John Ousterhout is a professor of Deparment of Computer Science from Stanford University. One recent project he is working on is the RAMCloud, a “new class of storage, based entirely in DRAM, that is 2-3 orders of magnitude faster than existing storage systems”. He posts his “Favorite Sayings” on his homepage. These sayings are precious experience and advice for building systems and developing software and they deserves really careful reading.
Some quotations that I found especially invaluable:
About performance optimization:
Most real-world programs run plenty fast enough on today’s machines without any particular attention to performance. The real challenges are getting programs completed quickly, ensuring their quality, and managing the complexity of large applications. Thus the primary design criterion for software should be simplicity, not speed.
If you try to optimize the performance of an application during the initial construction you will add complexity that will impact the timely delivery and quality of the application and probably won’t help performance at all; in fact, it could actually reduce the performance (“faster” algorithms often have larger constant factors, meaning they are slower at small scale and only become more efficient at large scale). … So, don’t worry about performance until the application is running; if it isn’t fast enough, then go in and carefully measure to figure out where the performance bottlenecks are (they are likely to be in places you wouldn’t have guessed). Tune only the places where you have measured that there is an issue.
About intuition and analysis:
Intuition is a wonderful thing. Once you have acquired knowledge and experience in an area, you start getting gut-level feelings about the right way to handle certain situations or problems, and these intuitions can save large amounts of time and effort. However, it’s easy to become overconfident and assume that your intuition is infallible, and this can lead to mistakes.
One area where people frequently misuse their intuition is performance analysis. Developers often jump to conclusions about the source of a performance problem and run off to make changes without making measurements to be sure that the intuition is correct (“Of course it’s the xyz that is slow”). More often than not they are wrong, and the change ends up making the system more complicated without fixing the problem.
About facts and concepts:
… before you can appreciate or develop a concept you need to observe a large number of facts related to the concept. This has implications both for teaching and for working in unfamiliar areas.
About problem fixing:
Don’t ever assume that a problem has been fixed until you can identify the exact lines of code that caused it and convince yourself that the particular code really explains the behavior you have seen. Ideally you should create a test case that reliably reproduces the problem, make your fix, and then use that test case to verify that the problem is gone.
About software project progress:
My rule of thumb is that when you think you are finished with a software project (coded, tested, and documented, and ready for QA or production use) you are really only 50-75% done. In other words, if you spent 3 months in initial construction, plan on spending another 4-8 weeks in follow-up work. One way to minimize this problem is to get your new software in use as soon as possible. If you can create a skeletal version that is still useful, get people trying it out so you can find out about problems before you think you’re finished.
About software improvement:
No software is ever gotten right the first time. The only way to produce high-quality software is to keep improving and improving it. There are 2 kinds of software in the world: software that starts out crappy and eventually becomes great, and software that starts out crappy and stays that way.
The only thing worse than a problem that happens all the time is a problem that doesn’t happen all the time
… if you admit that you don’t know the answer, or that you made a mistake, you build credibility. People are more likely to trust you when you say that you do have the answer, because they have seen that you don’t make things up.
Coherent systems often have advantages of efficiency, which is why humans gravitate towards them. … Unfortunately, coherent systems are unstable: if a problem arises it can wipe out the whole system very quickly.
Enjoy the full “Favorite Sayings” on John Outsterhout’s homepage.