The pragmatic programmer | Insights, and thoughts part 3
Hello reader, as in the first and second episodes, today's episode will also be about the book “The pragmatic programmer” and the many insights I got when reading the book. So let's begin(sensei Lawrence vibes here)
Prototypes
The business team gives you the mission of making a prototype, a POC, they are not thinking about selling it at the first moment, so they don't give you a big deadline because it's all a prototype everything will be discarded at the end of the POC
But when the business team sees the prototype working they decide to keep improving on the prototype, implementing new features in order to sell it as a product, and they are not going to give you time to properly rewrite it in a clean, dry, and without broken windows code. In other words, you are in trouble.
But as pragmatic programmers, our mission is to inform and explain to the business team that the technical debt may not seem like a big deal in the future but as soon as it grows the whole company will be in trouble, and as pragmatic programmers, our mission is not only to build a great code in the conditions we have but in this case, we also need to remind them that:
“You can build a great prototype of a new car out of balsa wood and duct tape, but you wouldn’t try to drive it in rush-hour traffic!”
And that's true, and our mission is to give the business team this shock of reality and remember them what the prototype word really means.
Estimates
Normally programmers are not very good at estimating, and we know that building software is complex and there are many factors we don't control, but the authors gave us a few tips to improve our estimation precision
— Write down estimates
Save your estimates in a notebook or something similar(.txt files work very well too), so you can measure how accurate you were
and can look forward to planning better next time you need to estimate
— Keep a log of your estimations
For each estimate you wrote down, track how accurate you turned out
to be. If your error was greater than 50%, try to find out where your estimate went wrong.
— Don't do it on the coffee machine
You almost always get better results if you slow the process down and spend some time going through the steps described in the book. Estimates given at the coffee machine will (like the coffee) come back to haunt you.
Automate everything
We normally thought that the movement of automating things was something that started with the DevOps adoption but in 1999 the authors have already written about it “If you need to do the same manual thing a second time automate it” and their tip to achieve it is:
— Automate the tasks with scripting languages
The authors mention Shell and Perl scripting as good alternatives to create procedures of manual tasks in the operational system, but I think you can also use python or node to do it too nowadays, so pick one and automate
Repetitive tasks can be things like code boilerplates, creation of files, folders, installing software, cleaning log files, and everything else that can be automated
And it's the same for when a new coworker join your team and the only thing that person got is documentation on how to do the manual thing of configuring the environment, the project, and installing software on what can be done wrong even with the instructions
Dont ask people to follow manual step by step procedures they will fail because they are not as repetitive as computers.
So to avoid human failure, we automate and delegate that repetitive tasks to specialists: the computers.
All software becomes legacy as soon as it’s written
A huge truth that I wasn't aware of is that as soon as the feature is implemented it is legacy code already, and wow technology moves so fast that every line of code in production is already legacy code. And how do programs keep themselves out of it?
Caring about architecture not only on adding the features for the current necessities but preparing the ground for new amazing features and that is achieved by:
A loosely coupled architecture, Dry code, no broken windows, good tests, automated and documented processes, and through an evolutionary architecture that knows that there are no final decisions, and everything must be reversible and adapt.
We want to build software that resists the test of time like this book did.
So fast so far, here we are at the end of the third episode in this series about pragmatism and programming. And it's incredible how the fundamentals and main concepts remain untouchable by the action of time, and how good ideas remain solid and age like wine.