It was past midnight, the sprint board looked like a graveyard, and a client demo sat on the calendar with a red circle. I hit Rails scaffold, pointed it at the schema, and watched screens appear like popcorn. The room exhaled. A week later the real work began, fixing the edges that the generator could not guess. That night sold me on Rapid Application Development, but it also taught me where regret sneaks in.
\n\n\n\nRAD code generation is great when the target is clear and the scope is CRUD heavy. Think Rails 3 scaffolding, Django admin, ASP.NET MVC templates with T4, or Grails over Hibernate. They jump start models, views, controllers, validation, and routes while you still remember the user story. The trick is to treat the output as a sketch, not a shrine. Scaffolding is a starting point, and the sooner you own the code the less it owns you. Commit early, trim fields, rename stuff to match the language of the project, and write a simple test that touches the happy path.
\n\n\n\nRegret shows up when generated code leaks into core logic. Keep business rules out of templates and out of controllers that come from a wizard. Push decisions into services or domain objects you write by hand. Use partial classes or separate modules so regeneration never stomps your work. If your tool cannot respect boundaries, run it once and move on. A clean seam between generated code and your code is the difference between a head start and a mess that resists change.
\n\n\n\nTemplates rot if they live only in someone�s laptop. Put generators under source control the same way you version schema migrations. Treat T4 files, Rails generators, or custom scripts as first class citizens. Add a tiny README that says what the generator expects and what it creates. Wire it into your build so Hudson or TeamCity can run smoke tests right after generation. Templates are source, not magic, and they deserve review like any other pull request.
\n\n\n\nUse RAD for the parts you understand, not the parts you fear. An ORM can map tables fast, but hard queries still need a human touch. Build basic forms and lists with helpers, then slow down for joins, paging, and permissions. Write tests before templates for the rule that matters most, even if the rest arrives from a wizard. You will change frameworks faster than you change your domain, so keep the business language in plain code where Rails, Django, or ASP.NET MVC are details at the edges.
\n\n\n\nContext this week matters. Rails 3 just shipped with a cleaner router, Django keeps winning on admin speed, and Visual Studio 2010 makes T4 editing less painful. jQuery is everywhere and HTML5 is not science fiction anymore, with the IE9 beta finally talking canvas. All of this tilts the table toward faster starts. The discipline is free. Keep migrations small, keep controllers slim, log slow queries, and delete generated files you do not need so the code base stays obvious.
\n\n\n\nBottom line: use Rapid Application Development to reach working software quickly, then refactor with intent. Generate the boring parts, protect your seams, version your templates, and move business rules into code you would be proud to read a year from now. Fast is fine, regret is optional.
\n\n