I love studying software development methodologies. After all, what is a methodology? It's someone's attempt to draw on past experiences to define a systematic process that will lead to fewer mistakes in the future. That's not Webster's definition, its mine. Most everyone else would probably mention "repeatable success" in their definition. I like mine better because I'll let you in on a little secret… are you ready… here it is… making good software is hard. And no methodology alone will lead to repeatable success. At the very least a critical analysis of every completed project should be done, and your methodology tweaked from lessons learned. The trouble is, too many teams don't even bother to do that. Critical self reflection is not something we as humans do very well.

Don't read me wrong, software teams need to follow a methodology, whether it's your own or someone else's. And there are no shortage of documented methodologies for you to choose from; Waterfall, Agile, Extreme, Scrum, RUP, Adaptive Software Development, Lean Development, to name a few. While repeatable success with an arbitrary team is the goal of a methodology, it is a lofty goal. My own experience says success is dependent more on people than methodology. This explains why some teams inexplicably succeed without any identifiable methodology. Good teams do their very best to improve with each project, and as a result their methodology improves.

Through the years I've been involved with many projects in varying capacities that utilized recognizable methodologies. I have my favorites, as I am sure you do. Methodologies are a lot like politics. You have extremes in Waterfall and Extreme Programming, with overzealous advocates who seem to shout with the loudest voices. And as with politics, the majority of us advocate for something somewhere in the middle. When I compare methodologies across the spectrum, the most significant difference between them is the degree of iteration. Software, by its very nature, is iterative. Something as abstract as software must be iterative. For most non-trivial software systems, you have to build it before you see its flaws, and I'm not talking about bugs. Conceptual flaws that are hard to foresee. Make no mistake; it's the risk of conceptual flaws that iterative software development seeks to mitigate. This necessity is all too often cloaked by descriptions of being "adaptive to change" in business. Business does not change near as fast as our perception or understanding of the business. And if you are building software, you are likely trying to automate, streamline, be more efficient/responsive, analyze, quantify, evaluate. For any of these business goals you better darn well know exactly what you are trying to accomplish before you try to create software. Far too many projects start without this understanding.

So how do you gain this understanding and build software that works? Iterations. For businesses that are well understood, methodologies with fewer iterations will work, regardless of the goal of the software, or even the size (in development effort). This is because a good, unambiguous specification can be written about something that is well understood. And developers can write good software from good unambiguous specifications. But without complete understanding, any software development process with few iterations will likely fail, and that is because the spec will not be very good. You just can't spec a process that is not well understood. The team will try, they will fill a document full, review it, and sign off on it because it will mention enough of what the decision makers really want out of this new software system. The developers will get it, scratch their head, ask a lot of questions, and then go build software, most likely filled with many conceptual mistakes. These projects performed in a Waterfall type methodology will always fail. When the software is delivered, it will be all wrong, and even if management is steadfast and funds the corrective iteration that fixes the software, the project will cost twice as much as forecast and will still be considered a failure. The less understood the business, the more iterations you need. If only it were all just about creating good software…

Managers and decision makers want to know how much a software project is going to cost. How much money will you spend up front just to gauge the risk? How solid are your estimates? Methodologies play a big part in these discussions as well. Folks I don't care who tells you otherwise, any software estimate made without a complete written spec is not an estimate at all. It is a guess. Sure, the more you guess the better you get at it, but dispense with the baloney and call it what it is. There is a reason why software estimating is often referred to as a Black Art. Software is extremely expensive to create and business people don't like to take risks based on a guess. Software methodologies must not only attempt to manage creating the right software, but it must also manage time and dollar estimates.

So how do you determine the best methodology? For established, continuous development software teams, I think it is their methodology. Sure they may have started from a known base, but with every development project they refine and improve to fit their product, environment, and people. So it is their methodology. But for new project development and consulting teams, what you do must be based on the specific project and its goals. For well known business practices, a methodology with fewer iterations and a heavy up-front specification process is best. These types of business scenarios are really easy for an analyst to identify too. Here's a real quick litmus test. Can the subject matter experts answer your questions clearly? Does every answer start with "that depends on…"? Ask three subject matter experts the same question, and compare their answers. For projects where the goals are less understood, go agile. And that means more iterations. Spec-code-test, do it again. This works because subject matter experts can see, drive, and evaluate software so much better than they can a spec doc. So give them software and then ask what needs to be changed and added. Do this enough times and you'll end up with conceptually correct software. Of course this too is dependent on the subject matter experts actually taking the time to perform an honest review. It pains me to say, but sometimes even that is extremely difficult to get accomplished. And without it, agile is no better than waterfall, at least from the goal of conceptual accuracy and risk mitigation. Everyone is busy this is true, but building good software is a team sport, and everyone on the team must play in order to achieve success.

So what does all this mean? Adopt a methodology that matches the business understanding of the project. Think in degrees of iteration. For most new software I tend to lean towards agile approaches, but don't get caught renaming your utter lack of any methodology for being agile. This is way too common. For well known business goals or projects porting legacy systems to newer technology, I would lean towards an approach with fewer iterations. There's very little risk there, so take the time to write a single complete spec. For your upfront efforts you'll end up spending less money in development.

Regardless of your chosen methodology, here is what you need to create conceptually accurate software.

1. You need a spec.
2. You need reviews by people who know what the software is supposed to be doing.

Do you have a spec? Any Spec? If not, you don't have a methodology you are flying by the seat of your pants. Weekly meetings, heck daily meetings, and whiteboards are fine, as long as the decisions are captured in the written word. If chicken scratch on the back of a Quiznos napkin is the best you can muster, photocopy it and distribute it to the folks that are going to create the code. You'll end up spending less on development for your efforts.

Get the reviews. People prefer to review software over documents. After distributing a specification doc, I once received feedback from a guy that our client identified as a subject matter expert for review purposes. His feedback was, "It's difficult for me to determine if this would work or not based on this document, so I'll have to reserve judgment until I see the software." Gee, thanks for the help. I asked for a new subject matter expert. You need that feedback though, so get it any way you can. The analyst or developer who thinks they know more than the client does is in dangerous peril. Ask yourself who are you are building the software for and who will determine whether it is right or wrong?

Software development methodologies exist to help us succeed in a difficult endeavor. They are no silver bullet, but just making an attempt to learn from past experiences and applying those lessons learned in future work will lead to greater software success.

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