On day 2 we will look into chapter 3 and 4.
For more in depth notes of the book, please purchase the book!
Chapter 3 Measure Twice, Cut Once Upstream Prerequisites
This chapter describes the work that must be done to prepare for software construc-
tion. As with building construction, much of the success or failure of the project has
already been determined before construction begins. If the foundation hasn’t been
laid well or the planning is inadequate, the best you can do during construction is to
keep damage to a minimum.
This chapter discusses software equivalent of blueprints
and construction permits. You might not have much control over preparations, so the focus of this chapter is on assessing what you have to work with when
construction begins.
Key take away
It is good to plan to specify requirements up front.
Essentially, you’ll need to pick the right balance for your project. If it’s something more stable, where the requirements are well understood and unlikely to change, a more sequential approach is appropriate. But if the requirements may change, or the structure isn’t as well understood, then a more iterative approach will be more beneficial.
The overarching goal of preparation is risk reduction
Most common project risks in software devel-
opment are poor requirements and poor project planning, thus preparation tends to
focus on improving requirements and project plans.From a technical point of
view, planning means understanding what you want to build so that you don’t waste
money building the wrong thing.Explicit requirements keep you from guessing
what the user wants.Explicit requirements also help to avoid arguments. You decide on the scope of the
system before you begin programming. If you have a disagreement with another pro-
grammer about what the program is supposed to do, you can resolve it by looking at
the written requirements.Software being what it is, iterative approaches are useful much more often than sequential approaches are.
Handling Requirements Changes During Construction
- Use the requirements checklist at the end of the section to assess the quality of your requirements If your requirements aren’t good enough, stop work, back up, and make them right before you proceed.
- Make sure everyone knows the cost of requirements changes, work up a revised schedule and cost estimate so that you can decide whether you want to do it now or later.
- Set up a change-control procedure If your client’s excitement persists, consider establishing a formal change-control board to review such proposed changes. It’s all right for customers to change their minds and to realize that they need more capabilities. The problem is their suggesting changes so frequently that you can’t keep up
Chapter 4 Key Construction Decisions
This chapter focuses on preparations that individual programmers and technical leads are responsible for, directly or indirectly. It discusses the software equivalent of how to select specific tools for your tool belt and how to load your
truck before you head out to the job site.
Programmers may be similarly influenced by their languages. The words available in a
programming language for expressing your programming thoughts certainly deter-
mine how you express your thoughts and might even determine what thoughts you
can express.
Your programming tools don’t have to
determine how you think about programming.Programmers who program “in” a language limit their thoughts to constructs that the language
directly supports. If the language tools are primitive, the programmer’s thoughts will also be primitive.Programmers 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.
Your position on the technology wave determines what approaches will be effective or even possible. Identify where you are on the technology wave, and adjust your plans and expectations accordingly.
Establish programming conventions before you begin programming. It’s nearly
impossible to change code to match them later.Every programming language has strengths and weaknesses. Be aware of the specific strengths and weaknesses of the language you’re using.
My thoughts
- Its hard for programmers to adopt to the test first approach.
- Ensuring the programmer has stepped through their code in the debugger before they check it in is not easy.
Top comments (0)