Software is hard because it is extremely highly dimensional. There is all of the state in your program, all of the dependencies and their intracacies, all the footguns in the language you are using, and then finally the complexity of the real-world problem your are trying to solve. Communicating this, and the implications it has on the development of software to non-engineers can be a frustrating experience. Here are a few analogies I’ve found work in the real world to explain why things are so hard.
Why giving effort estimates is often so difficult
- Imagine you’ve just been handed a bag, and your boss wants to know what the market value of the contents of the bag is. Now, it could be an ordinary bag, or it could be a magical bag, like Hermione had, with infinite space inside. You open the bag, and inside could be anything: a box of chocolates, a rabid tiger, both, and/or maybe another magical bag which also has infinitely more bags inside.
- Now, if the bag is simple, in a few minutes you can probably make a guess. However, it’s always possible that you miss a tiny little infinite bag in the corner, and inside of that one is the lost city of Atlantis. Unlikely, but possible.
- If you estimate too high, people say things like “That’s impossible, nobody could put something so valuable in such a small bag” . Then they’ll tell you that it’s actually worth less than that, even if they didn’t look themselves, just because that’s the maximum of what they want to pay.
- Depending on local customs, if you get the estimate too low, then you might have to reimburse the company out of your own pocket.
- This analogy falls down when you try to look for 80/20 rule things.
Why we should do some refactoring (yes, again) before we work on that feature
- Software development has a large aspect of ‘structure’. This can be compared to something like the layout of the furniture in a room.
- If you do it badly, nobody can get in and out of the door, so they do stupid workarounds all the time like going up and down the chimney by first invoking a spell to turn themselves into Santa Claus (which takes until Christmas, and they also have to deliver a bunch of presents to small children on top of their normal work).
- If you do it well, people can do useful things like walk in the front door, sit down at their desk, and get on with normal work with a minimum of fuss.
- When we add a new feature, we basically want to do something like add a new kitchen area, or a new door or stairway, somewhere in the room. If we don’t rearrange the furniture first, every time someone wants to get to that side of the room, they need to resort to going outside and then climbing in through the window to get to their desk. Not only does this take a long time, it also annoys everyone since they can’t get useful work done, and it also leads to mistakes since people have to focus on climbing through the window instead of their normal work.
Why super-ultra-detailed planning doesn’t speed up software delivery
- Sometimes we want to make sure the software engineers know exactly what the software they write is meant to do. So, in order to achieve this, some kind of Enterprise Arachnitect spins a specification-web of such detail that, theoretically, all the engineers need to do is go through each component and implement, piece by piece, exactly what it says.
- The problem here is that the software itself is just a specification for the computer, about how it should operate, piece by piece, exactly what the software engineer said.
- When the engineer implements the specification, at that point is the first time the specification is actually properly tested. Until then it is entirely hypothetical.
- It’s almost impossible to write a specification that is more complete or accurate than just writing the software directly, incrementally, piece by piece, starting from an MVP. The reason for this, is that the specification doesn’t get any feedback about what is missing or broken, whereas incrementally built software does.
- Compare it to a business trying to build the perfect product. Without market feedback, or at least feedback from testers, you have no idea if the product actually solves problems in the real world.
- Another comparison is to someone trying to get to a destination. It doesn’t matter how accurately they face in the right direction when they start, or how accurately they count their steps, if they don’t check where they are every now and again, eventually they will go off course and (potentially) fall down a well and need Lassie to run home and call for help.
- (This is what makes Agile agile - fast feedback loops to keep things on track. The rest is all just implementation details.)