Software projects are difficult because…
I’ve heard this said several times over the years:
Software projects are difficult because software is so easy to change.
Other engineering and building projects are seemingly easier because they deal with “hard to change” stuff like bricks, mortar and steel.
I heard this statement again at Rob Bowley‘s SPA 2009 “Dealing With the Estimation Fallacy” goldfish bowl discussion about estimation. Rob has written up the outputs of the session, but sadly there’s nothing more about this fascinating statement.
I find it difficult to accept this statement. Surely, the ease of change must be an advantage? It means we can exercise our Real Options later, that we can change our mind when we know more? It means that we can correct mistakes and wrong assumptions more cheaply? It means we can keep our creations relevant in a changing world?
So, to make software projects easier we just need to…
If the previous assertion is true, then making software projects easier is easy.
Make software hard to change so that software projects become (a little bit) easier.
Forget “embrace change”! From now on, I’ll make software hard to change. Not that I have to do much to achieve that, I can create hard to change software without thinking. 🙂
Hm. I still don’t understand why easy to change software makes projects hard. Do you know why?
Some effective ways to make software projects easy
The goldfish bowl came up with some more ideas about change.
1. Use only reliable, thoroughly tested technology that serves your people and process
One remark was that we make things difficult for ourselves through technology churn. Technology and tools change rapidly. Unfortunately, most of these changes are no improvements. But we don’t have to stay on that treadmill. Some time ago a new programmer in the team complained: “Why don’t we use technology X? It’s new!”. My response: “That’s exactly why we don’t use it. Yet.”
When I’m in charge of a project, we will only use a new tool or technology when it’s thoroughly tested and when everyone in the team understands it. We’ll first try the new tool on prototypes or small internal projects so that we can discover the hidden pitfalls. And even then I need to have a backup solution on hand if the new thing doesn’t work. As Weinberg says: “Anything new never works”. As the Toyota Way says: “Only use reliable, thoroughly tested tools that support people and process”.
2. Don’t reuse. Use.
Another remark was that we write too much custom code from scratch. We could reuse more or implement standard packages. My experience with this is mixed.
Standard packages can work IF they deal with a well-known, stable domain where you don’t want to differentiate yourself from your competitors. For example, you probably don’t want a custom accounting package, unless you’re Enron. But is a standard package really the best way to run your manufacturing plant? Maybe when you don’t want continuous improvement. If the slogan is “It’s easier to change your company to match the software than to change the software to match your company”, then you’ve got some really hard to change software. Those projects don’t look easy, though.
I’m no fan of frameworks. The penalty for “colouring outside of the lines” is too steep. Most packages and frameworks are “80% solutions”: great for the first 80% of your project, hell for the last 20%. For example, I like Ruby on Rails, but it takes me so much effort to do something differently than what the Rails developers think is the right way. As a result, I’ve seen mostly productivity decreases when using frameworks, even the ones I wrote 😉
What does work:
- Writing software for use, not for reuse. When I write TDD code, refactor and remove duplication I end up with useable code. A surprisingly large amount of it ends up to be useable in other projects. Three or more instances of this happening and it becomes worth spending time extracting the common code and maintaining it in a library.
- Using libraries, especially small, focused libraries with technical components. It’s a pleasure to be able to download a Ruby Gem, have a quick look at the source, write some unit tests against it, use it. For example, it took me about an hour to integrate the Akismet anti-spam service into my wiki. Since then it has stopped lots of spamming attempts on the many wikis I maintain. Great value for money!
These are just two small measures. They don’t make software projects easy. But they do avoid unnecessary difficulty.
Hi Pascal!
Interesting article.. if I got your article right, you mean that we can make it easier to success when creating software if we use reliable, thoroughly tested technology and if we write TDD code, refactor and remove duplication.
I agree with you, but I still think that the main problem with software development it’s not the technology itself, but the wrong approach, processes and methodologies used for software development.
Alberto, the post was meant to be a bit tongue in cheek. The problems lie elsewhere. But first, let’s stop making our lives difficult, stop adding unnecessary distractions (like playing with technology or ‘designing for reuse) to our projects.