This post is addressed to all the software dev. managers with this mentality, where a (probably manager) was honest in that they don’t care about Data Oriented Design (or any performance optimization strategy that requires some dev time, for that matter). A transcipt ensues:

– We worry not so much about the time, because it’s all user interface stuff.
We worry about how long it takes a programmer to develop a piece of code in a given length of time.
So we don’t care about this stuff. If we can write a map in one sentence and get the value out, we don’t care really how long it takes. As long as it’s–

 

– Ok. You don’t care how long it takes. But you know what? People who don’t care about long it takes is also the reason why I have to wait 30 seconds for Word to boot.

I’m dissatisfied with Mike’s answer. I’m sure this man is going to go home, and still not care about performance. At all. All he cares about is that Word’s dev team met the deadline, it sold well, and managed to make profits. Performance will only matter to him if the competitor manages to boot in 1 second and people are moving away because of that reason.

I’m a C++ developer with a business oriented mind, and I know his mentality set very well. So I’m going to give this man a different answer: because it reduces development time. Adopting DOD practices helps meeting deadlines, reduce costs, and increase profits.

There are four ways in which performance optimization and DOD cuts development time:

1. Planning. As Mike Acton pointed out, to implement DOD you need to understand the problem. This implies taking the time to think about the problem, about the hardware, about the common use cases, etc. This may seem like it increases development time (and thus costs), but I think I don’t need to elaborate on the concept that taking a bit of time to think about how to approach a given problem instead of jumping straight to coding and solving problems as they go pays off in the long term.

Correcting a mistake caused by not thinking things through can costs months of development time. DOD reasoning helps in understanding the problem and avoiding such mistakes.

2. Cuts off compiling time. A lot of time is spent compiling. In terms of Frederick Taylor, compile time is employee’s downtime. Sure, you can ask him to focus on something else, like writing documentation, read the bugtracker’s open bug list, discuss with colleagues about architecture, or take the legally required coffee break (on most countries with labour laws).

But in reality colleagues are rarely available at the same time to discuss architecture (because compile starts happen at random), they can’t take 10 coffee breaks in the same day, and if they’re fixing a bug from the bugtracker then they’ve already gone through that list. And if the documentation is in doxygen or other in-source format, modifying the docs means forcing yet another recompile.

But more importantly, they loose focus. Few things are more distracting than fixing a bug, wait 5 minutes to try it out, only to realize it still doesn’t behave as expected, you made a mistake and have to recompile again. Wait another 5 minutes. And if you do not have a full understanding of the bug, you may need to recompile two more times.

That’s a total of 20 minutes of dead time spent compiling, plus the lost time of the dev who lost track of what he was doing and what the problem was every time he hit ‘Build’, sadly that lost time cannot be measured. May be it’s a couple minutes. May be it’s hours. I’m inclined to think it can be days. All that to fix just one bug of medium complexity.

Cutting down compile time from 5 minutes to 30 seconds is feasible with the right practices, will increase developer productivity tremendously.
God help you if fixing the bug requires touching a header included in nearly every file. [Note: Some projects can take 30 minutes or longer for a full build]

3. Cuts off loading and processing time. This is very similar to the previous one. The random example of Word taking 30 seconds to boot (note: the number is probably made up, I don’t know how long Word actually takes) is a very useful one. Every time the developer needs to start the process he wastes 30 seconds.

If a bug needed 4 recompiles to get fixed, we probably re-ran the process with the debugger around 8 times to understand it. That’s 4 minutes in dead time in addition to the previous 20 minutes.

If the steps to reproduce the bug require significant processing (which requires a lot of time), the time needed to reproduce the bug may increase 20x.

Furthermore, the program is taking 30 seconds to boot… IN RELEASE MODE. We need to reproduce the bug in Debug mode. You can guess, Debug mode will take much more than 30 seconds… start doing the math.

DOD has a very nice property that the gap between Debug and Release builds starts to get smaller, often bringing debug builds to more than acceptable levels of usability, which results in developer productivity.

This isn’t just limited to bug fixing. Trying out new features get equally benefit.

4. Hardware costs. Because of points 2 and 3, you’re probably equipping your devs with the latest hardware. Lots of cores, lots of RAM. If you’re running a server, it’s probably a powerful one. If the processing power required is really big, you may even be using a server farm (whether to run the software or to run the compiler). Software that already runs fast requires less frequent hardware updates, and smaller server farms.

Now, admitedly, Mike Acton may be quite religious/strict about no-STL, no-exceptions, no-templates rules. Which are necessary on game development or embedded systems, but when developing mainly GUI-based applications for Desktops, these requirements can be relaxed a bit.

Take note that Mike’s approach is to focus on performance-critical areas of code (aka hotspots). Time critical operations that can unnecessarily take a lot of CPU. If you’re writing a tool or routine that is rarely going to become a hotspot, then it’s reasonable to write that “one-liner map”. Just don’t let it get out of hand.

If you’re still not convicenced. User-side, latency matters too. The following examples may be web-related, but don’t forget servers can be written in C++; and the data gathered isn’t really unique to web development:

• http://glinden.blogspot.com.ar/2006/11/marissa-mayer-at-web-20.html To quote a few: “we tried delaying the page in increments of 100 milliseconds and found that even very small delays would result in substantial and costly drops in revenue” “Half a second delay caused a 20% drop in traffic. Half a second delay killed user satisfaction.”
• http://radar.oreilly.com/2009/07/velocity-making-your-site-fast.html “a 5 second speed up (from ~7 seconds to ~2 seconds). This resulted in a 25% increase in page views, a 7-12% increase in revenue, and a 50% reduction in hardware. This last point shows the win-win of performance improvements, increasing revenue while driving down operating costs” “Google found an extra .5 seconds in search page generation time dropped traffic by 20%”

If by now you still think you shouldn’t care about performance, you’re either writing a program that has no competitor (a monopoly) or developing an original algorithm/solving a new problem which isn’t yet well understood.

Only the latter is an acceptable excuse for not optimizing, since you don’t even know whether the algorithm will work. But the former… you’re just letting yourself vulnerable to any potential comptetitor that may show up. And you may not even understand why you’re losing customers.

So, if you’re a manager, the next time you think you don’t care about how fast your product runs because all that matters is meeting the deadline or taking as little dev. time as possible to pay less hours to your employess… Think again.