One of my goals is to distill the complex down to its simplest form – without losing meaning or applicability. The challenge in creating one model that describes the entirety of software development is that it must allow for the multitude of software development processes that are already in existence. And it must stand the test of time, allowing for new approaches that haven't been invented yet to fit equally well.
To me, this means that the model must be general in nature; it should appear to be simple, yet capture the complexity and realities of software development. This took a bit of thinking on my part, but who said that this was going to be easy?
My model was developed from the observation that there are really two constants involved with software development. First, there are some fundamental steps involved with software development. Second, there are people involved in the software development. Nothing new under the sun here. I categorize both as:
- Software Development Activities
- Software Development Personnel
Software development activities are the steps that are involved with writing any software, starting with the inception of a project to release, whereby the product can either be enhanced with new features or maintained by fixing defects. The basic activities of software development, regardless of the software development methodology being used are as follows:
Before any code is written, there should be definition about what the software is expected to do. This information is utilized in the initial design, both of which informs and guides the actual construction and testing of the software, resulting in working code.
Of course, there is always planning and estimating that can occur at various stages. This includes any re-planning and re-estimating because the situation is changing or reality is setting in, and everyone is beginning to realize that the DATE that was thought to be so achievable is suddenly not so achievable.
Software also lives beyond any project – unless the project is killed. In fact, software (particularly large-scale systems) will spend more time in maintenance than in actual development. My position is that a system test at the end of a project has effectively placed the software in maintenance mode.
Note that there are no arrows or implied flow between the activities. Think of them as cards on a table that can be moved around as needed. For example, a waterfall approach to development will strive to have design complete before any coding, and the process will flow from left-to-right as shown. On the other hand, the use of Test-Driven Development (TDD) will require that a test be written before any actual coding is performed.
Obviously, all of these software development activities require that someone is performing those activities...
Software Development Personnel
Software isn’t about satisfying the needs of computers, it’s about meeting the needs of the customer – the user(s) of the software. Businesses, which oddly enough are comprised of people, provide the initial input into the process by articulating their needs. Some type of development process kicks into gear that captures those needs and produces working software, all through the talents and efforts of people.
Depending upon the size of the project, there could be as few as one to as many as thousands involved in the actual production of the software. The people side of software development can be characterized as primarily dealing with the attributes and interactions associated with the individuals, teams, and the organization as a whole; this includes things like business knowledge, programming skills, critical thinking skills, communication skills, teamwork, and motivation.
While software development activities and personnel are separate entities, they do not exist in isolation. In fact, they are inexorably linked and dependent upon one another for achieving maximum results. This leads me to my model…
Yes, using a DNA analogy to describe the “theory of everything for software development” works perfectly! (Well, for me it does.)
DNA is often referred to as a recipe or code, something that carries the genetic information used to construct other things. Similarly, the strands of software development activities and software development personnel are intertwined and bonded together; neither can exist without the other, and output (working software) cannot be produced without this fundamental arrangement.
The inputs can be anything that informs the project team, from the business vision, priorities of the feature set, constraints such as the budget, information about the competition, and influencing factors such as the tone and environment that the project team works in.
There are limits to my model. While any software development methodology can be used, the model doesn't explain which one to use, and under what circumstances one methodology should be chosen over another. The model is really describing the core, genetic software development material that can take many forms in actual practice.
When it comes to selecting a methodology, my feeling is that you need to make that call based on the goals and objectives of your project. There are times when the extra expense and overhead of finely-detailed requirements, design, and considerable testing are worth the effort. Being off a dollar or two on an insurance quote is one thing, but being off a degree or two with a nuclear missile is another. "Good enough" isn't always good enough.
The intent of my model is to strip away the methodology from the essence of software development. A methodology is a means to an end, one way of creating software, and each has something of use to offer. What is important is to understand the true nature of software development and the types of problems that a given methodology is attempting to address through its unique approach.
I also feel that it is important to recognize that methodologies alone aren't the only consideration when dealing with software development. The people that are involved with software development are a vital component and a major variable.
Different people have different strengths, weaknesses, and preferences. Everyone has different communications styles and approaches to their work. And when people are combined in a team, the interaction dynamics that occur can amplify strengths and magnify weaknesses, creating unique situations that can increase productivity or plant the seeds for outright failure.
The DNA of Software Development model and this blog are about confronting these realities. I would love any feedback that you may have!