On the Balance of Speed and Quality
Fostering faster development without sacrificing quality.
Faster / better / smarter / cheaper: the huge resource sink which focuses so much time and energy in our industry. How can we deliver more and sustain success?
There are no shortage of solutions: waterfall gave way to agile, which gave way to lean. Java/Php/C# yielded to Ruby, Python and Node which now yields to Go, Rust and Scala. IaaS swayed to PaaS with Docker the new king-of-the-hill. Are these tools helping us ship more or are we still spinning our wheels with shiny new toys?
The alternate view is not on technology nor process but on the individual. Companies seek the elusive 10x developer or look for the young, eager and energetic in hopes of daily-delivery utopia. Yet this tactic is usually fraught with peril:
Thus the “needed” re-write which starts the whole cycle anew wasting more time with little value. How does this situation—software burden—continually happen, destroying velocity, and what can be done to ebb the tide?
Technical debt has incorrectly become an overarching term used to rationalize slow development as the accumulation of straws breaking the camel’s back. Maiz Lukin’s excellent article on technical debt defines the issue and a company’s cultural decisions which exacerbate failure. As Lukin correctly points out technical debt is not about writing bad code and bad code should not be confused with technical debt. There is no excuse for bad quality; but if you must sacrifice speed at the expense of quality, is quality worth the cost?
Someone asked a great question after I gave a presentation on applying architectural patterns to grow healthy systems. Should startups spend time on design when the chance of failure is high? Should shipping code trump all other priorities even at the risk of burdening the future with unmanageable quality? Why not just do it; shoot first, and ask questions later?
Craftsmanship is the balance of quality and speed. It separates the good developer from the bad developer. It is what the junior developer gains with seniority. Craftsmanship is the crux of delivering quickly and carefully. Fostering craftsmanship is the question we must answer: how do you balance speed and quality to not only deliver now but to continuously deliver when complexity increases with time?
All tools, languages, architectural patterns and methodologies seek to answer this question in some way. And just as rushing out code too quickly has disastrous consequences over-engineering and new technology distractions have negative effects. Why waste time with unnecessary abstractions, or learn something new and unsupported when you can deliver with what you know now? It seems like a lose/lose proposition: you are either creating a mess for yourself, stagnating with caution, living in the past or chasing the shiny-new holy grail.
I do not believe quality and speed is an either/or choice. Craftsmanship, the balance of speed and quality, is attainable by anyone at any level. You can fostering craftsmanship by drilling answers from two simple, straightforward questions:
Why do this?
What are the consequences of doing this?
The difference between a good and bad developers—and good and bad development teams—lies with how well these questions are answered in the context of solving some problem. The flip side is how well companies understand and believe the answer from their development teams signals how well they are engaging and trust their development teams.
One’s inability to effectively answer Why? is the first tell of wasted time. It reveals whether or not one’s actions correspond to an end-goal. Slowness is not only how long something takes to do but whether or not it should even be done to begin with. Conversely one’s lack of understanding another’s Why? is also a sign of disconnect; the two parties are not in sync and risk a making a wrong decision by ignorance.
While agile processes have some combination of hypothesis/minimum delivery/validation metric to help answer Why? there is little gate-keeping on the development side. Why? reveals whether someone is producing value or simply producing, or whether management is supporting its team correctly. Obviously the work must be valuable but when gauging implementation—the result of craft balancing speed and quality—answering Why? will explain whether a developer’s assumptions fit a deliverable. Is some technology choice correct? Is some abstraction correct? Is some shortcut correct? Is the investment now worth the return later? These are the questions leaders answer. They must also be answered by implementors so implementors fully grasp context.
I find a common theme around slowness: the most common answer to Why? is simply some variation of “because”. Because “that’s the way it is” or because “that’s what someone told me” or because of poor, invalid assumptions. Answering “because” reveals a lack of conscience in forward movement: this is the quickest way to build a ball of mud. A good developer will never settle with “because”; a good developer does what is right but factors in time as well: there is no big rewrite; there are a series of incremental improvements. There is no bad code, there is acceptable technical debt.
Consequence is a subtler—yet more important—aspect of craft. While Why? reveals the now, Consequence reveals the later; the ability to continuously deliver in the future. Understanding consequence defines a good developer and is the heart of Lukin’s difference between technical debt and bad code: the former a trade, the latter an excuse.
Does someone understand the effect of a change? What is the benefit of action? Of inaction? Understanding consequence signifies an understanding of context; one knows the runtime behavior and the future evolution of a system. More importantly understanding consequence signifies whether the pay-it-now cost is worth the future dividend of optimal delivery versus an unnecessary abstraction cost never to be cashed in. Ignorance of consequence is a direct cause to unmanaged complexity that stalls delivery: you simply have no idea what you’re doing, hoping someone else will figure it out, chugging along constrained by your own prison.
But is simply questioning Why? and Consequence even needed? We often create focus by slimming our vision: agile seeks delivery of the small and manageable, the divide-and-conquer approach. With small, the Why? doesn’t matter because the cost is minimal; Consequence is irrelevant because there is no future to worry about, the future comes later. But small doesn’t drive implementation, and small creates slowness: you delivered, but did you do anything? Without the big picture we just incrementally move down a path to nowhere.
Speed does not come with frequent, small steps, if that speed creates larger hurdles to climb every week. And a technology solution—whether a new tool or a new refactor—is only acceptable if it is worth an investment, just like the addition of technical debt. The extra time to do now or learn now is worth the deliverable later: this is the secret of a 10x developer. This is the return for success. Forcing a sacrifice of craft for time is a lack of trust; failure is inevitable.
Real speed and real quality come from making the right decisions solving a problem in a given context. Velocity is not about speed alone: it is the rate of change given a direction. You must quickly go somewhere. Slowness is the absence of movement and direction. Absence of knowing why something is being done: either because you don’t know or you have the wrong answer. Repeated blindly, without considering Consequence, creates a mess—not debt—hindering new development. It is what nobody wants to deal with: spaghetti code, unneeded complexity, the wrong library or the NIH syndrome, with the only answer to start over, making the same mistakes again and again.
Foster craftsmanship: the ability to push the Why? out of people. Whether a developer or a non-developer pushing Why? will increase consciousness so the correct answer to speed and quality emerge. Pushing Consequence will enhance the Why?, providing context, keeping velocity strong.
