Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> wildly impractical - there are only so many developer hours available

Which is a huge reason that learning a RAD (rapid application development - emphasis on rapid) tool is a pretty useful skill.



What makes it rapid is taking shortcuts. There's no silver bullet for increasing speed while preserving maintainability and extensibility. Prioritizing speed is exactly the problem described in the post you're responding to.


Not implementing any solution and blaming it on "only so many developer hours available" is the problem I'm responding to.

I'm not "prioritizing" anything. The scenario we're discussing is when an intern or low-level employee is able to successfully automate, enhance, or simplify a manual, inefficient business process that management has not seen fit to improve - so the worker does it themselves.

Access and similar platforms aren't "rapid" because of shortcuts, they are rapid because they are visual-based, drag-and-drop, object-oriented and often make a component's properties and methods customizable also via a visual interface. It's a different way of programming, yes, accessible to the masses (which is likely the reason you have so much disdain), but not "shortcuts".


I don't have a problem with accessible development tools like that, but they do have tradeoffs. An Excel spreadsheet is an excellent tool for some business calculations, but once you start asking questions like, "can we add some authorization to this? Can we add some permissions? Can we pipe this into a UI?" we've passed the limits of Excel and we need to implement a real application. The more you implement in your spreadsheet, the more you may end up re-implementing in a real database.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: