Software development process standard operating procedures

Some long time ago I was working on a large software development project, and I wasn’t happy with either the quality or the velocity of our programming effort. So one night I sat down and tried to work out an activity diagram to show what our software development process needed to be, to improve both speed and quality. It turns out that a lot of this is just common sense, but for some reason or another team members would try to circumvent the process, which always led to more pain for everyone involved.

The diagram I came up with is shown in this activity diagram image. If the diagram doesn’t make sense on its own, this is what I’m trying to express:

• In the first step, a new desirable application feature is “discovered” or requested. (I’m going to skip the part where you probably have a backlog of new features that are prioritized.)
• These next steps can occur in parallel: the requirements are specified, and may be captured in use case form, or may be lighter-weight user stories with corresponding requirements; a prototype is created (for UI elements); and the feature owner creates a plan for how they’ll test the new feature. When I work on a use case or user story, I also look at the database and try to quickly write some database queries (or at least pseudo-queries) to check that we have all the tables and fields we need. If we don’t, you know you need to add them. Given my history with Function Point Analysis, I also make a quick count of the function points, which I use for estimating the time and cost of this new feature.
• Next, the design is reviewed with the necessary team members. This can include the goal donors, project sponsor, project managers, and developers, but the goal is to invite as few people as are sufficiently needed (as opposed to everyone that might be loosely related).
• Once sign-off on the feature design is obtained, one or more developers begin working on implementing it. Developers are free to raise additional questions and suggestions for improvement as they work. Ideally, another developer provides a quick test of their work, and once all preliminary bugs are worked out, the feature is released to the goal donor for their acceptance. (In some organizations testing may be conducted by a formal testing team.)
• Throughout the development process, questions are raised, and bugs are entered and fixed. Most importantly — and unfortunately something I don’t show here — everyone has to be open to a better way being discovered during this process. This can be really frustrating for developers, but a lot of times the person using the feature won’t really know what they want until they get something in their hands. This phenomena is known as IKIWISI, or “I’ll know it when I see it.”
• With understanding parties on all sides of the development equation, this process results in a very good product being delivered to the consumer.

All of that may sound like a heavyweight process to you, but it really isn’t; it’s really just common sense. But for some reason people on a team will try to circumvent this process, and when they do, it always leads to pain.

For instance, let’s say a developer doesn’t test their own code, or they don’t have another developer help test their code. This leads to a lower quality product being delivered to the goal donor. An effect of this is that it lowers their morale and their opinion of the developer.

Or, let’s say for some reason the design review is skipped. Guess what? You just left out an interested third-party who is going to balk later on. Or maybe the developer misunderstood the goal donor, and they go off and develop the wrong feature.

Standard operating procedures

Does this sound boring? Good, it should be!

This stuff should be SOP: Standard Operating Procedures. But for some reason a lot of people think this is a creative process. Guess what? It's not the process that’s creative, it’s what you do within the process that’s creative. The new ideas for the application, refactoring of the code, etc.

For me, keep everything as light and agile as you possibly can, but SOPs are just a framework to keep things running smoothly. If you have a better SOP than what I've shown, that’s great, use it. Just have one. Without some form of repeatable process all you’re really doing is just hacking and hoping.