Diary of a Software Manager

Process is one of those words that many developers fear. I’ve developed in small and large environments with varying amounts of process.

I spent my first 7 years as a developer in one of the most process heavy environments imaginable. During an orientation session for our department (we were required to attend one annually along with ethics classes, Six Sigma training, varying other required training programs along with 40 hours classes on our own time), after the instructor went through the entire development cycle over the 8 hours of class time, a new developer asked “So when do we actually write code?” I wish it was as dumb a question as it sounded. The actual development of the code wasn’t really covered. What was covered in great detail were the various checkpoints along the way that were deemed necessary to produce quality software. In practice, 80% of your day was spent filling out forms and writing documents and scheduling meetings with stakeholders. The QA department never actually did any testing, they just sat with you during acceptance tests to make sure you had checked the various boxes deemed necessary.

When it came to actually developing code, most developers just completely ignored the UML diagrams developed in the preliminary and detailed design phases. Just having UML diagrams was enough for QA and they couldn’t really determine if they were actually used in the design at all because they were not technical at all. QA was just there to make sure all the boxes were checked and having a couple boxes with lines between them served as proof that those bits of the process were followed. There are few things more frustrating for an engineer than to watch such a large amount of inefficiency and waste run rampant in an organization. You either fooled yourself into thinking it was necessary or quit and found someplace to work. The more that I started to understand about software development, the more this drove me nuts and I eventually left.

When I left I moved to a far, far smaller company that had very little process. A QA department had just been introduced and in my first week I wrote as much code as I would in a month at my previous job. Of course, these changes were released without anyone testing them and rendered useless the product I was developing for. Most arguments I heard from management against introducing any process were of the “it will only slow us down” nature. I heard “I’m not interested in having a bug-free product, I’m interested in having a product I can demo and sell” more than once. Over the course of a year we slowly introduced a small amount of process that we called “agile” though we were only really doing the daily standup bits, not any of the other practices. What inevitably happened is we were introducing products really quickly which excited sales. We then spent the next 6 months trying to get them stable in the live environment that frustrated our customers and rendered new development efforts completely ineffective.

The right amount of process is different for every organization. I’ve heard arguments for jumping into development methodologies full-bore. Depending on your organization, you may be able to do that. For me, it seemed like a more gradual switch to the Agile methodology was the way to go. I don’t think any methodology is perfect and you should make an effort to notice what your organizational strengths are and play to them. The important thing is to do when introducing a process is to:

• Decide what things you are currently doing that are successful
• Define the current nagging problems you have that are hampering your development efforts
• Pick a methodology and move towards it in a way that allows you to use your current strengths (we chose Agile/SCRUM)

I’ll post a Part II soon that details how our organization moved toward a development process