While we’re at it…

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…

This entry was posted in Agile / Lean, Fairly Good Practice, Software Craftsmanship. Bookmark the permalink.

What do you think?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s