Design First before Development
It is always a balance between designing a system and developing the system. There is a prominent saying that goes “design a little, code a little”.
First things first, the content represented in this article is a combination of my ideas on what I think of the subject matter, copies of actual texts from this article and this article, salute to authors of those articles as they inspired the writing of this article. Hope you enjoy reading it.
I design and develop software systems. In the process of developing systems, there is always a misconception of thinking that one can develop a system without developing a design for the system first. It is at other times thought that one can develop a system alongside designing, which is a bad strategy.
“Coding and designing software programs are two different steps.”
Most developers including me, we often desire to jump to development before designing and later develop designs that we adjust to fit in the programs we have written. I call this reactive development.
As Alan Lakein said it “Failing to plan is planning to fail”.
So whenever a software developer or engineer does not put designing first for any project, however small. The developer is already paving a way for the sofware to fail and the software developer themselves to fail which in turn affects the company.
Wait a minute, we haven’t defined designing and how it impacts software development. According to wikipedia, Software design is the process of envisioning and defining software solutions to one or more sets of problems. From the definition, we have about three key important words, process, envisioning and defining;
According to the Cambridge Dictionary,
envision is to imagine or expect that something is a likely or desirable possibility in the future.
According to the Oxford Dictionary,
process is defined as a series of actions or steps taken in order to achieve a particular end.
define is to describe the meaning of something …, or to explain something more clearly so that it can be understood.
So designing involves coming up with a series of steps that represent the structure and steps of how a software system will look like during development and once it is developed. This involves but not limited to, control flows, ERDs, architectural diagram for deployment, sequence diagrams among others. With all this in place, the problem at hand is half-way solved, which clearly indicates that all good software systems are achieved at the design level and not at the coding (implementation) stage.
Developers who partially practice design or fully miss out on designing always do this in these ways:
- They simultaneously try to design and code (an approach known as “design-a-little, code-a-little”)
- They rely too heavily on the programming language constraints when developing the logical design of the program
- Too much pressure to meet deadlines, often bosses demand more shipping out of systems to market than encouraging designing of better systems before development as this increase the time taken to ship out software projects.
- They skip the design step completely because they think the project is “too easy,” or they have overconfidence in their abilities, a.k.a, “I am too smart.”
This kind of rush to code can backfire and ultimately cost more development time, as a poorly designed program is likely to result in many errors that could have been avoided through careful planning.
In Chris Richardson article titled CxOs neglect architecture at their peril, he narrates why architecture (for our case let’s substitute the word architecture for ‘design’ to represent our context of designing in general) is important in software development and a step that must be done before any developer jumps into actual implementation.
If you use the design-a-little, code-a-little approach, you will probably have to erase or retype a lot as the design keeps changing. Your program will be twice as long and half as efficient as it should be. It can be a grand mistake to assume that skipping the design phase of your program will speed up the development process, and you will have your system up and running in no time.
To quote Brian Foote and Joseph Yoder, “If you think good architecture is expensive, try bad architecture.”
Further in Chris Richardson’s article, he points out what neglecting designing can do to an organization or any software system, he talks about the catastrophic incident that happened to Southwest airlines due to the fragile state of its scheduling system, where a delay to numerous flights due a severe winter storm, caused the scheduling system to collapse under the load of rescheduling planes and crews. The result was a nightmare for travelers and flight crews. It also costed the airlines a billion dollars.
The key to building economic code for any system is to take the time to systematically design your program before writing a single line of code. This may include designing architectural diagrams, ERD, control flow and flow charts, pseudocodes, other dependencies). With systematic designing (structured Programming), you reduce on the memory occupied, processing time, and generally code runs correctly at the first trial.
With systematic designing we have a thorough understanding of the problem as we have broken down the problem with a top-down analysis and understand all the smaller, smaller pieces of each unit and how each fits and works with each other. Doing this give a clear picture of how the program/ software will work in isolation and when integrated, how much man power will be needed to develop the system and under what time frame. With all this, it give a clear estimate on all the resources needed and the constraints and how to overcome them.
“Always Design first before Development”
References