Published January 12, 2020
by Doug Klugh

Always Write Good Code

Do not fool yourself into thinking you will ever go back and actually rewrite your code the right way.  Any experienced developer will tell you it rarely happens (even with the best of intentions).  And every time you save that cruft for later, you’re introducing Technical Debt, which will do nothing but slow you down.  To go fast, you must go well.  Trading quality for velocity will catch up to you very quickly and slow you down much more than if you had written good code to start.  This does not mean you should spend a lot of time over-engineering your solution.  Follow basic Software Evolution practices to get your product in your customers' hands as quickly as possible, while promoting YAGNI.

Let's face it, when you're under pressure to delivery quickly, it's easy to write quick and dirty code to meet a deadline.  But this is where product development often gets into trouble.  Product Owners are looking for short-term gains and fail to look beyond the horizon — where the team has to pay dearly for all the shortcuts taken to enable rapid delivery.

Are your estimates driving your schedule (as they should) or is your schedule driving your estimates?  In other words, are you massaging your estimates, forcing them to align with the desired schedule for delivery?  Anyone who is involved in software delivery should never expect estimates to be "adjusted" to fit a desired schedule.  Again, you're only fooling yourself if you ignore the amount of effort that is required to deliver a quality product.  It is better to reduce scope than to reduce quality.  That's not to say that you can never take calculated shortcuts to gain a competitive advantage.  But if you do, you should always understand the short-term and long-term impacts, have a plan to quickly pay down such technical debt, and provide visibility to all stakeholders in order to remain competitive and support your customers in the future.

Traditional waterfall projects usually align with the triple constraints of project management:  Budget, Schedule, and Scope.  When any of those constraints begin to slip (and they usually do), the thing that suffers sits in the middle of that triangle:  Quality.

In Agile development, Quality is not a variant that sits in the middle.  Quality is one of the three constraints and Scope sits in the middle (as a variant) — which aligns with Agile methodology.  Agile does not promise to deliver a set scope on a specific date within a specific budget, with whatever level of quality can be squeezed in at the end.  Instead, Agile promises to deliver the highest value (functionality) first with high quality.  And if anything has to slip, it will always be the lowest valued functionality.  So, if we have to miss anything, it will be the things we will miss the least.  How often do waterfall projects hit their target date from the beginning of the project?  Hardly ever.  Agile recognizes that we are just not very good at this and works accordingly.

While Waterfall aims to deliver with fixed costs, schedule, and scope (with variable quality), Agile aims to deliver with fixed costs, schedule, and quality (with variable scope).