More on this book
Community
Kindle Notes & Highlights
Many powerful programming techniques hide in journals and academic papers for years before trickling down to the programming public.
The claim that construction errors cost less to fix is true but misleading because the cost of not fixing them can be incredibly high.
The irony of the shift in focus away from construction is that construction is the only activity that's guaranteed to be done.
Construction is the central activity in software development. Requirements
A heuristic is a technique that helps you look for an answer.
A heuristic tells you how to discover the instructions for yourself, or at least where to look for them.
The letter-writing metaphor suggests that the software process relies on expensive trial and error rather than careful planning and design
In incremental development, you first make the simplest possible version of the system that will run.
Paying attention to quality is also the best way to improve productivity.
By far the most common project risks in software development are poor requirements and poor project planning, thus preparation tends to focus on improving requirements and project plans.
From a management point of view, planning means determining the amount of time, number of people, and number of computers the project will need.
The iterative approach absorbs rework piecemeal over the course of the project, which makes the total cost lower.
A problem definition defines what the problem is without any reference to possible solutions.
The problem definition lays the foundation for the rest of the programming process
The best solution might not be a computer program.
Be sure you know what you're aiming at before you shoot
Requirements describe in detail what a software system is supposed to do, and they are the first step toward a solution.
Explicit requirements keep you from guessing what the user wants.
If you find a requirements error during coding, you have to alter the design to meet the changed requirement.
Without good requirements, you can have the right general problem but miss the mark on specific aspects of the problem
Stable requirements are the holy grail of software development.
Requirements are like water. They're easier to build on when they're frozen.
A plan to follow the requirements rigidly is actually a plan not to respond to your customer.
If you're not heading in the right direction, stop and check your course.
Clients get excited when they think of a new feature.
It's all right for customers to change their minds and to realize that they need more capabilities.
Evolutionary delivery is an approach that delivers the system in stages.
Think about how much worse it would have to get before you would cancel it.
Many requirements issues disappear before your eyes when you refer back to the business reason for doing the project.
Are all the tasks the user wants to perform specified?
Is the level of security specified?
Is the definition of success included? Of failure?
Are the requirements clear enough to be turned over to an independent group for construction and still be understood? Do the developers think so?
Is each item relevant to the problem and its solution? Can each item be traced to its origin in the problem environment?
Is each requirement testable? Will it be possible for independent testing to determine whether each r...
This highlight has been truncated due to consecutive passage length restrictions.
Are the requirements complete in the sense that if the product satisfies every requirement, it will be acceptable?
Are you comfortable with all the requirements? Have you eliminated requirements that are impossible to implement and included just to appease your customer or your boss?
In the architecture, you should find evidence that alternatives to the final organization were considered and find the reasons for choosing the final organization over its alternatives.
The architecture should define the major building blocks in a program.
The architecture should specify the major classes to be used. It should identify the responsibilities of each major class and how the class will interact with other classes.
The architecture should describe other class designs that were considered and give reasons for preferring the organization that was chosen.
The architecture should describe the major files and table designs to be used.
The architecture should estimate the resources used for nominal and extreme cases.
The architecture should provide estimates and explain why the architects believe the goals are achievable.
Scalability is the ability of a system to grow to meet future demands.
Is error processing corrective or merely detective?
Is error detection active or passive?
How does the program propagate errors?
What are the conventions for handling error messages?
