There are no shortcuts

Software development creates technical debt in just the same way as trees create oxygen. It's unavoidable (except by killing the tree). However it is possible to reduce it by good professional practice, which we'll come to below and in future rules.

Code written with good professional practice takes less time to create than code written with poor professional practice. Think of a concert violinist playing Nikolai Rimsky-Korsakov's "Flight of the Bumblebee". Each note is perfectly formed and produced by years of honing professional practice. A beginner would have great difficulty delivering the piece as quickly or as accurately. In fact the best way for the beginner to deliver the piece would be to practice for several years.

In software development we often see this effect in the development of proofs-of-concept or prototypes. What usually happens is that every short-cut in the book is used to produce something that "just works". The Product Owner looks at the prototype and says "Great — get that into production by tomorrow" and thus we have a completely unsupportable product that only knows about the happy path, is a dark nest of technical debt and on day-one just about works. By day 14, when several new features have been added using the same coding standards that were in place on day-one, things have got massively worse. Now the code base is so difficult to understand and work with that it is becoming resistant to change. Each release is met with an exponentially growing test effort and fixing one bug invariably starts to cause two more.

How do we stop this happening? The answer is for all developers to use best professional practice all the time. If this had happened in the first place the initial prototype would have been delivered both quicker and with fewer bugs, better testing and better design. The team could have agreed on technical debt with the Product Owner and would have a plan to reduce it. Lead engineers would have thought about non-functional requirements like security, scalability and performance and there would be plans in place to address any issues. A build and delivery pipeline would be in place to ensure that the team could release safely into production several times each day and that each release was covered by a test suite which stopped the build if any functional or non-functional defects were found. Note that doing this right requires not only the developer but also the whole development team doing the right thing.

The developer leads by being an exemplar of professional practice.

Instead of running around like headless chickens the tester/testers should be contributing to the product backlog and estimation including all testing requirements, and signing off releases with any minimally required manual testing.