Even though they are not strictly necessary, metaphors help us understand the software development process by relating it to other activities we and society already know about.
Treating software construction (that is, everything between design and deployment of your software) as similar to building construction suggests that careful preparation is needed and illuminates the difference between large and small projects. A builder prepares to build a skyscraper one way, a housing development a different way, and a dog house a third way. No matter what the project, the preparation is tailored to the project’s specific needs and done conscientiously before construction begins.
If you emphasize quality in your project, you must emphasize construction practices for the overarching goal of those is simply risk reduction. Why is that so important? Data shows that purging an error by the beginning of construction allows rework to be done 10 to 100 times less expensively than when it’s done in the last part of the processes: during system tests or after release.
So, now that I've convinced you of the importance of planning for software development, what are the most important steps in preparing to build software:
Determine the Kind of Software you’re working on
Every project is unique, but projects do tend to fall into general development styles: Business Systems, Mission-Critical Systems, and Embedded Life-Critical Systems. Obviously, on real projects, we find infinite variations of those three themes, but they serve as guidelines to determine both planning strategies — like what life-cycle model to use, how deep your requirements must be, how much time you must spend designing, etc. — and construction tools — language, framework, environment, etc. — you shall use to deliver the best possible result for your project.
Define your Problem
The first prerequisite you need to fulfill before beginning construction is a clear statement of the problem that the system is supposed to solve. The problem definition should be in user language, and the problem should be
described from a user’s point of view. It sets a goal for both you and your team, less technical people, and, most importantly, your stakeholders can understand and look towards reaching.
The penalty for failing to define the problem is that you can waste a lot of time solving the wrong problem. This is a double-barreled penalty because you also don’t solve the right problem.
Describe your Requirements
Requirements describe in detail what a software system is supposed to do, and they are the first step toward a solution. Paying attention to requirements helps to minimize changes to a system after development begins. If you find a coding error during coding, you change a few lines of code and work goes on. If you find a requirements error during coding, you have to alter the design to meet the changed requirement.
Stable requirements are the holy grail of software development. With stable requirements, a project can proceed from architecture to design to coding to testing in a way that’s orderly, predictable, and calm. Unfortunately, studies show that the average project experiences about a 25 percent change in requirements during development, which accounts for 70 to 85 percent of the rework on a typical project.
Thus, you will never be able to have perfectly described requirements, but the ones you describe correctly will help you plan, develop, and deliver far faster than you would without them.
Build your Architecture
Software architecture is the high-level part of software design, the frame that holds the more detailed parts of the design. A well-thought-out architecture provides the structure needed to maintain a system’s conceptual integrity from the top levels down to the bottom and it partitions the work so that multiple developers or multiple development teams can work independently. Good architecture makes construction easy. Bad architecture makes construction almost impossible.
Some typical architectural components you should pay attention to are Program Organization, Major Classes, Data Design, Business Rules, User Interface Design, Resource Management, Security, Performance, Scalability, Interoperability, Internationalization, Error Processing, Fault Tolerance, Architectural Feasibility, Overengineering, Buy-vs.-Build Decisions, Reuse Decisions, and Strategy Changing. If you can plan for all of those things ahead, half of your project will be complete before you begin.
In the end, when you look at the architecture, you should be pleased by how natural and easy the solution seems. It shouldn’t look as if the problem and the architecture have been forced together with duct tape.
Choose your Programming Language
Studies have shown that programming language choice affects productivity and code quality in several ways:
- Programmers working in a language they’ve used before are from 30 percent up to three times more productive than those with minimal to no experience in that language;
- Programmers working with high-level languages achieve better productivity and quality than those working with lower-level languages.
The Sapir-Whorf hypothesis says that your ability to think a thought depends on knowing words capable of expressing the thought. If you don’t know the words, you can’t express the thought and you might not even be able to formulate it. So, choose a language that you (and your team) know the words of and, more even so, that has the words you will need.
Compromise on Coding Conventions
Before construction begins, spell out the programming conventions you’ll use. Coding-convention details are at such a level of precision that they’re nearly impossible to retrofit into software after it’s written. Most of the important programming principles depend not on specific languages but on the way you use them. If your language lacks constructs that you want to use or is prone to other kinds of problems, try to compensate for them by inventing your own coding conventions, standards, class libraries, and other augmentations.
Remember that good programmers, those who program “into” a language, first decide what thoughts they want to express, and then they determine how to express those thoughts using the tools provided by their specific language.
Code
After you plan for all of those, it’s finally time to code! Just don’t forget the things you planned for and toss those out because it is easier to code one way or another. Those are your guidelines, follow them.
As was said in the beginning, the overarching goal of preparing for construction is risk reduction. So, a final tip is to be aware that your preparation activities are reducing risks, not increasing them. More construction practices exist than you can use on any single project. Consciously choose the practices that are best suited to your project.
The whole content of this article was created based on Steve McConnels’s book Code Complete 2nd Edition, so every piece of data pointed out has the source pointed out in the book and it is the main reference for this article.
Top comments (0)