People over Process

Bill Higgins talks about the welcome introduction of Coté to Redmonk.

Bill talks about the role of process in software development. I remember when I first joined IBM and was placed into a team that wrote the stress tests for our Message Broker product. I was fresh out of university where I had just won a distinction thanks, in part, to my programming project - which I had written in the archetypal single-coder, late-night, coffee and pizza style.

The culture shock was intense, to put it mildly.

Looking back on it, I realise I didn't have the maturity to see that managing a 100+ man development and test team, distributed over multiple continents and timezones, is different to writing some code in your bedroom. The development process was there for a reason - and it worked. The thing that frustrated me most - the apparently endless meetings and time taken to take a change from concept into product - wasn't slowed down by the process, but was enabled by it. Sure - things could have been done more quickly if the process hadn't been there but, six months later, there would have been utter chaos and we'd have never got anything out of the door.

I reflected on this as I read Bill's post. He argues that endless, mindless process is an enemy. Quite right. The only thing I'd add is that, in order to classify a process as mindless and choose to throw it out, you don't just need good people; you need experienced people.