There I am, discussing a feature with my colleagues, when one of them says the words of scope creep doom: “While we’re at it, we might as well implement that other feature (that belongs in the same component). It would be foolish not to, as it’s so much work putting that component live.”
I disagreed, as it’s become second nature for me to break features into smaller parts not make them larger; let alone combine 2 features that are unrelated except for the component they’ll reside in. But why was that again? After all, the argument is so convincing: That component is hard to deploy. And the other feature is not that much more work. Oh, so tempting!
Too bad, that in my experience it never plays out that way. Even if it’s really “not that much more work” coding-wise, it usually turns out to be a bad idea for other reasons. Or in the words of my esteemed ex-colleague Stefan:
Don’t forget that the easiest part of software development is coding.
So here are effects of combining features that I’ve seen (not all at the time or for the same features):
- You lose focus
- Sometimes you end up with only one feature fully implemented and the other as half-baked zombie code
- In extreme cases this leads to the secondary feature being released, but not the original one (which was more important)
- You add work other than coding
- Documentation – If you skip this, either no one will know about it (and then why build it at all) or there will be lots of questions. Again and again and again.
- Testing – Even if coding the secondary feature doesn’t add much work, it might be a lot of work to properly test it
- The secondary feature might need additional libraries / hardware / upgrades …
- You add risk
- More places touched -> more “opportunities” for introducing bugs
- A bug in the secondary feature can cause a delay or worse rollback of the original feature
If it weren’t for the original feature the secondary one might have never been important enough to get build. But if you combine them, it will forever bloat the code, the test suite and be a potential source of bugs.
So, say no to scope creep. Even though it’s hard to say no and the “While we’re at it”-argument sounds convincing. Sadly it’s never quite as easy as it sounds.
Instead I’d work on making deploying easier. That’s the real problem here. And not an easy one…
Update: Also read this excellent article by Kris Gale about complexity cost
Update 2: I did not follow my own advice and here’s what happened