Mistakes, Criticism & Initiative

It's no secret to anyone who has ever built a software system that the task is difficult. As an aside, it's the challenge that is presented every time I start a new project that makes this profession so fun to me, but back to the topic. I've had folks tell me that software is not hard, but these opinions are often premised on their work of writing Excel macros, or perhaps dabbling at modifying an existing application slightly. I have even had supposedly technical people ignorantly question my estimates on implementing new features by asking me telling me that I should be able to just "write a little script" to accomplish the feature. What do you tell those people? No.. what I am referring to is the task of creating a new application or feature from scratch that users actually like and stands the test of future change – by another developer.

After acknowledging that there is at least some modicum of difficulty in this endeavor, it should come as no surprise then that mistakes are often made. Evidence of this is all too clear to anyone following tech news. The sheer volume of negative software news is disheartening, though I truly believe that many of the articles I read are more influenced on "software politics" than any real interest in accountability. I especially love the articles that pose those questions like "would we as consumers put up with a car that blue screens every time the turn signal is turned on…"

You can read tons of books and articles about software and quality. We have methodologies, testing, code reviews. CMMI level n's. More methodologies, different tests and even more reviews. Throw in design, specs and better up front engineering efforts. Put a little of all this theory to practice and you might come to the conclusion that quality software is possible, but not easy to accomplish. Even with all of the activities in place to improve your chances of repeatable software success, mistakes will be made. And that's what I really want to talk about.

Mistakes in a software project come in many shapes and sizes.

• Specification Mistakes. Fred Brooks said it best. "The hardest single part of building a software system is deciding precisely what to build". Many times I have built exactly what the spec said, only to discover much later that it was wrong. The unfortunate part of these mistakes is that engineering often take the brunt of the blame and criticism for specification mistakes that they had little or nothing to do with.
  
  
• Design mistakes. These mistakes are often not immediately apparent until performance and maintainability issues crop up. They usually manifest themselves late in the project, where fixing them becomes increasingly expensive.
  
  
• Coding errors. These are probably the easiest mistakes to mitigate through testing and code reviews. Still, they too often slip through, I think mostly due to sheer opportunity count.
  
  
• Deployment problems. Failed installs. Dealing with incompatibilities, suspect or compromised systems, etc. These issues are not insignificant. If they were, we wouldn't be forced to use so many less than stellar browser based applications.
  
  
• Bad personnel and platform decisions. Sometimes these mistakes will sink a software project the fastest.
  

What happens when mistakes are made?

When a mistake is discovered, my experience tells me that the first question many managers immediately ask is "who did it?" Something is out of whack and it shouldn't be. There must be someone to blame. And sometimes blame is good. The kind of mistakes that happen as a result of a lack of attention to detail are sometimes best handled through the blame game. Some harmless egg-in-face to keep the team on their toes. Checking in code that won't build, thus breaking the build process is an example of this. Find the knucklehead, and make sure everybody knows who it was. But what about mistakes that are harder to discover and come with larger consequences. What about a bug that slips through testing and happens to rear its ugly head just as the president of the company is presenting the newest features to a room full of prospective customers? Is a "head gonna roll" so to speak? Not in my company.

Instructive, Constructive and Destructive Criticism

The only reason to criticize someone at all is to motivate a person to change their behavior. Yet it seems inevitable that when things go wrong, emotions take over and managers often say things that were not thoroughly thought out, and when this happens, destructive criticism ensues. As a manager, strive to be constructive and instructive, not destructive. First things first, find out what really happened. All too often the wrong person or group bears the brunt of initial criticism. Apologies later cannot repair the damage that has already been done. Once you know what really happened, if there was a person or group that exhibited behavior that you think needs to be changed, by all means do it in private. And once you're in private, here are a few more tips.

• Avoid the word "not". Not is bad. Not will not get you results. "That's not right", "That's not how to do it", "You should not have done that". Use better ways to get your point across. "There might be a better way", "Maybe I could have been clearer when we discussed this", "There are many ways to accomplish this, and perhaps this approach would work better".
  
  
• Think before you say - "You should have [fill in the blank]". Hindsight is 20/20 and pointing out errors in retrospect is easy even for stupid people. Find a better way to point out how the doer of the deed could have done it better.
  
  
• Have patience. Never take away the mouse or rewrite someone's code during a code review. Nothing is more disrespectful. Either have the patience to instructively discuss how you think your ideas will improve things, or just leave it as it is.
  

So why worry about all this? What, besides hurt feelings, is the result of destructive criticism?

Lost Initiative

Quite simply, people will not display any more initiative than absolutely necessary if they think their efforts might lead to destructive repercussions. They will not strive for a better way to do things. They simply will stop trying or suggesting anything new. Marching pays the same as fighting so-to-speak. Innovation cannot exist without initiative. And if you're working in the world of competitive commercial software products, an innovative nugget from even the most junior member of the product team just might make the difference between the success and failure of your product.

Now by chance, if you have ever worked for the 3M Company, you're probably thinking to yourself - wait a minute… I've heard this before. That's because you have. I didn't come up with this stuff, but I wholeheartedly agree with it. William McKnight built 3M to prominence in the 50's and 60's with this basic rule of management:

"As our business grows, it becomes increasingly necessary to delegate responsibility and to encourage men and women to exercise their initiative. This requires considerable tolerance. Those men and women, to whom we delegate authority and responsibility, if they are good people, are going to want to do their jobs in their own way. 

"Mistakes will be made. But if a person is essentially right, the mistakes he or she makes are not as serious in the long run as the mistakes management will make if it undertakes to tell those in authority exactly how they must do their jobs. 

"Management that is destructively critical when mistakes are made kills initiative. And it's essential that we have many people with initiative if we are to continue to grow."

3M is not a software company, but I think Mr. McKnight's principles apply especially to software companies.

Software development is a field where we define "crap" as other people's code. That's pretty critical. Where managers too often have very little respect for the difficulty involved in the software development process, or the people that create the software. Combine this mindset with the many opportunities for mistakes in building software and you get… destructive criticism that leads to less initiative and no innovation. And that's the very stuff that a software company needs to be successful.

Brian