This post is part of a series of posts with my personal notes about the chapters in the book “The mythical man-month” by Frederick P. Brooks. I write these posts as I read through the book, and take notes on the concepts I find more relevant. I do, however, advise reading the book to get the full benefit out of it.
In this chapter, Frederick P. Brooks, tells us about performance requirements. Of course, the context was different, so the examples and terminology need some translation to today’s context…
Nevertheless, the lessons learned back then are still valid today:
Like any cost, size [infrastructure] cost itself is not bad, but unnecessary size [infrastructure] cost is.
Criticizing infrastructure costs in itself is foolish: one must also ask “why is it needed?”, “what do we get in return?”, “what product requirements make this infrastructure needed?”.
Set total size budget as well as resident-space budgets. Set budgets on backing-store accesses as well as on sizes.
Back then, both the size of an application and the number of times it would access the disk were critical, so there had to be scrutiny to both, which was implemented ed in the form of limits.
Nowadays size and disk accesses might not be as critical, but I can perfectly relate this principle to:
- Total response times => have monitoring in place and permanently displayed;
- Individual test execution time => define a time limit for individual tests to run;
- Total test suite execution time => keep total test suite execution time under a value;
- N+1 problem => permanently monitor and detect N+1 problems;
- …
Specify exactly what a module must do when you specify how big it must be.
In other words, the requirements for a feature, or module, must include functional requirements but also performance requirements. And I dare add, usability (UX) requirements.
All during implementation, the system architects must maintain continual vigilance to ensure continual system integrity. […] Fostering a total-system, user oriented attitude may well be the most important function of the programming manager.
This is extremely important technically, as in coding standards and patterns consistency, but also in a product UX perspective. Both of those perspectives need to be constantly monitored to ensure the integrity and consistency of the application as a whole.
@hgraca 