How to cobble software together properly

You needn’t take this post seriously, but it does come from my frustration with
software development at a certain… never mind.

Analysis

The first and most important requirement is to have a poor analysis of the problem or none at all. Judge an analysis strictly by its page count and the number of foreign words, paragraphs or chapters nobody understands. Best of all, do it without the client. We know better than anyone what they have in mind. Then change the resulting analysis at least two or three times during development.

Data model

Whatever you do, don’t design a domain model or model the relationships between entities. Obviously you have to start with the database. So, based on the first version of the analysis, sketch out the tables and columns. You can always drop them. Add “sketch it out” and “flip it over” to your developer vocabulary. You’ll hear them a lot. Every time the analysis changes, adjust the data model, or rather sketch it out again.

Domain model

Stitch the domain model onto the data model. Build the domain objects to match it exactly. If the data model doesn’t have lots of composite keys, something is wrong. Stay away from surrogate keys. Preaching that doctrine is heresy. Write tests for every domain object. Updating them in step with the data model will add a little variety to your ten-hour shifts.

Since you’re keeping up with modern technology, pick a persistence framework you haven’t
worked with before. Don’t worry. You’ll get to rediscover all the traps of mapping the domain model to the database two or three times as the analysis changes.

Service and DAO layers

Design the service and DAO interfaces to the best of your knowledge and conscience. You’ll get to change them and their implementations several more times. Sketch out test objects for those layers.

What’s left to say? Welcome to the age of cobbling software together, where any sort of plan is pointless. Is it worth trying to adopt more progressive software development methods? No. The only thing worth considering is whether to keep taking part in the inevitable harakiri of the software house that puts food on your table.