Sponsored Link •
|
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.
Advertisement
|
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
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.
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.)
Level | Focus | Key Process Areas |
---|---|---|
5 Optimizing |
Continuous process improvement |
Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies |
4 Managed |
Measurements and analysis |
Detailed measures of the software process and product quality are collected. Both the software process and products are quantitatively understood and controlled. |
3 Defined |
Process standardization |
The software process for both management and engineering activities is documented, standardized, and integrated into a standard software process for the organization. All projects use an approved, tailored version of the organization's standard software process for developing and maintaining software. |
2 Repeatable |
Basic project management |
Basic project management processes are established to track cost, schedule, and functionality. The necessary process discipline is in place to repeat earlier successes on projects with similar applications. |
1 Initial |
Competent people and heroics make it all happen |
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:
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.
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".
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.
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
Have an opinion? Readers have already posted 12 comments about this weblog entry. Why not add yours?
If you'd like to be notified whenever B. Scott Andersen adds a new entry to his weblog, subscribe to his RSS feed.
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. |
Sponsored Links
|