Edge cases and new code

Spectacular failures in software development still plague the industry. Sometimes I wonder if this is a less a problem of the tools or more a problem of managing the design of the thing; or rather, over-managing. I came off of a large, failed, multi-year project at my former employer. On the surface, it appeared everything was done correctly as far as design went; lots of detailed use cases and database designs. Looking back on it, I see that a lot of time was spent on managing edge cases; the kinds of things the software is meant to manage only rarely or only due to an extreme exception. The app itself was a straight-forward CRUD app looking to replace an older client/server app; thus, most of the business rules should have already been in place. The thing about older apps is that all the edge case rules they contain were never designed into the thing in the first place; they came in as time went by. The hubris back in the 'waterfall' days was that the app was never expected to be majorly refactored over time. Now many of the tools for web development (frameworks, IDE's) have the expectation that refactoring will be done and support those efforts. Thus, the development of greenfield apps may best be realized through a modified 80/20 rule that promises only to deliver the 80% on V1/launch, and that the 20% (which will take 80% of the time) will be delivered incrementally with heavy unit testing and use-case churn expected during that time. Grails is a great tool that's designed to 'get something in front of the customer really fast' while providing a RAILS framework which enables much simpler refactoring and the incremental addition of services to manage edge cases.