Carpe Beerum: Life's Lessons

Paw Prints: Writings of the maddog

Today I met with a person who was one of my students in an evening class at Merrimack College in 1981. At that time he was programming for Compugraphics, and eventually became a manager of thirty people at a large hardware company.

Our conversation was not about “bits and bytes”, but tended to be on management style and those things that freeze a project instead of moving it forward. The parts of the conversation that impressed me the most were not things that came straight from a text book on computer science, but were things picked up over time and honed through experience. Some people would call them “common sense”, but unfortunately the points he made are not that common. Many of the points found me shaking my head in agreement. We both had the same ideas, but often said them in different ways and with different examples.

One of the short “messages” he often tells his engineers is that it is often faster and better to implement something twice (learning from the first implementation), then to try to implement it perfectly the first time (when you have little idea of what the customer really wants or how they are going to use it). In Free Software the adage is “Release early and often”.

One of my favorites was the discussion about two people coming to him after arguing for weeks about “the right way” of doing a project. My friend listened to each of them present their case for ten minutes, then pointed at one of them and said “We will do it that way”. Afterwards the other person asked for a reason why my friend picked the opponents method. “I did not have a reason,” my friend said, “but if you two really intelligent people have argued for weeks over this, and neither of you could convince the other one you are right, then probably both methods are close to being equal. What I know is that you have made no forward progress while arguing over this. I would rather you implement a sub-optimum solution now, getting us closer to market, then spend another year trying to discuss which solution is 'best'.”

I told my friend I had even proposed a formal position for that type of resolution solving at Digital Equipment Corporation....the position of “software czar”....but my management would not listen to me.

He told me about how a QA person was really upset that whenever my friends team fixed a bug, his QA team found ten more bugs. To the QA person this illustrated that “fixing bugs was bad” because “the development team created 10 more bugs for every bug fixed”. My friend quietly told the QA manager “No, what it means is that when we fixed the first bug your QA team could now get to other areas of the code that had never been reached before, and you were finding the new bugs there. It means your QA team is doing a great job, with comprehensive tests, and that they should continue.” He could not get the QA person to understand what was really happening.

Another story he told me was his inability to sell his company on implementing a simple solution that would allow them to capture 84% of their competitor's market. The management had rejected the solution since it would not allow them to capture 100% of their competitor's market, but they had no other solution that would capture any of their competitor's market. We both ordered another beer while we shook our heads.

We sat there for three hours, discussing the lessons we had learned over the years in industry...my forty and his thirty years. I told him that we should write a book, but the only title we could come up with was probably something that would be mistakenly attributed to Scott Adams of “Dilbert” fame: Carpe Beerum.

Comments