Ciao!
Wouldn’t you agree that writing software feels like juggling contrasting goals?
We want it delivered soon, but high quality. We want the fun of bleeding edge, but the stability of mature tech. We want to have an impact, but we avoid feedback.
That’s why we adhere to KISS, YAGNI, and Good Enough. Step-by-step recipes make us feel protected by the chaos of software development.
But entropy is a thing. We cannot conceal it behind simple prescriptions. We need to deal with the nuances of code, or else, we are doomed to perform mediocre work.
We need to keep it simple but choose a validate solution. We are not going to need it but should keep options open. We aim for the good enough, but it should be the right enough, not the easy one.
When we decide to go fast, bleeding edge, and ignore feedback, then the output is similar to the codebase I’m tasked to rescue.
Among other (fun) things, the API is too slow to even be usable. And I can’t help but think that wasting investing a few hours in testing the first endpoint would have prevented basing all the following code on the wrong architecture.
We cannot change the past, but we can make the present better. That’s what I’ve worked on this week.
Making an Endpoint 13 Times Faster — Down to 900 milliseconds. In other words, more than 13 times faster in the worst case (before it took 12 seconds) and infinitely faster in the best case (no more crashes).
Also, with a bit of discipline, we can achieve (seemingly) competing goals. See Code Quality is Free (if You Do it Right).
Elsewhere on the Web
Domain Modelling Made Functional — Types can be used to represent the domain in a fine-grained, self documenting way. And in many cases, types can even be used to encode business rules so that you literally cannot create incorrect code. You can then use the static type checking almost as an instant unit test — making sure that your code is correct at compile time. (Whatever the topic, Scott is a must-watch.)
Why Averages Suck and Percentiles are Great — Anyone that ever monitored or analyzed an application uses or has used averages. They are simple to understand and calculate. We tend to ignore just how wrong the picture is that averages paint of the world. (A more rigorous approach than the one I’ve employed. Yes, I’ve averaged the calculations in my post.)
Reflections on software performance — I’ve really come to appreciate that performance isn’t just some property of a tool independent from its functionality or its feature set. Performance — in particular, being notably fast — is a feature in and of its own right, which fundamentally alters how a tool is used and perceived. (Amen to that!)
How are you (dis)liking the PinkLetter so far? I’m looking forward to your feedback. Hit reply and let me know how I could provide more value to you. Yes, you!
Thanks for spending some time reading with me. Talk to you soon.
Yours truly,
Riccardo.