Tuesday, January 2, 2007

Why do they always pick the hard way...

I have started to read a number of blogs on the internet having to do with software development. Some have been better reads then others, but recently a friend of mine made a post on Business programming not being that hard I began to think about this in the car on the way home and I felt inspired to write something in a blog of my own.

I started to wonder about why Big Business seems to consistantly strive to make things as hard as they can on developers in the name of progress? Just about every largish company that I have been associated with in my fairly short career has touted some process or methodology that they follow that helps them to produce high quality software in a highly repeatable fashion with quick turn around. Can the management of these companies really be that daft? Do they walk around with blinders on all day long thinking to themselves what a great thing they have laid upon the feet of the software developers that work for them?

Process for the sake of process doesn't do anything to help the software developer and more often then not it seems to get in the way. My life examples are things like CMM (Capabliity Maturity Model) and Prince II and a few others that have had less defined processes that they would choose to follow (Waterfall and others). These things are all fine and good in their own right - but they MAKE THINGS HARD! In some cases unduely hard.

Why do these processes make things hard - they make things hard because every single one of them get in the way of doing the primary job of a programmer. What is that you might ask ... PROGRAMMING! Each one of these items requires gobs and gobs of documentation, time tracking, etc. etc. etc. which detracts and distracts from the job at hand ... Getting the code down and into source control so that someone can take a look at it and say "Yeah" or "Nay" and then more code can be written or modified to bring the end result in line with some persons individual/business requirements.

Knowing this - why is it so hard for businesses to attempt to define a process that does just that - allow the programmer to work with the business or a smallish group of people to allow the code and small amount of documentation to stand on its own? Why do businesses cling to making things as hard as humanly possible on the developers and the staff that surround them? Why do they all cling to the idea that putting these heavy processes around what programmers do is somehow an improvment on the way things work?

I understand that there have to be some controls, Change control is a good example. I also understand that there has to be some common understanding of an 'overall' process so that more then just the developer and a business person can understand whats happening and when, but why such heavy handed processes and procedures?

Now I can hear some people saying "Why not adopt an agile approach?" This is all fine and good but one can not look at things like the agile methodologies that have sprung up of recent as a Silver Bullet solution to the 'old' way of doing software development processes. However, what still befuddles me is why companies find it so hard to take the best of both worlds - the bits of one methodology that aid rather hinder and mash them together into their own way of doing things. I guess in the end - blindly following a process for the sake of the process is easier then taking the road less traveled and actually developing a process that works.

1 comment:

Sean LeBlanc said...

Hey, Joe.

Found your blog via LinkedIn.

Regarding your comments - it's ass-covering, plain and simple. It's like that old adage about no one getting fired for buying IBM. Well, these days s/IBM/Microsoft/.

They pick to blindly follow the process du jour because "everyone else is doing it". That combined with the need to "take action", be "proactive", etc. and voila, you have the [CMM|Sigma6|RUP|Scrum] process foisted onto development.