Presentation: Ken Schwaber on Code Quality as a Corporate Asset
- Share
-
- |
Read later
Reading List
Ken Schwaber, co-creator of Scrum and head of the Scrum Alliance, spoke at Agile2006 on code quality as a corporate asset, controversially telling conference-goers that "a drop in code quality is a drop in the value of a core asset of the company, and ... that [makes it] a CFO, COO, CEO type of decision." InfoQ presents exclusive video of his talk, along with Schwaber's slides, in The Canary in the Coalmine. This presentation covers:
One uncomfortable truth that Scrum can surface is the existence of a culture that produces unmaintainable, cobbled-together legacy code, or as Schwaber called it in this presentation, "Core Functionality". Schwaber described it as follows:
We've all seen teams come up with creative solutions to deliver despite heinous quality problems in existing core software - including recreating core functionality inside their own application. This is just one way that systems become fragmented and difficult to maintain, hampering subsequent projects, until a complete system rewrite looks cheaper than continuing to work with the degraded core codebase.
How do teams find themselves in this all-too-common position? If IT has been acquiescing to unreasonable demands, we continually reinforce the idea that we're goofing off, since we always seem able to squeeze out more when push comes to shove. Doing so builds up a perception that cramming in extra features is free! Whereas, in fact, we're fitting it in by dropping quality. Schwaber's point: "By dropping quality to save our jobs, our customers have come to believe that this 'magic' has no cost, whereas in fact we're severely damaging our companies in the process."
Schwaber says: "As long as we fold, they will continue to ask us to fold." Schwaber's solution:
We can add: a good process cannot hide or compensate for a lack of coaching ethics. We need good processes and good people. If forced to choose... recent experience suggests: go with the good people :-)
Hopefully you're never forced to choose. I think your point about going with good people as a safe bet is that someone will emerge as a leader and put a process in a place.
4
Discuss
- The way product owners and teams should work together
- The place that product owners and teams come from, using Waterfall
- How Scrum falls apart if these habits persist
- How organizations have fallen apart because of these habits
- How to undo these habits.
One uncomfortable truth that Scrum can surface is the existence of a culture that produces unmaintainable, cobbled-together legacy code, or as Schwaber called it in this presentation, "Core Functionality". Schwaber described it as follows:
Core FunctionalitySchwaber talked about system maintenance as a key indicator of poor-quality core software, the extreme case being what he called "design-dead code", which paralyses development whenever integration of new code depends on changes to core code, where development is painfully slow and risky. He pointed out that quality isn't some intangible thing: it can actually be measured by the amount of time the team spends maintaining the system. This becomes critical when it impacts delivery of software that could offer competitive advantage, giving the example of Microsoft's long product delivery cycle versus Google's very short cycles. Even when teams use Agile methods, their "Agile advantage" can be more than negated if code quality slips, progressively reducing velocity until the team, and the company, are unable to respond rapidly to change.
- Most significant new functionality builds on it;
- It is fragile, it doesn’t have test harnesses;
- Few people still know how to (or are willing to) touch it; and,
- It requires more time to work on (lower velocity) than new code.
- Sometimes called infrastructure or legacy software.
We've all seen teams come up with creative solutions to deliver despite heinous quality problems in existing core software - including recreating core functionality inside their own application. This is just one way that systems become fragmented and difficult to maintain, hampering subsequent projects, until a complete system rewrite looks cheaper than continuing to work with the degraded core codebase.
How do teams find themselves in this all-too-common position? If IT has been acquiescing to unreasonable demands, we continually reinforce the idea that we're goofing off, since we always seem able to squeeze out more when push comes to shove. Doing so builds up a perception that cramming in extra features is free! Whereas, in fact, we're fitting it in by dropping quality. Schwaber's point: "By dropping quality to save our jobs, our customers have come to believe that this 'magic' has no cost, whereas in fact we're severely damaging our companies in the process."
Schwaber says: "As long as we fold, they will continue to ask us to fold." Schwaber's solution:
We have to be courageous. The intention of this conversation is to make you aware that it's not just a phrase, "be courageous", but it's a professional responsibility which, if you follow up on it, not only will you feel better when you come to work, but it is for the good of your company. And if you don't do it... it's going to kill your company. This is not just a trivial little thing, "let's not refactor because...", this is a sacred trust ... to drop quality is a catastrophe for our company.Schwaber proposed strategies for disengaging from the vicious downward spiral, including building models and tracking delivery cycle time against competitors to evaluate the impact of decreased velocity due to poor quality, to allow executives to make informed strategic decisions. He also proposed:
Worse yet, our pattern is not to tell anyone, right? So a classic thing we do now is: if you are in a release and the customer absolutely has to have it earlier and the quality has to be dropped... that is not a Product Owner decision, that is not a Customer decision, that is a drop in the value of a core asset of the company, and it has to go in the books. That is a CFO, COO, CEO type of decision.
Apprise the CEO of this problem: that this is the root cause that the company cannot build new software to meet competitive threats.Schwaber is an informative and entertaining speaker, even while he's tackling these uncomfortable truths. Watch the InfoQ video of Ken Schwaber's Agile 2006 presentation: The Canary in the Coalmine.
Why? Because the only time I've succeeded in getting engineers over the fear of actually standing up and saying "I know that you really want to do that, but it's not a velocity that's sustainable to us at the quality that the company expects," is when the CEO comes into the room and says "If anyone tries pushing you or bullying you into something you can't do, you come to me," because now everyone knows the consequences.
Rate this Article
- Editor Review
- Chief Editor Action
Submit
Submit
Related Sponsor
Discover the 11 Disciplines of Continuous Testing you need to consider to truly shift left.
Hello stranger!
You need to Register an InfoQ account or Login or login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think
Community comments
A ray of hope
by
Cameron Purdy
Posted
The importance of Transparency and Ethics
by
Noah Campbell
Posted
Re: The importance of Transparency and Ethics
by
Deborah Hartmann
Posted
Re: The importance of Transparency and Ethics
by
Noah Campbell
Posted
A ray of hope
by
Cameron Purdy
I tend to disagree with a lot of the Agile(tm) Consultants(tm) and Speakers(tm), but I really do like the core idea that one can view "Code Quality as a Corporate Asset". Whether or not one can have get "the CEO [to come] into the room and [say]" anything seems about as far-fetched as the other Schwaberisms, but we (anyone writing code -- even test code and example code) should always view "Code Quality as a Corporate Asset", and we should also view it as our craft, i.e. we should build it with great pride of worksmanship.
Peace,
Cameron Purdy
Tangosol Coherence: Clustered Cache
Peace,
Cameron Purdy
Tangosol Coherence: Clustered Cache
The importance of Transparency and Ethics
by
Noah Campbell
Great presentation!
I have to admit that I too find the Agile(tm) Consultants(tm) and Speakers(tm) to be a bit underwhelming in their rhetoric. Scrum as a management process is what usually draws me to these presentations and the key to this presentation is that Scrum builds in transparency into the process. That's not to say that RUP, Waterfall, etc. can have equal transparency, but short iterations do put the spotlight on potentially ugly practices...and that's the key to the this presentation. What do you do when presented with difficult decisions?
In Beck and Schwaber's words: have the courage to do the ethical thing.
I have to admit that I too find the Agile(tm) Consultants(tm) and Speakers(tm) to be a bit underwhelming in their rhetoric. Scrum as a management process is what usually draws me to these presentations and the key to this presentation is that Scrum builds in transparency into the process. That's not to say that RUP, Waterfall, etc. can have equal transparency, but short iterations do put the spotlight on potentially ugly practices...and that's the key to the this presentation. What do you do when presented with difficult decisions?
In Beck and Schwaber's words: have the courage to do the ethical thing.
Re: The importance of Transparency and Ethics
by
Deborah Hartmann
Scrum as a management process is what usually draws me to these presentations and the key to this presentation is that Scrum builds in transparency into the process.Yes, this emphasis on transparency is one of the things that draws me to Scrum as well. But, as others have said, a good process cannot "fix" shoddy developers. Scrum relies on the team to bring skill and common sense into the mix.
We can add: a good process cannot hide or compensate for a lack of coaching ethics. We need good processes and good people. If forced to choose... recent experience suggests: go with the good people :-)
Re: The importance of Transparency and Ethics
by
Noah Campbell
If forced to choose... recent experience suggests: go with the good people :-)
Hopefully you're never forced to choose. I think your point about going with good people as a safe bet is that someone will emerge as a leader and put a process in a place.
