"Make it work, make it right, make it fast"
This sentence is attributed to Kent Beck, the creator of the Extreme Programming (XP) methodology. While "make it work" is a reminder for pragmatism and avoidance of early optimization, "make it right" is a plea for sustainability. What place does this leaves for "make it fast"?
When we think about a software solution, what does "fast" actually mean? Are we talking about real-time fast? As in milli- or microseconds response times? Or are we talking about "responsive fast"? As in designing our components with asynchronicity in mind so that your user never has the impression of waiting? Or are we finally talking about "not-too-long fast"? As in computing a good-enough solution in a "not too long" timeframe, as it is done for an optimization problem that would otherwise take centuries to solve via brute force.
Fast really depends on the context, the problem at hand and the constraints of the system. A Formula 1 car has very little in common with a truck, but both express different views on speed: raw speed in kilometers per hour for the one, reliably pulling tons of materials from one place to another for the other. Each of them is the fastest solution to one given problem, you just have to figure out which.
When is it time to make things fast? Not before you have made it to work, and after you have made it right. Not following this rule has a name: early optimization.
A Formula 1-type car could probably pull tons of equipment between places, but the gasoline, spare tires, maintenance and repair costs would go through the roof... if the Formula-1 didn't remain stuck in a bump on the road in the first place that is. On a very short term, it would be fast, but this would be missing the point. Optimizing early could lead into creating a Formula-1 where what you really needed was a truck.
When is it time to make things fast? Not before you have made it work.
When is it time to make things fast? Not before you have made it right.
Making it right taken alone often doesn't fulfill non-functional requirements ; like performance. You will often have to do some tweaking to obtain a solution that satisfies the business. But making it right will create a "good enough" solution you can build on. If your database calls are already stripped to their bare minimum and if your code is flexible and modular enough to be correctly unit tested, you are probably not far away from a good enough solution in terms of performance and your design will allow for the necessary changes to make the output faster.
Fast isn't a qualifier that only applies to our code. What use is a fast software if no one is able to reliably and quickly make changes to it in the future? When tweaking software for speed, we should not forget the overall readability. If by increasing speed we end up obfuscating the code, we must take a step back and look at the whole picture. This is where the idea that making things right will inherently make them fast, flourishes. By following the Clean Code guidelines and principles, we will shoot for clarity, flexibility, reuse and organic improvements. All those qualities will make the next step easier for us, making the cost of the next feature go down and the production speed go up.
When is it time to make things fast? When we have made it right, it most probably already will be. Keep this sequence in mind: "Make it work, make it right, make it fast"!
Photo by Marc-Olivier Jodoin on Unsplash
Read the two other parts of this series: "Make it work, Make it right, Make it fast" (Kent Beck)
