Generalizations are always wrong

I’m as bad as anyone when it comes to generalizations and simplifications.  Yet even as I state that nothing is ever that simple I still believe there’s a lot of value in generalizations.  They help us see patterns and anti-patterns.  I see even more value in the effort to simplify problems.  Much of what we do in building software is about creating a software model for real life messy scenarios.  We simplify because messy software is very expensive to write and maintain.  Ignoring unknown edge cases when architecting an application makes it possible to get something working quickly.  I don’t think you can do Agile without starting with a deliberately simple model.

I think the tension between Agile and Waterfall sums up the situation nicely.  They are yin and yang.  Agile works because the people involved have enough experience to identify a good model early on.  In other words, they already know the problem well enough to dispense with the rigourous process of Waterfall.  In practice I’ve found that we never know all of the problem enough so a good project is one that is balanced between up-front design and discovery through coding and user feedback.

Another common example of this is around performance.  Jeff Atwood generalizes that hardware is cheaper than programmers.  Lars totally disagrees.  This is hardly a new debate.  Anyone who has had to make a complex application go faster knows how much work and risk it involves.  Equally, anyone who has tried to get a complex application working (with incomplete and changing requirements) knows that optimizing too soon means you’ll never finish.  Both Jeff and Lars are trying to present a simplified view of the problem.  Both arguments are valid but lack the context of business needs.

The performance problem is often exacerbated by the lack of clear requirements.  “Make it fast” isn’t helpful.  “Ensure that account creation requests have a median response time less than 100ms and a 90th percentile less than 500ms” is better but

Good project management is about knowing when to use more hardware to buy time to build more perf.  It’s about defining performance goals in business terms that make it possible to prioritize the work.