Skip to content

Just Say No (to broken processes)

Broken development processes lead to broken code. When you find badly formed code, and especially if you didn’t  write it just then in order to make the test pass just a minute ago, and super-especially is the code is already in production, you not only need to rectify the code, you need to rectify the process that lead to the broken code. Well, to be accurate, you need to start engaging in some root-cause-analysis on how this badly formed code came to be included in the production system.

On a technical mailing list I’m on, a developer asked for help in regard to a class he had to modify. There’s no need for the full gory detail here; suffice to say it’s main feature was that it had a very long if-then-else method that had nearly 20 steps testing multiple boolean statuses strung out after each other. The question was very simply; “how to refactor this?”. The suggestions were all good; ranging from using polymorphism to implementing a rules engine.

It’s not the solutions, or even the code that I want to discuss. Near the end of the thread, the original poster came back and said he’d discovered that (to paraphrase) ‘the feature change needs to go to the QA process today’ and that the refactoring couldn’t be done: the two-line hack would have to suffice.

I feel for the poor bugger, I really do, I’ve been in that situation myself. Maybe it’s just my bombastic, iconoclastic nature that makes me push back at these situations and tell people what fools they are for not valuing the craftsmanship of the very craftsmen they’ve hired specifically to build their software solutions. We need to start to insist that craftsmanship is valued and not just dismissed with an airy wave of the hand by management anymore. I’m fully aware this frequently makes me unpopular amongst those who don’t like to told the hard, brutal, truth. But I’ve given up caring. The truth it is.

In this spirit, I’m going to put on my “I’m as mad as hell and I’m not gonna take this anymore” hat and say the following. The reason that class in that state is because “changes to this feature are going to need to be in a build for QA today”. What needs to be done about these situations?

Just Say No.

Developers – those aspiring to be craftsmen anyway, need to be able to say it just is not possible for this feature to be changed today. Tell the management they have maxed out the credit card and the bailiffs are banging at the door and taking the silverware away as payment.

For a start, who decided this feature had to be in the QA build at some arbitrary cut-off date anyway? Someone who had never seen that class, that’s who. That “chicken” committed developer – the “pig” – to deliver the feature by some arbitrary cut off date and didn’t know the details. This is estimation by fiat. In any half-way decent process that respects it’s workers as people and not jut bit-flippers, no-one has the right to do this; it’s massively broken process. Chickens are not allowed to decide on estimates: only pigs are. The only way these things change if someone stands up and says “NO” to such broken process.

I don’t mean to say the developers can just go off with the fairies and gold-plate every piece of code they touch. But it has to be at least well-made. Obviously this particular process isn’t an agile environment – as it includes a “QA” stage with arbitrary cut off date at which point hte code “gets thrown over the wall”. And the company has management (I assume it’s management) running around and setting arbitrary delivery dates for unknown work.

Seriously, process improvement has to start somewhere. Be the change you seek. Stop tolerating poor code. If the process you work in demands you to tolerate it, change the process as best you can.


  1. Ben wrote:

    lol “I’m as mad as hell and I’m not gonna take this anymore” …your age is hanging out :-) Also: that was a crap movie & I want my 2 hours back.

    Seriously though, sometimes the QA excuse can be symptomatic of inefficient testing processes… the kind that can be replaced by robots. It should not be so costly to QA a piece of software that it impacts what (and how) things are developed.

    As developers, we need to start looking at how we can use the lessons we’ve learnt to help other parts of IT be more efficient. Agile is about more than just how you write code…

    Friday, June 5, 2009 at 20:51 | Permalink
  2. Scot Mcphee wrote:

    Well, I would say that fact there is a post-development “QA step” is a big hindrance to effective delivery. It’s a wasteful thing to have a separate process with a pipeline like that.

    My concern in this post isn’t so much about “more than just how you write code” as it is how all those non-code things affect the code. If you don’t write good code, or can’t clean up poor code, it’s not just the /code process/ that’s in a fault condition; it’s large chunks of the entire development method.

    Friday, June 5, 2009 at 21:53 | Permalink

One Trackback/Pingback

  1. let x=x › ‘//TODO’ considered harmful on Saturday, June 6, 2009 at 00:47

    […] Yesterday I said that developers should start being a little more militant about the craftsmanship o…, i.e. pushing back on broken methodology that demands poorly-built code  be released into the wild. This sort of code is always inherently fragile and will break your software if it has not already. […]