The Cumulative Benefit of Multiple Small Improvements

As a programmer becomes more effective, they find themselves thinking more and more about refinement. That is, taking a program or module or function that already works, and making it work better. Better could mean faster, or with less code, or with more elegance, or with more clarity of purpose, or any number of other characteristics that us programmers find "valuable".

At times, these refinements may appear to others to have little value, and in discussions about them, critics often emerge:

Ooh, you shaved off a few milliseconds off that function - big deal!

Why bother with this functional nonesense when for loops have served us reliably for years - they work just fine!

Whats so great about Promises? So you save a couple of indents? No thanks, I'll stick with callbacks!

Comments like these reveal a shortsightedness that can often exist among the more cynical of us (or perhaps in all of us in our more cynical moments).

What I think is sometimes not recognized or is under appreciated, is​ the cumulative benefit of multiple small improvements.

Certainly this appears around us everywhere. But in programming, the effect can be multiplicative, or even exponential due to the modular nature of code.

Performance

Reducing the processing time of a function by 2ms may not sound like much. But if that function is being called within an animation, it is ideally being called 60 times per second, which is a savings of 120ms - per second!  That might be the difference between running your animations at a sub-optimal 20fps/30fps and the buttery-smooth frame rate of 60fps.

Or it might give your app the time to perform additional animations or flourishes you wouldn't have been able to afford otherwise.

Or maybe it just reduces the energy drain on your users' machines by 10%. Multiplied out by all your users, and its a big savings!

Code Size and Clarity

Ok, now lets look at some Javascript code examples for fun:

Callbacks vs. Promises

// Using callbacks
getData(url, function(err, data) {
		if(err)
			reportError(err);
		else
			renderData(data);
	});

// Using Promises
getData(url)
	.then(renderData)
	.catch(reportError);

The argument:

Clearly the promise-based code is cleaner, simpler and more elegant. But is 2 less lines worth all the hype?

Imperative vs. Functional

// Imperative
for(var x=0;x<data.length;x++)
	process(data[x]);


// Functional
data.forEach(process);

The argument:

The functional approach saves a line of code and does read a bit easier, but at the cost of a whole new mental model? I'd like to spend some time with my kids!

Attempts to fall back to a kind of pragmatism to avoid the work of refining code or learning new concepts are understandable. But if the software you are writing is of any importance, it is worth the extra effort. 

These apparently small improvements play off each other, and get multiplied throughout your application, resulting in significant benefits in terms of code readability, reliability, size and speed.

And as your code gets smaller and easier to read, it becomes easier for you to reason about. And here is where you can really strike gold - in identifying ways that you can restructure, regroup, or refactor your code that more effectively represent or conveys the code's intent. From here, you can get really big speed improvements, more robust programs, and vastly improved user experiences.