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.
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.
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.
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