Recently I was reading the book Domain Driven Design by Eric Evans and came across this quote that I thought was really interesting:
“Manufacturing is a popular metaphor for software development. One inference from this metaphor: highly skilled engineers design; less skilled laborers assemble the products. This metaphor has messed up a lot of projects for one simple reason—software development is all design. All teams have specialized roles for members, but overseparation of responsibility for analysis, modeling,design, and programming interferes with MODEL-DRIVEN DESIGN.”
When I was in school I was very fortunate to have a professor named Dr. Richard Paul Evans. Dr. Evans always seemed to have a very interesting and profound way of viewing the software development process. His class and insights made a strong impression on me and have helped shape the way I design and develop software.
The quote at the beginning of this post reminded me of a point that he made during this course related to the standard waterfall phases of a software project. He proposed that there was really no difference between the requirements, design, and implementation phases of software development. Separating projects along these different boundaries is arbitrary at best and harmful in many cases.
These boundaries are arbitrary because it is very difficult to describe or even demonstrate a difference between the activities performed during requirements and design. Sometimes the difference is described by saying that requirements are the “what” and the design is the “how”. Where this logic is faulty is that there are not clear boundaries around what software does and how it does it and the differences are very subjective. The “how” to one person can actually be the “what” to another.
As a very simple example a requirement may read: The system shall display a list of all of the books that have been checked out of the library. At first glance this appears to be a valid “what” should the system do requirement. However this implies that the system will provide an entire list of checked out books which is “how” the system should let the user know which books are checked out. The terms “what” and “how” are ambiguous in relation to software requirements.
The separation of a project into requirements and design phases in and of itself may not be harmful to a project, but in many instances it is accompanied by a division of labor. One team may perform requirements analysis, another design, and still another actually implements the software. In many cases the skill sets of these teams are not equivalent. This can be especially risky during the requirements phase where it is common for teams that are not as technically proficient or knowledgeable in the business domain to be tasked with creation of “requirements”. Sometimes this is even viewed as a non-technical and trivial task that takes little expertise.
The fallacy to this approach is the fact that this initial phase of software design, the so-called “requirements” phase, is the most critical. Decisions in the software development process are cascading in nature. Every decision made affects a myriad of other decisions further along in the design process. The earlier in the process the decision is made, the more important it is and the larger the impact on the overall design and success.
Most software developers take this for granted in regard to design and development. Create a strong design and find your mistakes as early in the process is usually the motto followed to prevent wasted or misdirected effort. However, this is not always the case with the “requirements” phase of the design. Many times it is accepted practice for another group to create a large document of “requirements” and hand them over to the design team to turn into a software product.
The decisions made in the first phases of design (requirements gathering) are the first and most important decisions in the process. It is important to the success of the project to pay very close attention to these decisions and to have the most knowledgeable members of the team involved.
The software industry has realized this accident of the software development process and responded with a new set of approaches to software development. Agile development processes deal with this issue by encouraging a close collaboration between the business users, designers, and developers on a software project during all phases of the project. The entire project is centered around continuous design and delivery with a very short feedback cycle. The term design here involves working closely with the business analyst to design the system and deliver working software. I believe this is a large part of why these methodologies are so effective and have gained so much traction in the field.
Essence of Code 