Describing the Software Development Process

Peeling an onion

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

]

  • Scott Sehlhorst

    Scott Sehlhorst is a product management and strategy consultant with over 30 years of experience in engineering, software development, and business. Scott founded Tyner Blain in 2005 to focus on helping companies, teams, and product managers build better products. Follow him on LinkedIn, and connect to see how Scott can help your organization.

6 thoughts on “Describing the Software Development Process

  1. I am new to your site, having found it looking for descriptions of MRDs and what is included.

    I am looking for where you think interface solutions should reside and with whom these solutions should be developed.
    I typically work with a product manager to develop task flows and screen flows, then include development in discussions when we are ready to solidify screen flows. From there, the PM and I (I am a UI designer) work to create hi-def screen designs, running these past developers to validate approach and constraints.

    In my present company there is a very different attitude about who develops screen flow and screen design solutions.

    Looking for other perspectives on this point.

  2. Barbara,

    Thanks for commenting and welcome to Tyner Blain!

    From your description, it sounds like you do two things – interaction design (as Alan Cooper would call it) when working with the product manager to define the requirements, and then interface design (visual, usability, IA?) in iterations with the developers.

    I think that interaction design plays a role in requirements – specifically in the ideation stage of determining which problems to solve with software. I also believe that the other design elements are more about execution/application of ideas, and fall in the “software design” bucket.

    Take a look at Software development process example for more details.

    I will update this post now to include a link – it’s definitely relevant.

    Thanks again for reading, and especially for commenting

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.