Agile Zone is brought to you in partnership with:

I am a programmer and architect (the kind that writes code) with a focus on testing and open source; I maintain the PHPUnit_Selenium project. I believe programming is one of the hardest and most beautiful jobs in the world. Giorgio is a DZone MVB and is not an employee of DZone and has posted 636 posts at DZone. You can read more from them at their website. View Full User Profile

Technical Investment, or quality vs. time

12.14.2010
| 7947 views |
  • submit to reddit

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.

Conclusions

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.

Published at DZone with permission of Giorgio Sironi, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Sadsds Dsadsadsa replied on Tue, 2010/12/14 - 6:02am

the best article i have read on this site in a long time.

Cosmin Mutu replied on Tue, 2010/12/14 - 8:46am

Well, in REAL WORLD, in most of the companies, projects deadlines are always under estimated, most of the time documentation is badly written and programmers are assigned on 2 or 3 projects at the same time.

Quality DOES MATTER for PROGRAMMERS. Programmers HATE bugs.

Quality NEVER MATTERS for SALES & PROJECT MANAGERS. These guys LOVE bugs.

So, stop falling off your bike ;) nothing new under the sun.

Giorgio Sironi replied on Tue, 2010/12/14 - 9:44am in response to: Cosmin Mutu

If you are a project manager and you happen to lose your best programmers to the competitors because of the lack of care for quality in your development process, I'm pretty sure you will be affected. I never thought that motivation a/o quitting could become an issue for managers before reading the research and studies in Peopleware. Strangely, it's even recommended by Joel Spolsky.

Stephane Vaucher replied on Tue, 2010/12/14 - 1:05pm in response to: Cosmin Mutu

Obviously, your REAL world is not everyone's real world. There are companies that correctly estimate effort. After the publication of the CHAOS reports, there are some companies that tend to over-estimate. It depends on the skill of the team and of the quality of the process. Also, no one likes bugs.

Andy Leung replied on Tue, 2010/12/14 - 3:10pm in response to: Giorgio Sironi

Giorgio, I actually quit most of my times just because of the management. If you believe that "my manager cares about me and he/she doesn't want to lose me to the competitor"? I believe you are in Mars instead of my planet Earth. I am not saying all managers are bad but to believe there is such manager who is taking care of the whole team and individual's career path, it is very difficult for me and to be honest, I would say probably there is 1/100,000 managers is doing what you are saying. The only time I see a caring manager is the time I watch TV or movies.

Cosmin Mutu replied on Wed, 2010/12/15 - 2:03am in response to: Stephane Vaucher

I don`t want to enter on a full debate with you on this subject, but if you didn`t knew already, the REAL money come from MAINTENANCE and not from PRODUCTION. I actually have knowledge of a project where bugs were intentionally left so that they could send people on sites for maintenance. (THIS APPLIES TO MEDIUM TO LARGE PROJECTS)

Still, I agree with you that there are companies where deadlines are more or less correctly estimated but these are very rare. So consider yourself lucky if you landed a job on one of these companies ;)

 

Giorgio Sironi replied on Wed, 2010/12/15 - 6:21am in response to: Andy Leung

I don't think that the majority of managers are from TV, quite the opposite. It's this mindset - which leads to issues both for developers and the managers themselves - that we should fight to change. Conference-friendly bosses, which I have seen some, are a start...

Andy Leung replied on Wed, 2010/12/15 - 12:08pm in response to: Giorgio Sironi

Fight-to-change works in SMB but not big ones. You will see more politics player in management level than someone who knows how to manage a team well in the biggies. Besides, even though you could fight to change, sometimes it's not up to you. e.g. even though you are assigned to be the Tech Lead for a project, your project is just a child project of the parent where there is overall Tech Lead and overall Architect, overall BA and overall PM and overall this and that you have to fight. So even though you may be able to convince your own team, your idea may not see the light eventually and this happens every single day. That's where the challenge's from. Thus far the only way I see someone demostrating a working model is: your father is one of the VP up top and yeah your idea will always expedited to the door.

Stephane Vaucher replied on Wed, 2010/12/15 - 9:42pm in response to: Cosmin Mutu

I don`t want to enter on a full debate with you on this subject, but if you didn`t knew already, the REAL money come from MAINTENANCE and not from PRODUCTION. I actually have knowledge of a project where bugs were intentionally left so that they could send people on sites for maintenance. (THIS APPLIES TO MEDIUM TO LARGE PROJECTS)
Agreed about the importance of maintenance; if you want lots of work, learn cobol or pl/1. Concerning your example, people try to profit from a system, and thus, your example of dishonesty does not surprise me. For your information, there are internal dev teams of large companies that seed errors in code for QA to find. Why? Because QA decides if they can modify the codebase. With the go ahead, the dev team can modify the codebase to clean it up.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.