I feel like it’s the word ‘goal’ that makes one stumble here. I agree that he is not really describing the ‘goal’ of software development. He’s describing how t

I feel like it’s the word ‘goal’ that makes one stumble here. I agree that he is not really describing the ‘goal’ of software development. He’s describing how to succeed at software development in order to reach a larger goal. And although it took me a while to understand what the author is getting at, I do kind of see his point which in my mind could be summarized as: slow and steady wins the race. Or: In order to speed up (in the long run), slow down (in the short term). Be conservative, be thorough, understand that developer productivity isn’t about that LOC per x unit of time. One analogy that comes to mind for me is Formula 1. Sure, it would be faster, right now, to just not pit. You would have to drive into the pit, stop and wait for the tyres to be changed and drive out again. Meanwhile your opponents are zooming past you out on the track. But if you don’t pit, soon enough your tyres will be worn down and it becomes impossible to keep heat and performance in them, and after a while longer you might even have to stop completely due to a puncture. The ‘pitstop’ could be anything that ensures productivity in the long term and as such helps in reaching the final goal, and those are the things that take a professional to understand the importance of.