If software specs are so important, why do so many software teams skimp the most on specifications? Here's the politically incorrect skinny.

• It's very difficult to do it well
• It requires fighting with other people for their time
• Those people you fight with don't think you listen to them, so they don't want to help
• It requires time and money that managers don't want to spend
• Nobody finds it very entertaining, so they are never "in the mood"
• Perception is reality, and creating software, any software, is perceived as progress. Creating documents is not.

We all do this. We all skimp on specifications. To what degree we skimp is the differentiator. For most organizations, about 50% of all software projects fail. Projects fail for lots of reasons, but a consistent theme in post mortem analysis is inaccurate or incomplete software specifications. Is there truth to this, or is it just easier than saying our ideas suck? If there is truth though, we should conclude then…

Improving specification activities is the single best way to improve your software development project success probability.

And this should make logical sense too, since no matter how good you are at creating software, if you are creating the wrong software, it's irrelevant. But… you could also logically conclude that too much effort in specification is also bad. After all, you do have to eventually build something. So seek to find the balance, but don't skimp.

Everything in Software is Iterative

I do not think that it is possible to fully specify a software product before it is built. And most people agree with me too, as nearly all respected software methodologies involve some level of iteration.

Spec, Design, Build, Test. - Do it over again until you run out of features to add or money to spend.

Everyone does this. The primary difference between methodologies is merely the size of the iteration. Some like them big (think waterfall), some like them small (think agile). But regardless of iteration size, are your spec docs changed during an iteration? Are spec changes controlled? Here's a test to help answer that question. When you finished your last iteration, did your specification match the product? If it does, it was either a really good spec or it was alive.

The Difference that a Living Spec Makes

If your spec has been properly maintained, then it is alive. It's a living document. It has an owner. Someone on the team who actually cares about it enough to feed it, water it, and make it grow. When you update a spec, then design and build against the change, your changes are more thorough. That's because when you open the spec, you are again immersed into the application as a whole, not just the specific issue that brought about the need for a change in the original spec. The cross references and related functionality are again brought to the forefront of your mind and you start to analyze the change in its entirety and how it affects all of the application stakeholders.

The importance of keeping a living spec increases with the size and complexity of your software. But even if your team is me, myself and I, you will create better software if you write specs and maintain them throughout the life of your application.

So don't neglect your specs! Give that doc a pulse and you will end up with better software.

Brian

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

Chocolate or Vanilla? That's the question I posed to 24 kindergartens last week as I passed out holiday cupcakes to my sons class. For the record; 14 chocolates, 10 vanillas. Now a statistician would tell you with much bravado that clearly chocolate is superior to vanilla by a commanding 16.7%. A chocolate connoisseur might latch on to that statistician's conclusions and add a few choice words such as rich, delicious, moist, or dark to his commentary and be very convincing to the unbiased observer. But the real truth is that the correct answer to this question is purely a function of the person. Some folks just like chocolate more. No further analysis required. The question that I pose is this. Can we say the same for development platforms?

What would be the results if I asked 24 software developers, at random, whether they prefer .Net or Java. Clearly this question must be more than just a matter of choice. Clearly there must be some level of superiority here. Be it in inherent capabilities, tools, or hardware. Based on all the "statistics" I have seen over the years, I would guess that the answer to my question would yield a near even count for both platforms. Could it be that the choice of development platform for a new software project be as arbitrary to its success as choosing a chocolate cupcake over vanilla? Don't bet the farm.

Barring any technical prerequisites that would preclude one or the other (yes, they do exist), I stand by my prediction of results. Why is it then that about half of the professional development world writes in Java and the other half .Net? I think it's because both platforms are viable for most software solutions. The differentiator, just like the cupcakes, is in the people. The investment it takes to become really good in a particular development platform is great. And with technology, personal bias is all about knowledge of a given platform, or lack of knowledge of the alternatives. And when you look at a developer's career, they are never more eager to sponge up technology details than in the beginning. So it is with very few exceptions that a developer doesn't answer my question based on their developer roots. What platform were their first projects on? In a previous life, I worked a little in industrial automation and that world has their technology players as well. Multiple vendor platforms with specific strengths and weaknesses, but overall pretty equal. Engineers in that world have their preferences too. Modicon, Allen Bradley, Siemens. Their personal preference can almost always be mapped back to their first project.

For the record, I am a .Net guy. I am a .Net guy because I "grew up" using Microsoft development tools. C++, VB 4-5-6, Asp, Interdev, VS200x. Yes I have also written java code, but very little. Could I architect a good Java solution? I know I could. I know I could because I am a good developer. Classes are classes, patterns are patterns, and languages are just syntax, blah blah blah. Besides, I love the curly brace {J}. But I also know that I could build a far superior .Net solution in less time. And it not because I think .Net is far superior to Java. With .Net, I can just do. With Java, I'll know what I want to do, and then have to look up how to do it.

So what difference does all this make? Make your platform decisions based on your people, or your people decisions based on your platform and your software projects stand a much greater chance of being successful. And if this stumps you, find a 5 year old and offer him a cupcake to explain it.

Brian

Developers, Developers, Developers!

I wonder if Microsoft developers ever feel underappreciated. Having never worked there I can't say first hand, but judging from the antics of their chief exec, I'd bet not. Not every exec responsible for software endeavors share Mr. Ballmer's enthusiasm for our kind. If you bounce around long enough in this field, you will inevitably get a taste of both the yin and the yang of executive flavor for which I refer. In my case, the past employers that fall into the opposite spectrum of Mr. Ballmer are in that camp simply because they didn't know any better. Software, or should I say, the importance of software has a way of sneaking up on an exec. One day its pencils, ten keys, and typewriters, and then BAM! - You're in a meeting to negotiate this year's accounting system license agreement. Well, maybe I am exaggerating a bit, but for non-tech leaders, this creep happened, and some adapted better than others. And it's sometimes hard to fault them for their attitude towards developers. In the early days where their opinions were formed; it was all about their experiences. If their teams were good, and they successfully implemented software based systems that actually worked without first failing over and over, the bosses get the impression that it's easy and anyone should be able to do it. On the other hand, if their teams were lousy, and repeatedly failed, well, those developers are certainly not worthy of any kudos either. And then there is the yang for the yin. The exec that has presided over this technology creep with foresight. The creep was there for him too, but he creeped with intent. This exec recognized the competitive advantages that his software systems could achieve his company. This exec recognized the need to ensure that his development teams were better than his competitors and that this competitive advantage could significantly affect the organization's success. This guy is real and he's in Ballmer's camp.

For leaders who have "grown up" so-to-speak within the software process, their opinions are based on other factors, because their experiences were different. They understand far better than their non technical counterparts the great challenges (and great enthusiasms) of the software creation process. They understand developers, and understand that not all developers are created equal. They understand that while great coding might arguably be considered an individual endeavor, great software is definitely a team sport. The successful leaders in this group are also in Ballmer's camp.

In software, a good team of developers stand a chance of overcoming methodology weaknesses, dysfunctional project managers, and impossible schedules and yet still pull off miraculous success. But the best of everything else with bad developers… there's gonna be a big thud when the gantt hits the windshield.

So embrace your developers. Give em' a hug. Hell, stand center stage and at the top of your voice yell! Developers, Developers, Developer!

Brian

So the doorbell rings and I answer it. On the other side of the door is the Ice Cream guy. That's all that Schwans sells right? So I tell him before he says a word that I am not interested in buying any Ice Cream. "But wait" he says, while moving to stop the door from closing with his foot. "We sell more than just Ice Cream. Do you like pizza?" Well… yeah I like pizza, and so the discussion gets a new life. He then hands me his product catalog and lo and behold, they sell lots of things I like. So I start flipping through the pages and rattle off a few items. While I am doing this, he whips out his hand held device and starts punching 3 digit codes that correspond to the items I'm mentioning. When I finish, he goes out to his truck, brings back my items, and asks me how I'd like to pay. I say credit card, half expecting him to tell me that he can't take a credit card, I mean… he's at my front door for Pete's sake. "No problem" he says. I hand him my card and on the side of that same hand held device he slides my card through. And out from the very small wireless receipt printer strapped to his leg appears my receipt. I didn't even notice that printer at first, and I am usually pretty observant of electronic devices. He hands me my receipt and says his goodbyes. I close the door, and I am happy. And it's not because of all the good food I just bought that requires little to no cooking. That makes my wife happy. No, I am in la la land thinking about just how much fun it must have been to create the software application on that hand held. 3 digit codes, wireless printers, credit cards. Fun!

Yep, it happens to me all the time. I see software applications and I start wondering what it would have been like to create it, and how I might have done things better. This is because to me, few things are more fun than making software. Sure there are steps in the software process that are decidedly "funner" than others, but all in all, it's a blast, from specs to release. Fortunately I have been able to build lots of software through the years. The first time I got to write code that people actually used, I remember thinking, I can't believe I am actually getting paid to do this. For full disclosure, I wasn't paid much, but back then I probably would have worked for free if my boss had told me he couldn't afford to pay me.

I don't know how I would have ended up spending my days (and nights) had the solid state transistor never been invented, or had I been born 100 years earlier, but as a result of the advent of the modern computer and its solid entrenchment into all walks of business and commerce, I get to build great software for a living. So whenever the sun sets on my career and I take up the rocking chair, there is a very good chance that I too will get to udder the famous words of Thomas Edison.

"I never worked a day in my life. It was all fun".

And if the Schwan's guy ever shows up at your place, forget the pizza and go directly for the Black Jack Cherry Ice Cream. Product # 362.

Brian