Bad change: creeping complexity

Change requests are a major part of software development. If you think in an agile way, every card is a change, and that is what your development delivers. I still don’t trust change.

Impact Assessments try to document what impacts a change will have, both the desirable, and the inevitable. Good code is code that makes this easier, but many changes don’t respect good code boundaries, especially changes around the inflection points.

Let’s consider the shopping example from the inflection points post again. We take payment, we send an email confirmation, we start a warehouse workflow and a delivery workflow.

The boss announces some brilliant news. Your UK operation has bought out your US distributor, and all he wants to do is update the system so that US buyers can use the same shopping cart. That’s it. Simple change, allow USA addresses and credit cards.

Except your payment provider doesn’t accept credit cards. No problem, US cards can use the distributor’s existing payment provider. Add a branch, close the story.

Except your shipping provider has a different API for their US site. No problem, add a new handler, add a branch on shipping address when you create the shipping request inside the payment method. Close the story.

Except the distributor has their own warehouse and you need to Decrement their stock levels and kick off their stock process instead. No problem. Abstract it behind a warehouse handler, add a branch on shipping address when you create the packing request inside the payment method. Close the story.

Except the payment adds VAT to all the orders, when it sends them to the payment provider. No problem, add the US  state rates in the payment page, and pass the new total to the credit card provider. Close the story.

Now count the new decision paths, and the implicit coupling you’ve now introduced between the payment processor, the order calculations, the packing handler and the delivery service. Wouldn’t it be better to have a US and a UK order and just branch once?

At this point you may want to cancel any new requirements until you can refactor.

And I haven’t got through all the implications of this change for this step, and this is just one change. Has anyone else seen this happen?

Advertisements

3 thoughts on “Bad change: creeping complexity

  1. Hi Craig,

    I often get scope creep all the time. It sounds like in this case you needed a Spike in order to determine what the actual scope of the change is and so that you can figure out what the best way to approach making this change is. When we work on spikes we normally just time-box them to a few days.

    Once you have the scope of the change and you understand the difficulties and complexity involved you can dump the spike code then look at making the proper change. I’d probably break this down into a few stories so we can track progress better if the changes are going to take a while and also build in some time for refactoring at each stage.

    Liked by 1 person

    1. Thanks for the thoughtful reply. The other scenario is where these requests drip in slowly and the purchase step gets bigger in small increments each time until it becomes a ball of code that’s hard to untangle, but each individual step was small and self contained. In those scenarios, refactoring spikes are needed to break the step down again.

      Like

Leave a Reply

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