A salesman walks into a bar near Microsoft. He sees that there is no where to sit, but he’s dying for a drink. After waiting a few minutes patiently for a barstool to become available, he loses his patience.
So he climbs up on top of the bar and announces that he’s a salesman, and he’s got a great idea for a software system, and it can be written in a week by any programmer with a brain.
The bar clears out.
The fact is that we’ve all been victims of a WAMI, (Wild-A**ed Marketing Idea). Some of us more than others. It’s not that these ideas are bad. In fact, they are usually quite good. It’s that they usually come with a wildly unreasonable expectation of how “easy” it will be to bring them to life.
And there’s the rub. In the initial impression and early agreements made on a project, dealing with expectations of cost and capability, a lot of architectural assumptions are made, and then estimates are based on those assumptions.
But if you don’t write them down, how will those assumptions be reviewed? How meaningful are they? How can they be challenged, or validated, or even reused?
One idea that I heard lately goes like this: when a business leader describes a problem and proposes a solution, to internal IT groups, the group should NOT respond with an estimate. They should respond with a high-level architecture, complete with assumptions and potential tradeoff decisions for the business leader to validate. (a couple of pages of diagrams, and a single page of assumptions and tradeoffs).
Once he or she says “yes” to those constraints, then (and only then), provide an estimate.
This way, the architecture starts as soon as the idea does. For those folks who work in the Waterfall model, the architecture exists (at a vague level) before the requirements document is completed. At each stage, the architecture is updated to reflect things that were not known before.
For those folks working in agile projects, you don’t have Big Design Up Front, but you don’t have Zero Design Up Front either. You have something small, something light, and hopefully, something that directly emits code or tests along with those diagrams.
Point is that the initial architecture doesn’t have to be ‘right’ but it can form the basis for understanding the system, its assumptions and constraints. It is updated with each sprint, or reworked with each phase or whatever your SDLC process calls an ‘iteration.’
At least then, hopefully, an IT team gets away from the notion of “t-shirt size project estimation” and towards the notion of transparent assumptions, managed expectations, and realistic costs.