Describing the Software Development Process

Describing the software development process

Software development involves determining what to develop, documenting this decision, determining how to develop it, and actually developing it.

• How do we separate these very different processes so that we can talk about them?
• How do we staff a team to accomplish them?

We present a framework for describing this process in terms of layers of activity. Many people use pyramid analogies, which show the magnitude of effort in each layer (lines of code versus lines of requirements, for example). Many other people use inverted pyramids to reflect the importance (or impact) of work done at different layers (a sentance defining a strategy has more impact than a line of code). Some people show PERT diagrams of waterfalls or pretty circular arrows charts showing iterative lifecycles, or any of many good analogies.

We think of it as an onion.

When describing any software, we can discuss the software at any of multiple levels of abstraction. The heart of the onion is a secret to those who never cut onions – they only see the outside. The center is strong, but if you aren’t used to it it can make you cry.
Different people in an organization will discuss a software solution at the different layers. It isn’t because they are unable to discuss at a different level, it is because the level they discuss it at is most germaine to the decisions they are making. A developer will make decisions that are much more focused than a CIO. And a product manager will apply policy decisions at a different level from either of the others.

We will describe out framework in terms of different layers of abstraction. We’ll start at the inner level, or smelliest part of the onion and work our way out to the skin. We’ll move from the concrete to the abstract. From the implementation details to the goals.
The layers of abstraction

1. Implementation. The actual code that is written and running. The user interface that is presented. The tests that are included in a regression suite. We do what we’re asked, in the way that we’re asked.
2. Design. The architectural description of the implementation, UI and test suite. Design decisions define much of the reality for developers – good design decisions make implementation and maintenance easy. Bad design decisions can make for disaster.
3. Requirements. Different processes will use different names for these. In a process that uses structured requirements, this is the functional requirements, user requirements and business requirements. These can be captured in an FRS, SRS, or PRD (but please no, not all three!).
4. Market analysis. The problems or opportunities that express potential ROI opportunities. These can be captured in an MRD.

How do organizations handle this?

Most software is driven from the top down (4,3,2,1) and it can be like peeling an onion. First identify a value prop. Then figure out how to achieve that value in software. Create a design that will work, and implement it. Each step is peeling another layer from the onion.

There are exceptions to this rule – many startups have a “this is cool, what can we use it for?” mindset. Also, more mature businesses will often task someone with leveraging existing assets – which means “find out how to make more money from what we already have.” There are absolutely good examples of this both in software and in hardware. But that’s really not what software processes target.

Different people in the organizations have different responsibilities – they tend to operate exclusively at one layer of our framework or at most two layers.

Wearing one hat or two?
Looking at common roles within companies or on projects, we often find people doing two of the jobs in our four-layer framework.

• Design/Implement is a common pairing (combining 2 & 1). Architect/developer is a practical and common senior position. The skills required to design and implement are complimentary – one is expressly a superset of the other.
• Market/Spec is another common one (combining 4 & 3). A product manager often plays both roles (outbound and inbound are the industry jargon terms for “focus on the market” and “focus on the product”). There are synergies between understanding what problems need to be solved, and identifying what problems need to be solved with software.

A bad idea is combining the roles of “decide what to do” and “decide how to do it”.

• Spec/Design is rarely done intentionally. We’ve done this once, and succeeded only because we rigorously separated the two roles. Technically, I played a Spec/Design/Implementation role, while managing other developers and building a relationship with the clients. We do not encourage staffing people with this combination of responsibilities. It is no more natural as juggling while swimming.

Final thoughts

There are four roles in our framework, from identifying valuable opportunities to writing great code. It is a good idea to combine design and implementation responsibilities in a senior person on the development team. We would have avoided our requirement writing mistake if we had done that on our previous project. Combining inbound and outbound product management responsibilities makes sense for smaller teams and exceptional individuals.

Asking the same person (or the same document) to define both what software should do and how the software should do it is a bad combination for any but the most nimble switch-hitter. Shakespeare would qualify as a nimble switch-hitter.

[Update: We’ve created a few followup posts that talk about these topics in more detail

• Foundation series: User experience disciplines
• Software development process example
• Requirements versus design – which is which and why
• Software requirements – process and roles

]