Quotes About Efficiency

Software is like a science. We show correctness by failing to prove incorrectness, despite our best efforts.

But I can write my tests later", you say. No, you can't. Not really. Oh, you can write some tests later. You can even approach high coverage later if you are careful to measure it. But the tests you write after the fact are defense. Tests you write first are offense. After-the-fact tests are written by someone who is already vested in the code and already knows how the problem was solved. There's just no way those tests can be anywhere near as incisive as tests written first.

When you see commented-out code, delete it!

The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that.

Duplication is the primary enemy of a well-designed system. It represents additional work, additional risk, and additional unnecessary complexity.

I like my code to be elegant and efficient. The logic should be straightforward to make it hard for bugs to hide, the dependencies minimal to ease maintenance, error handling complete according to an articulated strategy, and performance close to optimal so as not to tempt people to make the code messy with unprincipled optimizations. Clean code does one thing well. -Bjarne Stroustrup, inventor of C++ and author of The C++ Programming Language

Adding manpower to a late project makes it later.

Building a project should be a single trivial operation.

The perfect kind of architecture decision is the one which never has to be made

Just as the Hare was overconfident in its speed, so the developers are overconfident in their ability to remain productive.

Another problem with service-level decoupling is that it is expensive, both in development time and in system resources. Dealing with service boundaries where none are needed is a waste of effort, memory, and cycles. And, yes, I know that the last two are cheap—but the first is not.

FUNCTIONS SHOULD DO ONE THING. THEY SHOULD DO IT WELL. THEY SHOULD DO IT ONLY.

Architecting for the enterprise, when all you really need is a cute little desktop tool, is a recipe for failure.

Duplication is the primary enemy of a well-designed system.

the ratio of time spent reading vs. writing is well over 10:1.

A good manager drives a project to be good enough, fast enough, cheap enough, and done as much as necessary. A good manager manages the coefficients on these attributes rather than demanding that all those coefficients are 100%. It is this kind of management that Agile strives to enable.

1. "First make it work." You are out of business if it doesn't work. 2. "Then make it right." Refactor the code so that you and others can understand it and evolve it as needs change or are better understood. 3. "Then make it fast." Refactor the code for "needed" performance.

What this team did not realize was that having dirty tests is equivalent to, if not worse than, having no tests.

We want our code to be a quick skim, not an intense study.

The cost of automating acceptance tests is so small in comparison to the cost of executing manual test plans that it makes no economic sense to write scripts for humans to execute.

If you think good architecture is expensive, try bad architecture. —Brian Foote and Joseph Yoder

Complexity kills. It sucks the life out of developers, it makes products difficult to plan, build, and test." —Ray Ozzie, CTO, Microsoft Corporation

Lots of very funny code is written because people don't take the time to understand the algorithm.

The goal of software architecture is to minimize the human resources required to build and maintain the required system.