House of Software Development

We've started a software developer's book club at work, and our first book is Code Complete, 2nd ed. by Steve McConnell - probably the highest recommended book on software development today.

Our division is just starting to organize itself from a staff-augmentation focus where we'd help out clients with relatively quick and easy programming solutions to a structured software development focus. It's more of an attitude shift than a job-type shift, really. We aren't going to start selling shrink-wrap, we're just going to start laying down some procedures and standards and a methodology of sorts.

Coincidentally to reading the first chapter which reviews the major aspects of software development and discusses different analogies (including that of building a house), my boss asked me last week to basically define my own role in the new hierarchy, which itself is still being defined daily.

So, I smartly put together the following diagram based on Steve's ideas, and told my boss that I wanted to be improving techniques and finding tools for the "green level" in the cartoon below, and as my career progressed, I wanted to move into the "blue level". He has a software background from a decade ago (COBOL), and knows essentially what it's all about, but I think he was really impressed with the clarity and completeness of the analogy. Suffice it to say, he forwarded my silly cartoon (which he loved, since he has a good since of humor) to the group including the text that said I was in charge of the "green level" and would later be in charge of the "blue level". Nice :) Now I owe Steve a bottle of champagne, too.

This is the house of software development. Like any building, the house is only as good as its foundation, and as you continue building to the roof, the higher levels are dependent upon the lower. There are other components not shown here since they are outside of our group (like infrastructure, which would be like the plumbing, and sales, which would be like the people living in the house who are trying to sell it).

The different color gradients represent different roles or responsibilities.

  • Purple – Problem definition, and requirements gathering are done by a business analyst. Output includes scope, functional spec.
  • Light Blue – the design and architecture are done by a senior developer by using the documentation of the lower level. Output for this level includes technical spec and may include the database and data logic on medium to large projects. This level sets the tone for the rest of the project (decides if dedicated testers needed, what level of testing needs to be done, what procedures need to be used, number of developers needed)
  • Green – the programmers take the documentation produced by the lower tiers and start constructing the code. Output includes code, GUI, and possibly unit tests depending on small to medium sized projects; larger projects may have dedicated testers.
  • Orange – the overall testing, support, and QA/QC sits on top of the house. The system testing includes pre-release testing, issue tracking, and post-release support. This role has the final say on quality and effectively signs off on the project. When issues come in post-release, this role directs those issues back to the green band for corrective maintenance, but provides the tool for tracking issues.

0.02 QA

Thanks, Aaron; I'm glad you appreciated the cartoon! I think you're right on that the QA should be more prominent.

In the smallish consulting projects that I'm usually involved in, the senior dev would do some code reviews, and the devs would do the testing. Even so, I think that showing how QA is part of the whole process is valuable.