- We Fail Too Much
- Definitions of Success
- The Standish Group
- Doing the Wrong Things
- Doing the Things Wrong
- Time Goes By, Things Improve
- One Reason: The Civil Engineering Analogy
- Giving Up Hope
- Ignoring Your Mother
- Bridges Are Hard, Software Is Soft
- We Swim in an Ocean of Change
- Accept Change
- Embrace Change
- Capitalize on Change
- A Better Analogy: Evolving Systems
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Doing the Things Wrong
I teach quite a lot. This gives me access to lots of developers, day in and day out, and so I like to ask them questions about how things are going for them, and why they think things are the way they are.
In my most popular class, which is about patterns, I begin by throwing a question out to the entire class:
"How many of you have been on a failed project, or one that was significantly challenged?"
Naturally, they all raise their hands.2
Next, I ask:
"What happened?"
This is a question they do not expect, and one that likely they have not been asked much before. Sometimes, a largely unasked question leads to very valuable discussions. I listen and write their responses on the whiteboard. Here are some typical responses.
- The requirements changed after we were pretty far into developing the code.
- My project was dependant on another project, but we did not get what we expected from the other team, and so we had to change our stuff to match what they did.
- The customer changed their minds. A feature they were sure they did not need ended up being important, because the marketplace changed while we were developing the software.
- We did not realize the best way to get a key feature to work until we got well into the project.
- The technology we were using was unreliable, and so we had to change horses midstream.
- The stakeholders imposed an unreasonable schedule on us.
- We committed to a schedule we could not meet, as we later determined.
. . . and so on. I have gone through this process dozens of times, in large and small companies, with individual developers in public courses, here in the United States and abroad, and the answers are basically always the same.
Looking for a through line, a common element that seems to underlie all or most of these causes of failure, consistently drives to the same conclusion. There is a thing that makes us fail, and that thing is change. Requirements change.
- Our customers do not know what they want; or
- They know what they want but they don't know how to explain it; or
- They know and can explain what they want, but we misunderstand them; or
- They know, can explain, and we get it, but we miss what is important; or
- All of this goes right, and the marketplace changes around us anyway; and so things have to change.
Technology changes. Fast. Faster all the time. I do not think there is much point in hoping that this is going to stop, that we're going to finally have a stable environment in which to develop our software.
Change has been, traditionally, our enemy, and I think we have known it for a long time.
Who would rather work on maintaining an old legacy system, as opposed to writing something new? I ask that question a lot too, and rare is the developer who would choose maintenance.
Maintenance is, of course, change. Change is a chance to fail. Nobody wants to be the one who broke the system. Nobody wants to be the one who's going to have to stay late, or come in this weekend, and fix the thing.
And so, we find ways to avoid making changes.
Sometimes, we put a contract or a control board between ourselves and our customers. Sign the contract, and they cannot change the spec unless they jump through a series of hurdles, which are designed to discourage them from making the change at all.
But even if that works, it does not work. Remember that fifth metric of software success? The software has to be used, it has to deliver value. If it does the wrong things, even if they were the things in the signed contract, then it will fail in this respect.
Another approach is to try to create a design that is set up to change in any possible, imaginable way.
But even if that works, it does not work. This is typically called over-design and it creates a whole other problem: systems that are bloated at best and incomprehensible at the worst. Plus, my experience is that the one thing that comes along to derail you later is the one thing you didn't think of in the over-design—Murphy's Law, as they say.
So, what do we do? How can we safely accommodate the changes our customers want, and likely need? What has made us so brittle?
Why did we ever try to develop software the way we did (and the way some people still do)? Examining this question can lead us to some interesting conclusions, and can perhaps give us some guidance that will help us to continue this upward trend, and perhaps even speed things up.