Labnotes » Managing management

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?

Jun 26th, 2006

Sterling Camden

Thanks for the linkage, Assaf.

It’s a tough problem. Management and sales will cite the competitive market as the reason for having to get something out quickly. Actually, the more competitive the industry, the more pressure to get released, right or not. What they don’t understand is how badly that approach bites in the long run, and how much more competitive advantage they could have if the foundations for the application were laid securely. They often can’t see past this year’s earnings.

Jun 27th, 2006

Assaf

Sales and engineering often don’t see eye to eye. Sales needs to close the deal early on, engineering needs time to make sure its viable in the long run. But neither is at fault.

That turf war happens because the turf is too small. Either the product is too expensive to develop, you need to push it too hard, or expectations are not talked about from either side.

You need someone at the top that clearly understand the true cost of each sale.

Expectations — that’s key. Developers (myself included) are often so optimistic about their own abilities that they underestimate the effort required, especially if sales wants that to be the answer. If engineers can back off from their egos, fully analyze the risks, and set reasonable expectations by articulating the real story (plus 20% for the unexpected) then it becomes possible to do the job correctly in the time given. In a perfect world.

In my experience expectations is everything, the key to successful relationships, but also the hardest thing to manage.