Comments on: Just Say No (to broken processes)

By: let x=x › ‘//TODO’ considered harmful

let x=x › ‘//TODO’ considered harmful — Fri, 05 Jun 2009 14:47:10 +0000

[...] 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. [...]

By: Scot Mcphee

Scot Mcphee — Fri, 05 Jun 2009 11:53:56 +0000

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.

By: Ben

Ben — Fri, 05 Jun 2009 10:51:43 +0000

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…