Tuesday, October 9, 2007

Process? We don't need no stinkin process!

OK, I admit it, we do need process. We are a growing company. We have a lot more developers working here now, across more products and releases than ever, and somehow we have to coordinate that. However, I do not subscribe to the view that a successful company just all of a sudden hits a moment in time where EVERYTHING that they did just doesn't work anymore. Where all your processes that are in place are now obsolete, and things you didn't have processes for need processes most desperately. Yesterday, we were producing good software well, but today if we don't do it this new flashy way, it's just not good software anymore.

I personally think we have done a pretty good job making software. I guarantee that there is more we could do, but that we do well as is. We have a bunch of grown-ups working here, who are obviously very competent engineers, and can stay on task. We should reward them with greater freedom to explore ways to improve the software and their skill sets.

There has been a culture across different jobs I have worked at in my young career that rewards the latest acronym or fad that hits all the blogs and gets a writeup in Dr. Dobbs. Everyone needs to be doing that because somebody else does it successfully. The difference is that different people are working there. What worked there doesn't necessarily mesh here, and what has made us successful perhaps wouldn't thrive elsewhere if hoisted on another organization.

Obviously, I work for a software company, and when I leave my job, I go develop some more. When I get home, I feel so free, just to do work and screw up, and learn something new as a byproduct of it. I love the freedom of expression that comes with a blank slate and no "existing framework" or architectural standards to burden me. If our processes are so broken, why is it that the existing framework (the artifacts of said irreparable processes) is sacrosanct? Seems odd.

I wish we could take all our brightest minds and just put them to work on things like "how can we make really awesome new stuff and take the stuff that sucks and make it better", instead of, "oh well we use sprints now and the SCRUM master wouldn't be agile if the burndown is a waterfall of SDLC leverage, so we can't do that feature. But hey, we can just do it later." By then, a new barrage of process change will take up our time, and eventually the "new" feature will be based on technology that was obsolete five years ago.

When I go home, I get to decide what makes the greatest impact to users and bottom line and what will be the best way to do things right now, using traditional methods of estimation like "how much better will this make the product, and is it worth it in light of the fact that it takes n hours"? It's freedom, baby! Catch the fever.