Years ago, I read this statement, applied to software development:
”Make It Work, Make It Right, Make It Fast”
I don’t remember the source. It is attributed to Kent Beck, but apparently, there are precedents. Read:
In the last decade, I started to understand the three-part statement, and I really think my software development skills were improved adopting this way of doing programming. Somehow is related to TDD (Test-Driven Development) but there are different things, and can be applied in a wider context. Let review what I think about each part, and how I apply them everyday.
Make It Work
Yes, instead of trying to do “THE RIGHT” thing from the beginning, I put my effort in having a working thing (a function, a method in a test, a use case branch, a user interface and experience). I don’t bother about the inner improvements, or about applying all the patterns from the book. I write code that works. Simple, working code. Following this advice, I can write simple code, and I can start to understand the underlying problem. If the product is use case branch (not a full use case), the working output can shed light on the business model, and even end user feedback can be applied in early stage.
However, if I tried to do the right thing, I could waste my time and effort in something that is not what the project needs.
There is an special case: “make it work” is an essential of TDD second step, make the test go green.
Make It Right
Only when I have a working piece of software, then I’m back to improve it. Removing code duplication, applying the patterns in context (not only the patterns by the book), exploring new implementations. This is the opportunity to decrease or to remove any technical debt, any relic of toxic code. If something is convolute, go and write more straightforward code.
When the product is code written with TDD, I apply this advice at refactoring step. TDD workflow and cycle helps me to have a controlled technical debt amount. And having all the tests, now I can explore with confidence alternative internal implementations, without pain. It is really a creative step. Some programmers think that TDD puts a damper on creativity, but on the contrary, I see this two steps as a form of exercise it.
Make It Fast
Only then I worry about the speed of execution. There are so many factors that can influence it, that I only take care when a have a clear and working implementation. If you tend to write code in the previous phases thinking “this code is faster code”, stop doing that. I don’t know if a method is faster enough or not, without having a clear use case that needs performance improvement, and without having speed measured before optimization. Don’t optimize what it’s not measured.
Sometimes, I met project with the wrong decisions already done: someone added stored procedures, because “stored procedures are faster”, without any evidence of such assertion, without any performance suite that could support the statement. And then, a convoluted stored procedure, with lot of domain logic, start to emerge in the middle of the system. Even worse: without any test.
So, after practicing these precepts in my personal and professional projects, I’m a big proponent of following them. It is a pleasure to see how an idea grows up until become a concrete and solid library or system.
More fun is coming.