vwdiesel

It really has just been one of those days. In my previous post I did a bit of ranting about why companies always have to pick the hard way to do things. This time around I thought I would attempt to address one of the things that really gets on my nerves, the "I am the boss so you'll do what I say" syndrome as I like to call it.

This topic has come up for me a few times in my career so far and it seems that in my current position at "Big Company" I will be experiencing it more and more. The syndrome usually involves your boss or your bosses boss and works something like this:

1) A pet project of the 'boss' has been created
2) This pet project is not part of the current development line(s)
3) The 'boss' makes a request to get this pet project in 'Right away'
4) This 'right away' flies in the face of reason
5) This 'right away' forces other things out of the way.

The reason that I think these types of things are especially bad is for the 'flies in the face of reason' of #4 stated above. In my current case it is a pet project of the 'boss' that has not been tested or reviewed and the boss would like this change implemented in a very short time frame. Why does this bug me so much? Well, "Big Companies" like to tout that they are secure and that they have process (as in my previous post) and that the software that is developed at "Big Company" is of the tippy top quality. However, when pet projects come up all of these procedures and policies and so on seem to go right out the window. In the end this means that the software is of a lower quality because changes are rushed in, they are not reviewed and vetted properly and as such also have a high probabilty of having some security issues and other bugs (even more so when you speak about doing web development). The other reason that this "I'm the boss so you will do what I say" thing bothers me so much is personal.

When I was growing up I came to believe that the saying that I should "Respect My elders" was bunk not because the thought itself is bunk but more because of the way most of my "Elders" said it. They all seemed to say this line as if I should respect my "Elders" because they are old. I patently disagree with the statement when stated in this way. I, rather, agree with the statement when it is taken to mean that I should respect the knowledge that my "elders" have due to their being on the planet longer. I additionally treat this not as a given but something that you have to prove to me that you have. This is why it has always bothered me to hear people in positions of power say "You should do this thing A because I said you should", or "Jump THIS High because I am your Boss." Both of these statements do nothing to solidify my belief that they know what they are doing but rather does more to solidify that they are absolute morons that got where they are not by being bright - but by being ruthless and nasty and always getting their way because they can.

So - like my previous post, why does it have to be "My way or the high way", in my personal experience the adage "You catch more flies with honey" is more applicable. Choosing to work in the system as defined and to work WITH your employees to make decisions is more beneficial to both their growth, your leadership as a boss - and the "Big Company" as a whole.

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 due is somehow an improvment on the way things work?

I understand that their 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.