Month: May 2016

When not to optimize

Software development has some consistent goals. We want the software to be as fast as possible, as small as possible, to work as well as possible, and to be done as soon as possible. Naturally there tend to be trade-offs between these goals: the fastest algorithm may require more storage space, the algorithm that requires the least space may be complicated and prone to errors, extensive testing may delay the release. We decide which goals take priority and what values are acceptable for each. But how to choose? In some cases, optimizing for speed and size makes a lot of sense. If a loop will execute ten thousand times, a one-millisecond delay in each loop is likely to be unacceptable. If there are ten million items to be stored, requiring an extra byte for each item can make a difference, even with today’s storage allocations. Even when not under tight constraints, all things being equal, we’d like to optimize our performance. In some cases, though, it’s better not to optimize. I’m not talking about avoiding premature optimization – I’m talking about not optimizing at all. For example, suppose you have an object which will be instantiated a few dozen times¬†(with each instantiation being stored on disk)¬†and there are two ways you can code it. One will require an additional string value, the other will simply perform some calculations (perhaps...

Read More

The importance of downtime

As I write this, it’s the day before I return to work after a sabbatical. I’ve spent the last two weeks in Europe, exploring castles in England and munching crepes and escargot in France. What I have not done is anything related to work. In fact, before I left home I did two things. I removed the sim card from my phone (I got a temporary one in Europe to provide a data plan there) and I shut off my work email, so I wouldn’t get any emails from work even when connected to wifi. In my last team...

Read More