Practice 7. Don't Neglect Performance
Performance is one topic that generates passionate discussions in software development. Some people feel that code clarity is more important and that you should get the code clarity right first and then optimize the 1 to 3 percent of code that needs it. Others feel that you should code for performance first, because if you don't, your code will always be slow.
Personally, I get scared when a development team or developer says "we'll worry about performance later." I have seen too many projects where the team felt the need to get the features in before worrying about performance led to months or years of rework. Code clarity does come first, but not at the expense of performance. This is another case where you need to embrace the genius of the AND: You must be concerned with performance AND clarity, with a strong bias toward the latter. You don't have to be obsessive about performance, but you need to understand what the customer's expectations are, design for the right level of performance from the beginning and where performance really matters, ensure that you have tests to measure performance and let you know when the performance degrades in a noticeable way (see Chapter 5 for more on performance tests). You should never have to hear from your customers that your product is too slow…!
I also get scared when a development team says its software will get faster on the next generation of hardware. The fact that computers are getting faster is a constant and everyone benefits, including your competitors. Applications are also getting larger and more complex. You need to understand at least the basics of performance for the programming language and framework your product works in. Just because you develop in Java, for example, doesn't mean that you can neglect performance, even though Java is an interpreted language.