> Stop the cult of "build faster with tech debt" -- internal quality matters and costs you velocity.
Well, internal quality costs, and the price is expressed in time.
As someone else said: "shipping is a feature", and especially for first versions! The quality of the code is only important for that code that actually brings value to the user, and you need to ship in order to know which is which.
The problem with technical debt stems from the diffused myth that the development of a functionality ends as soon as it is released. No, you must continue to work after the first release, in order to polish the code while integrating the feedback from the user. This is the core of Agile.
>The way I assess where lines cross is by canvassing the opinion of skilled developers that I know. And the answer surprises a lot of folks. Developers find poor quality code significantly slows them down within a few weeks. So there's not much runway where the trade-off between internal quality and cost applies. Even small software efforts benefit from attention to good software practices, certainly something I can attest from my experience.
If you expect your business to exist more than a few weeks from now, opt for quality implementation over "ship it" hacks that cause compounding costs into the future.
> Developers find poor quality code significantly slows them down within a few weeks.
By the way, I'd like to know which kind of software those "skilled" developers are used to work on. If it is the umpteenth CRUD web application, several weeks can correspond to a few releases. In other fields, a few releases is a matter of years, and even only a few months of customer feedback is a treasure that smart developers don't give up easily.
There are hacks like "everything in a huge global object", and technical debts like "no unit tests for internal detail and no detailed software structure documentation until we know which code is actually worth to maintain".
Well, internal quality costs, and the price is expressed in time.
As someone else said: "shipping is a feature", and especially for first versions! The quality of the code is only important for that code that actually brings value to the user, and you need to ship in order to know which is which.
The problem with technical debt stems from the diffused myth that the development of a functionality ends as soon as it is released. No, you must continue to work after the first release, in order to polish the code while integrating the feedback from the user. This is the core of Agile.