The two poles of software development:
Release early, release often.
Do it right.
Both are intended to make people’s life easier and better.
If you release early and often, you can get users involved in the development process. No matter how smart you are, there are features you didn’t think of that will only come up once people actually use the software. And there are great features that just don’t matter to anyone.
You can’t do great design by capturing all the requirements upfront. You can only plan in detail for mediocre software. Great software builds on experience, and experience builds as people are starting to use early releases.
Treat this as a law of nature. You can’t break it, no matter how often people try.
But there’s a problem with half solutions. Crappy software tends to work for a while, and then go up in flames. You’re losing a lot of data, you can’t keep up with load, or the hack-upon-hack-upon-hack becomes unmaintenable nightmare. At some point you just can’t get it stable, or add new features, without a rewrite refactoring.
If you want the code to survive, if you want happy users for the long term, you need to do it right.
Those are two poles, but they don’t conflict. If you plan your development process right, you can do both at the same time. You release early, iterate, release often, refactor, and eventually get it right. You get all the features that matter, some you didn’t even think of, stable code that’s easy to maintain.
It’s just a matter of picking the right process.
And getting management to agree.
That’s the biggest challange in software development. Behind every developer, there’s a bean counter and an eager sales person. And they want to defy the laws of nature.
Management wants software done right, so it never shows any flaws. Of course, you know it will be mediocre software because you know you don’t know all the requirements upfront without getting users involved. You’ve done it long enough to realize that customers don’t know what they want until they see it. Requirement documents don’t mean anything.
Management wants software done now. If there’s any way to get an early release, they’ll take it and sell it as a done deal. I call it “prototype lock-in”. If the prototype, held with duct tape and spit, looks close enough to the real product, it will be the real product. And damn the maintenance costs.
Management budgets 80/20 in relative dollar amounts. But we all know that getting 80% there takes 20% of the effort. Once it’s that close to being finished, it’s actually far away from being done.
The trick, as Sterling Camden puts it:
The key is to prevent the company from releasing either of the first two versions without being able to retract them at a later date.
So how do you get management to understand the laws of engineering without trying to defy them through creative accounting? How do you prevent your project from becoming another Enron?
Chad came up with one idea:
Alternatively, if you have the sort of boss or client that likes to think (s)he is cutting-edge and hip to the New Thing, all avant-garde an’ stuff, you can just throw around phrases like “agile programming” and do the “iterative organic project evolution” thing. It’s a little like prototyping and refactoring beta testing and doing proper project design to varying degrees from day one to delivery.
What do you do to cheat clue management into the reality of software development?
Theme adapted from Simpla theme originally designed by Phu.
Powered by WordPress, fueled by espresso, more credits …
Subscribe