Technical Investment, or quality vs. time
The Agile Zone is brought to you in partnership with JetBrains. Learn how Agile Boards in YouTrack are designed to help teams plan, visualize and manage their work in an efficient manner, with support for both Scrum and Kanban processes.
A fundamental question of software development is: can we trade quality, sacrificing all we know about writing clean code, to gain time?
This expression means, can we take up technical debt and hack together some code, throwing away our test suite, which after all has to be maintained with the code?
Believing that the answer is Yes is a fundamental fallacy, and the term Technical Debt itself is shaped to convey the fact that you'll pay interests for years over the capital you have borrowed today in order ship a day early. It's like signing up for a credit card and go for a session of wild shopping, but you'll never know when the bill will arrive, and how early.
I was riding my exercise bike, listening to Stack Overflow #38 when I heard Jeff Atwood and Joel Spolsky say “Quality just doesn’t matter that much.” I nearly fell off my bike.
I mean this is Joel Spolsky right? His buddy Jeff makes this incredibly dumb statement and Joel grunts his approval. WTF?
This is the kind of idiotic statement I would expect to hear from junior hackers, or people who haven’t written very much code. You simply cannot deliver software products for more than a few years and think that quality doesn’t matter very much.
[...] one thing you learn after four decades of coding is that code quality matters one hell of a lot. So to respond to Jeff I’ll simply fall back on the old saw “Faithful in little, faithful in much.” In other words, if you can’t keep your code clean, no way can you keep your systems clean. -- Uncle Bob
Jeff and Joel use their user base as unit testers, for example in Stack Overflow. Now try doing that with an accounting application.
We can argue that not all applications, particularly public, web-based ones, need the same level of attention of an enterprise one. However, we Agilists view quality as the base for speed, not something that can be part of a trade-off. For example, I learned by Claudio Perrone after his famous Lean presentation that market alignment (basically speaking, having the key features in your product) is much more important that quality: you can be aligned to the market with an ugly application and become rich, or not be aligned to the market with a clean application whose code is refined every day, and remain poor.
But... The catch is that to remain aligned to the market, the application must change with it, for example responding to advancement by competitors (and in 2010, the market changes a hell of a lot quickly); if you have clean code, you can maintain it and move towards new features and goals, while if you are too rigid because of bad code you won't be able to catch up with the pace of other vendors.
I really don’t believe that you can go faster to a working, viable product, over any period longer than a few days, by cutting back on test or code quality.
I know for certain that you can go faster over any period of time larger than a few weeks, by upping your game, by writing a few more tests, improving your code a bit, every day.
What happens in between those few days and those few weeks? That’s up to you. If you practice, I think you’ll go faster. If you don’t, when the few weeks are up you’ll be just the same in capability, but surrounded by more bad code. Is that going to make you happy?
You get to choose how you work. Choose, pay attention, and choose again tomorrow, next week, next month, forever. -- Ron Jeffries
According to Jeffries, one of the founder of the eXtreme Programming movement, bad code bites you back in a matter of hours. Let's say you are developing a class incrementally: in this case, I think it bites you back just after seconds, because when you are writing the second test case you'll probably read again the first one. Unreadability is, in the small, a lethal snake which can bite you before you can notice, just like hacked-up code in the large.
This is a quote taken from Peopleware instead, a famous book about projects and team management that attacks the common assumptions of our industry on productivity.
In many cases, you may be right about the market, but the decision to pressure people into delivering a product that doesn't measure up to their own quality standards is almost always a mistake. [...]
Allowing the standard of quality to be set by the buyer, rather than the builder, is what we call the flight from excellence. A market-derived quality standard seems to make good sense only as long as you ignore the effect on the builder's attitude and effectiveness. [...]
Ask one hundred people on the street what organization or culture or nation is famous for high quality. We predict that more than half the people today would answer, "Japan." Now ask a different hundred people what organization or culture or nation is famous for high productivity. Again, the majority can be expected to mention, "Japan."
According the authors of Peopleware and their studies conducted over hundreds of teams, the effect of taking too much time to ship while pursuing a spiritually-defined, abstract Quality are ugly: products arrive late to the market and are beaten by the competition. However, the effects of letting quality slide away are even more horrible: your best programmers, which are not impressed at all by the policy the project is conducted with, will flee and quit. The people who remain are not motivated to perform at their peak, since from their view point the project is a mass of broken windows. Even if the ones who leave the team are not top programmers, the underestimated cost of training of their substitutes, who will take from 6 months to become accustomed with the codebase and reach full productivity, will outrun every calculation. Then will come the increased costs of maintenance and technical debt.
In short, there are many sources which think of quality as irreplaceable, and that the only way to go fast is to go well.
Therefore, I'd like to propose the term Technical Investment to describe an opposite approach to taking on technical debt. Instead of purchasing expensive features on credit, think out them well and make an investment for the future. In the future, you will reap the benefits of your time, money and human capital spent during development, by being able to catch opportunities. Don't include features and behavior that You Aren't Gonna Need It: but test and refine what you are producing.
Can teams with technical debt dedicate a day to transition to a new source control system, which will give you even more rewards in the future? Or to stop for some hours and research how to setup Continuos Integration, which will catch a dozen of bugs before they go in production, fixing them at a tenth of the cost? In a free econonomy, who has capital gets even more by investing it, while he who continuosly gets in debt, eventually will go bankrupt.