Archive for May, 2008

Management 101

May 31, 2008

I have had a boss since I started working back in the early eighties. I have been a boss and been someone who oversees work as well. During the past 20 years or so I came to believe that the front line manager is the most important job in just about every industry and especially in the software industry. Much like my parenting philosophy, a manager can do little to improve their employees, but they can really mess things up. Why is it that so many manager choose the path of messing thing up? I guess they were never taught management 101. I will attempt to give a primer.

Management’s primary job according to Deming (if you have the book “Out of the Crisis”):

  • Appreciation for the overall system in which work is done
  • An understanding of variation – and the true relationship between cause and effect
  • Constant pursuit of learning (improvement) through designed experiments
  • An understanding of the psychology of people

Thanks to google I found this:

  1. Take time to consider.
  2. Keep mind open — mouth closed.
  3. Obtain information without disclosing position.
  4. Reward people with praise for telling you what they believe to be fact — whether correct or not.
  5. Consider alternatives. Discuss pros and cons.
  6. Make decision — stay the course — support all involved.
  7. Change plan if new information makes it necessary.
  8. Keep confidence of management and customer. Tell the truth, no matter how painful.

These sources are a good start. I will add a few thoughts to Deming’s last point (the most important in my opinion). People, although complex, behave in fairly predictable ways. A person’s productivity correlates to to unmeasurable things: their morale and the skill they have at the task. If they like what they are doing their morale will be higher than if they are forced to do something they disagree with. Skill can be learned, but only if the person wants to be better. If they want to be better you have to get in their way to stop them. 

If you manage people then I believe your number one goal is to make them as productive as possible. Given the above it would seem obvious that you want people who like and are good at what they do. So the primary job is for you to identify those people and GET OUT OF THEIR WAY! I am amazed at the ways managers get in the way. They ask the person to do the task the way the manager wants it done (see above comment on what that does to the employee’s morale) because the manager THINKS they know better because they are the boss. This is so sad, but I see it happen so much that I think it is a pattern. The other thing I see is a manager who can not tell who the talent is. They look for people that are like themselves and make them the A-team and treat the others as second class citizens. Unfortunately this happens because upper management uses the same technique and it propagates down to all without a clue. Those with a clue tend to leave the organization.

I am sure I have glossed over things and simplified somethings too much, but I would love to hear other opinions.


Project Change, a Way of Life

May 26, 2008

I just read  Project Change, a Way of Life by Jurgen Appelo ( – ~2mb) and I thought it was worth the read. His goal was to “link complexity science with agile software development”. He starts with change is the only constant which leads to the iron triangle. For some reason he puts the attributes on the apexes and not the sides (I think this hides the most important aspect of the iron traingle, but it’s his article).

Next he goes on a diatribe on the term “project” and decides a better term is “product” (which is the goal of most software projects – sorry I just couldn’t help myself). He then gets to an interesitng discussion on success which leads him to this:

I believe that every software product is a success, until it fails. 

I think its a good way of looking at it. He talks alot about his car…he is young after all. He uses the term fitness from biology. Fitness is a relative term about how well a species survives in their environment. I like that: a product’s fitness is the same thing. Take a product out of it’s environment and it could do better or worse. Put other products in it’s environment and it might be more or less usefull.

He calls the game of improve or die the Red Queen Race from Through the Looking Glass. Products change to keep up with the competition or they are no longer used and die. Your nice document management system will lose to a package that costs money once the feature difference is worth the cost.

He then goes into Fitness Landscapes, which a neat idea, but I don’t see a strong correlation with software products. I disagree that people can do “conscious selection” well and natural selection is not well characterized as being random. Now I am just nitpicking. Like I said in the beginning, I think this aritcle is worth the time it took me to read 28 pages.

Why do decent people use the waterfall method?

May 25, 2008

It seems everywhere I go the waterfall method dominates the mindset of the management and most of the technical staff. I wonder why that is? It seems to me that any rational person would admit that the cost of fixing a defect grows exponential as time passes from the moment it was introduced. Most rational people would admit that in the waterfall method most defects are caught at the end of the project life cycle, thus guaranteeing they will be very expensive to fix and that most project will have to resort to testing the quality up to a level that is relative to how late the project is (the later the project the more defects they will consider shipping). Given these assumptions, why do any project using a method that caps the outcome to mediocrity? Maybe my own past can help me understand this.

When I was first paid to do software (circa ’91) I thought the right way to do software was the waterfall method. It was what I learned in Grad school as part of the Software Engineering series and it seemed everyone I met was using it in one form or another. When my job involved the CMM it fit very nicely with this belief. Anyone who though differently was obviously a Cowboy Programmer and was just too lazy to do a professional job. Being young gave me such confidence (ignorance seems to do this).

As I gained experience, I started to doubt my belief in this classic approach. I worked once with a client who gave me new requirements every other week or so and my team of two gave him working code every week or two. It worked well, but I didn’t think why. Later I started teaching others how to deliver software on time and started to really question my belief. I saw projects being executed by CMM level 3 and higher organizations consistently go over budget and deliver sub par systems. About this time I read some Agile books, some Lean books, and the classic paper by Gilb “Evolutionary Delivery versus the waterfall model” and though what a dope I had been!

I seemed to have overcome a belief that wasn’t founded on solid principles, but others seem not to. Humans tend to behave in irrational ways in order to “fit in”. Maybe what I see is just a group dynamic caused by fear of the unknown. They know the waterfall method and the devil they know is better than something they have never tried. The more I think about it, it reminds me of OO adoption. Back when I first read about OO in ’92 (and it wasn’t a new idea by any measure then) I thought this is got to be the way to program. It came naturally to me, but it was years before I was in the majority.

Maybe Agile/Lean (Whatever you want to call it) just needs to ride the adoption wave until the majority accepts it. Then the fear factor will be with those who don’t do it? Then some new idea will come along and some guy will blog about idiots like me who do it the “old way” 🙂

Moving to WordPress?

May 25, 2008

I got sick of blogspot yesterday so I started this today. Only time will tell if I use it.