Summary
I've spent most of my career in small companies, usually start-ups, doing software development under less than optimal conditions. I've got 15 or 20 years worth of (hopefully instructive) horror stories aching for an outlet. This is my first installment.

guerril´la
A member of an irregular, usually indigenous military or paramilitary unit operating in small bands in occupied territory to harass and undermine the enemy, as by surprise raids.
The American Heritage Dictionary of the English Language, Fourth Edition

What is Guerrilla Development?

I've spent most of my career in small companies, usually start-ups, doing software development under less than optimal conditions. So, when Bill Venners asked if I'd blog on artima.com I said yes! immediately since I've got 15 or 20 years worth of (hopefully instructive) horror stories aching for an outlet. This is my first installment.

Choosing the clever name for my blog page was the second most difficult task in all this (finding a picture of me that wouldn't frighten children was the only thing harder). I toyed with several catchy phrases, but most of them didn't convey the level of conflict and frustration that can be felt both inside the software organization and between the developers and the rest of the company. The more I thought about it, the more I realized the software department often played the role of The Loyal Opposition, holders of customer interests, keepers of the vision of the long-term company goals, and defenders of sanity in general. We were insurgents in our own company. We were doing Guerrilla Development.

Guerrilla Development
Software development in an environment unsupportive of the effort. The adversity can take the form of active management encumbrances (ridiculous budget constraints, time constraints, staffing constraints, and the like), or in passive resistance such as stonewalling by product management, marketing, sales, or training. Guerrilla Developers find a way to win, despite the odds, and work to prevent their project from becoming a Death March.

Understanding the Impact of Low Maturity

All of this might sound a little melodramatic to those working in mature software environments. If you are such a person, consider yourself lucky. Estimates vary, but somewhere in the neighborhood of 80% or more of all software development groups work at Software Engineering Institute (SEI) Level I Maturity. For those of you not familiar with the SEI maturity levels, here is a handy table. (Please credit SEI for crux of the information shown below.)

I've read numerous software engineering books over the years and while they might mention that most shops are at SEI Level I maturity, they rarely give insight as to what that really means. The vast inventory of software development knowledge is carefully cataloged in these tomes: most shops are SEI Level I shops, projects should begin with a requirements gathering phase, and here's a description of McCabe Cyclomatic Complexity, for example. All of these interesting points do not have the same importance. One of them, the fact that most shops operate in an environment that can easily categorized as chaotic, is vastly more important than all the other pieces of software engineering trivia.

Being at SEI Level I Maturity means that it is likely that your software department, and likely your whole company, is a complete mess. Only heroics and daredevil acts bring victories. There is no notion of control; there is only risk mitigation. There is no process; there are only people. Often, your goal is simply to survive to fight another day.

Consider the kinds of things I've heard over the years:

• "Three tech writers? Why do I need one?"
• "Quality? That's your problem!"
• "We need a new demo for a customer. Put everybody on it. He'll be here in a week. Oh, and your other schedule can't slip."
• "I thought your estimates where high so I cut them in half before submitting our bid. Consider it a 'management challenge'."

As you might be able to tell from the above, SEI Level I software development shops often exist within SEI Level I mentality companies. This imposes a special challenge for anyone wishing to make things better.

The Challenge of Leadership

Imagine the energy, planning, and determination it would take to bring an SEI Level I shop to even Level II where there is some process, some tools in place, and some measures to assist with scheduling, bug tracking, and testing. This is the challenge that most small companies that build software have.

Note that I'm not talking about software companies, necessarily. There is a significant number of companies that have a software development function, yet would not likely be described by their executive-level managers as a "software company".

• "We don't make software; we make mobile phones."
  Yet, most of what makes a mobile phone and its network function is sophisticated software.
• "We don't make software; we make equipment."
  It almost doesn't matter what kind of equipment we talking about anymore. If it goes into a modern factory, it needs software. It needs to communicate with the other pieces of equipment on the floor. Motion control is software controlled. Its status is monitored remotely with software.
• "We don't make software; we make cars."
  Cars are now rolling networks with dozens or even hundreds of embedded computers in them.

I've cited big things (phones, factory equipment, and cars) but the problems associated with software being a second class citizen in a company is actually more likely to occur in smaller companies making smaller products like coffee makers, microwaves, toys, bicycle computers, and other gadgets. Check out the book Embedded, Everywhere to see how pervasive computers have become and where this trend is taking us.

My Next Few Blogs

With the explosion of demand for software and a limited number of people adept at software development, we can expect many of these new shops to spring into existence at SEI Level I maturity and stay there for a while. What can we do about it?

In my series of blogs I'll talk about the state-of-the-art at the low-end of the software maturity scale. I hope to provide some insight into how things are, how they got that way, and how folks (like me, when I was doing it) try to introduce maturity and sanity into the system. You shouldn't write off every department or project that has profound troubles at a given point as a Death March. Quite the contrary, I believe that in every SEI Level I shop there is a Level II or Level III shop trying to get out!

I've had my share of ideas gathered over the years that I hope to share in future blogs. I look forward to hearing from the community on this. Please feel free to post feedback here or write me directly.

-- Scott

Resources

• The Software Engineering Institute at CMU.
• SEI's description of McCabe's Cyclomatic Complexity. Just for fun.
• McCabe's description of Cyclomatic Complexity. Even more fun, if you like that sort of thing.
• Embedded, Everywhere: A Research Agenda for Networked Systems of Embedded Computers, by National Research Council. See the description and my review on Amazon.com.
• Death March: The Complete Software Developer's Guide to Surviving 'Mission Impossible' Projects by Edward Yourdon. See the description and my review on Amazon.com.

Talk Back!

Have an opinion? Readers have already posted 12 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever B. Scott Andersen adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

B. Scott Andersen has 20+ years of experience in software development splitting his time between individual contributor and management. He is now a Principal Software Engineer with Verocel, Inc., a company specializing in helping safety-critical system developers attain certification for their products. The opinions expressed here are his own and he takes full responsibility for them... unless, of course, they are worth money, at which point they belong to his employer.