Tracking change and innovation in the enterprise software development community
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
Free Book Offer
SOA Demystified
$40 Value
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Posted by Amr Elssamadisy on Dec 03, 2007
If a customer tells you that they are not interested in software quality, that they have a specific scope that must be completed by a specific date - what do you do? Do you listen to the customer and compromise quality? (By the way, what is quality?)
Simon Baker asks should you always do what the customer wants?
If the customer says he doesn't want "perfect code", he's happy to take low quality code as long it does what he wants it to do, what do you do? We're here to deliver what the customer wants, right. So, do you cut corners on quality? I wouldn't. I'd want to understand the customer's thinking and if it turns out that it's short-term thinking ("I want the cheapest solution so I don't care about quality"), or it's ignorance or plain old stupidity, I'd walk away. My conscience wouldn't permit me to compromise the quality of my work.
And, on the ScrumDevelopment Yahoo! Group a related discussion has been taking place discussing whether or not "quality" should be non-negotiable. The discussion started with a question from Pierre Mengal:
I'm facing a case where the customer don't care about the quality because for him, this is a waste of time. They have firm deadline, not extensible resources and can't reduce scope. They are willing to rewrite completely the application few months after the release if they really have too. This is definitely not a problem of development cost at all (they can loose millions by not releasing the day of the deadline).
Esther Derby responded with a query:
I am curious about the statement “quality is not negotiable.”
Quality is not an absolute term and *must* be negotiated to reach a shared, specific definition. For me, it’s more helpful to say that “I won’t sacrifice the negotiated level of quality.”
Jerry Weinberg has said “quality is value to some person.” The task is to find out where that value lies.
You might take a look at Jerry’s Quality Software Management series.
Also Kathy Iberle wrote a nice paper “They Don’t Care about Quality” which addresses “quality” within different business contexts here: http://www.kiberle.com/2003/STAREast2003.pdf
Lance Walton pinged in suggesting that we don't have a firm definition for quality:
A very obvious problem here is that 'quality' is a poorly defined term. What if, for example, 'release something even in [sic] poor quality' actually meant releasing something that crashed every time a user tried to save their work (it might make a difference if the work was actually saved before the crash, I suppose). Or what about if it
meant every keystroke took 10 seconds to process. Would these be acceptable under the 'release something even in [sic] poor quality' banner?
Alistair Cockburn gave an illustrating example:
I just visited a company (A) whose software is selling more than their
competitor's (B), enough to be driving B defunct. The person I was
talking to said that B's product performed more functions, faster and
with fewer bugs than A's did, but B hadn't created an in-field expert
support organization, as A had.From their customers' perspective, product A had "higher quality" than
product B. Customers bought product A and not product B.Simply avoiding bugs and writing maintainable code does not yet deliver quality. Someone still has to buy it. Deciding to buy it is the
indicator of "what counts as quality".There are uncountably finite number of dimensions to "quality", and
much negotiating to be done over which dimensions rank in which order, and much of each is needed. When you go out of business, saying "bug-free and maintainable" doesn't count for much.
Another way to look at quality was discussed in Ken Schwaber's presentation Agile Quality: A Canary in a Coal Mine which suggests that code quality should be taken as a corporate asset.
So, should we listen to the customers when they say they don't care about quality? Should we do what they ask blindly or ignore them because we know better? Or, is there another way? What conversations should we be having with our customers to build the best software?
Learning to be a Good Product Owner: Foundation Skills
Design in Agile, Software Craftsmanship, Product Development, Testing @ QCon London in March
VersionOne is recognized by Agile practitioners as the leader in Agile project management tools. Companies such as Adobe, BBC, CNN, Dow, HP, IBM, Sony and 3M have turned to VersionOne to help deliver greater value to their customers.
Inclined to agree that quality is not absolute, and must be negotiated before it can be understood. For instance, if you look at code coverage as one potential measure of quality, it's exceptionally difficult to cover all code completely by all coverage measures. Accepting that one almost never has time to completely test code is a good start to accepting that quality is negotiated.
That said, there are some good examples in this thread about some examples of a quality standard that might not be acceptable. If you feel your customer's desired quality level endangers the project in other ways, then you should make that clear, and then, if necessary, walk away.
On the other hand, quality is often negotiable to a reasonable rate, and customers are often willing to listen to concerns about quality levels, when there aren't overriding business concerns.
In the situation described:They are willing to rewrite completely the application few months after the release if they really have too. This is definitely not a problem of development cost at all (they can loose millions by not releasing the day of the deadline).
There's a challenge here -- deliver the right kinds of quality (an application that doesn't sacrifice business needs by not working) without unnecessary costs (the kinds of quality that could cause the release date to slip).
If that's a challenge you think you can meet acceptably with a margin for error, then I think it can be appropriate. If there's no margin for error or you fear it's not possible to deliver in the deadline an application that will work reliably, then those are conversations that need to happen.
I will note that there's often a hidden cost to quality negotiations: morale. Many developers don't like to feel as if they're being asked to deliver a sub-standard product, and if you push them in that direction, morale may suffer.
I maintain that it is very dangerous to take this statement at face value. This cannot be the start of a conversation.
First, you must back up one step, or maybe more. The term "quality" is loaded - and in the customer/user world, may be loaded in a completely different way than in the developer world! (As exemplified in the Cockburn story, above)
We need to learn a new kneejerk reaction to this: "What do you mean by that?"
Surprisingly, one client said "I don't care how elegant the solution is, but it needs to work!" Hmmm, is that what dev thought when they heard the statement, at first? :-)
deb
Quality means costs and risks that grow geometrically when deferred.
> "I don't care how elegant the solution is, but it needs to work!"
This could be also my first reaction to the client request: non-working code is just wasting resources, so one thing we could sacrifice, I guess, would be refactoring.
However, my experience is that:
-velocity goes down quite fast when refactoring is not done regularly
-it is very dangerous in the game of expectations, because the "[we will] rewrite completely the application few months after the release if [we] have to" is often forgotten after the first success (but of course, without that first success there is sometimes no second chance)
Anyway, even if we try to negociate quality, this is a real challenge to fix precise criteria upfront:
-how do we know we've tested enough according to the "Quality threshold"?
-how do we know we have a maintainable enough system according to the "Quality threshold"?
-how do we know we have a usable enough system according to the "Quality threshold"?
Most of the time, and especially on projects with hard deadlines, the "Quality threshold" is very subjective I think. Does anyone has a successfull experience of negociated quality with tangible metrics?
Eric.
Surprisingly, one client said "I don't care how elegant the solution is, but it needs to work!" Hmmm, is that what dev thought when they heard the statement, at first?
Depends on what you mean by elegant. ;)
There are plenty of good business reasons to sacrifice code quality (e.g. adherence to O-O principles, test coverage, readability, etc.) in order to meet a hard deadline. It's the responsibility of the development team to listen to and respect those reasons.
However, it's the also responsibility of the development team to remind the business that each 'short-cut' is another charge to the Technical Debt credit card. If that debt isn't paid off at some point, hired goons will show up at your door, baseball bats in hand. It's the responsibility of the business to listen to the development team and allow them to pay down that debt after the deadline has passed.
While cutting corners can increase velocity over the shorter term in order to meet a deadline, long term velocity will suffer if Technical Debt isn't kept to a minimum.
Dave Rooney
Mayford Technologies
Hmmm.... I always thought that one of the great things about Agile was that it gave the Customer more power - since *they* know the business then they make the priority decisions and what gets done first.
At the same time, we could go overboard. Shouldn't the developer's make development decisions? Gold-plating is something, and writing bug-free code that meets the individual's definition of quality code is something else.
Aren't we all professionals? Shouldn't we trust each other to do the best that we can. Developers shouldn't be dictating business decisions, but isn't the opposite also true?
All of this - it should go without saying - is within the context of a self-organizing team that communicates well and communicates via GOALS instead of individual steps.
However, it's the also responsibility of the development team to remind the business that each 'short-cut' is another charge to the Technical Debt credit card. If that debt isn't paid off at some point, hired goons will show up at your door, baseball bats in hand. It's the responsibility of the business to listen to the development team and allow them to pay down that debt after the deadline has passed.
While cutting corners can increase velocity over the shorter term in order to meet a deadline, long term velocity will suffer if Technical Debt isn't kept to a minimum.
And because technical debt is difficult to see, assess, measure for developers, let alone for business, it's very important that business have some understanding of what that means, and that development is able to clearly communicate about the current state of that debt, and the debt likely to be incurred by a particular course of action. That's not an easy task, but it seems imperative unless the directives from the business are to keep all quality knobs turned up as high as the team believe they need to be at all times (which is very rarely true).
Aren't we all professionals? Shouldn't we trust each other to do the best that we can. Developers shouldn't be dictating business decisions, but isn't the opposite also true?
In a perfect world, yes. Last I checked, the world in which I live isn't perfect! :)
I do agree, though, that teams with good communication handle these issue quickly and efficiently. On a coaching gig about 18 months ago, I was working with a developer trying to bring a part of an application under test. He wondered out loud why a certain small feature was needed, and if corners could be cut by not implementing it. I said that it sounded like a question that needed to be asked of the Customer who, by virtue of this being a Whole Team in One Room, was a few metres away. Her answer was that the feature would allow (the product) to compete directly with (a product from a competitor recognized globally). In less than 2 minutes, the developer had a perfect understanding of the business value and why he had to do something.
On another coaching assignment, it worked the other way. The developers were telling the customer that they had to do the work a certain way, because they already had a framework that they wanted to leverage. However, the cost (in terms of person-days required to implement the feature) was prohibitively high from the Customer's perspective. After considerable prodding by myself and another coach, the developers were able to propose a simpler solution that took a fraction of the time, although they had to build several pieces of it manually despite having a framework and tools that automated many of the steps.
So, in the latter case, the Customer indicated that the cost was simply too high, which was absolutely her prerogative. That caused the developers to rethink their work, and look for a simpler, less costly solution (which they did).
Would the developers incur some technical debt as a result of the simpler solution? Quite probably. However, looking the alternative of the cost of established solution, trying something simpler was the accepted alternative.
These are both cases where both the Business and Development influence each other's work, although they don't dictate it. They are also examples of goal-related thinking rather than task-related thinking.
Dave Rooney
Mayford Technologies
To clarify:
> Surprisingly, one client said "I don't care how elegant the solution is, but it needs to work!"
The background: I believe their team had been trying to give them very comprehensive solutions to their needs, while blowing their target dates and delivering buggy code.
I'm a little surprised by some of the responses here. I would have thought that most would understand that quality is definitely negotiable.
I think we all understand, even if it's just in our hindbrain, that we can't test everything, even those of us doing TDD. Testing everything is a good way to turn a $50 product into a $500 dollar version.
So, if we understand that we're already compromising, can't we also accept the possibility that our current understanding of what's "enough" may be too much? If there are different grades of steel for different uses, is it possible to have different grades of software?
If you don't think so, all you have to do is take a look at the games software industry. They usually have frozen release dates, especially at this time of year, and it can be difficult to reduce scope. Most publishers will opt to release a buggy game and patch it later without much thought. Sure, this results in buggy games but it's also not unusual for those games to go on to become financial hits.
If you don't think so, all you have to do is take a look at the games software industry. They usually have frozen release dates, especially at this time of year, and it can be difficult to reduce scope.
Good point, but because they do it doesn't make it the best decision necessarily. In fact, being an occasional WoW player myself, they've released with reduced scope and patched that scope later on.
The scope-time-quality constraints are the same - but if we don't ask the question of reducing scope....
i think its a great idea, you can even go further - you can say - we can deliever product on time, but we wont have enough time to test it, so we wont be responsible for possible bugs. Then customer has choice and if he doest care about quality why force him? Of cause the best idea will be to educate him, but i think that many of them know how it all works.
I have never seen a customer who was willing to pay to get the quality up. It's always "10 to 20% of our needs working and a way to put bugs into change control with low cost resources to fix it after the initial project".
I imagine it is hard to understand why the software is built buggy in the first place, looking at it from the business point of view. It's just like building a house right?
I couldn't speak for southern Europe but I have had the same type of customer...
Part of the problem is related in our relationships to customers and an Us vs. Them relationship. The answer is touchy-feely, and very related to communication, personal responsibility, and clarity of the goals.
These issues are hard in any/all cultures and - I would venture to suggest - these points are applicable in multiple cultures.
You might want to check out Teamwork is an Individual Skill.
The other three points are cost, speed-to-market, and scope. We are not magic. An increase in any one of these areas needs to have a corresponding decrease in another. You can't increase quality without impacting either cost, speed-to-market, or scope. This needs to be negotiated with the customer at the start of every project, and every time any one of these factors changes, the discussion needs to be had again.
As for the implementation of Quality, you go back to the requirements determination phase, and implement non-functional requirements, which may be in the areas of usability, reliability, performance, security, safety, or supportability. It's the lack of these "Non-Functional" requirements that leads people to say "that product has low quality." It's simple to implement non-functional requirements, you can say for example "it is a requirement of this system that any the downtime is less than five minutes per month." You say that at requirements determination stage, *before* design starts, and the system gets built that way. Of course it's not cheap, and there is a corresponding increase in either cost, speed-to-market, or reduction in scope. And the customer must be negotiated with and agree. If they don't want the extra, they don't pay for it, they get the product faster, the scope does not budge upwards, and they get their "user-defined" level of quality.
Quality can be negotiated, but it should be discussed with the customer where they want to reduce the quality.
So where they want to reduce the time?
In design,requirenment , testing or coding.
In software quality is not just one line.It is applied at various levels in different way.
Further to
> It's just like building a house right?
"The Software / Construction Analogy is Broken"
> If they don't want the extra, they don't pay for it,
> they get the product faster, the scope does not budge
> upwards, and they get their "user-defined" level of
> quality.
And your software contracting company gets nasty blog press, don't forget about that!
Well, there may be a difference between "economy" quality and irresponsible quality. I admit it's difficult but I believe it is possible to set an appropriate level of quality that may be lower than what we would normally seek and yet deliver a product that satisfies the customer, the market, and ourselves.
If the customer pushes to dial quality into the irresponsible range, then the only thing we can do is push back or walk.
Sure, they can do that with WoW now, since they essentially have their walking skeleton in place.
However, if you think back to launch day, how was it? :)
Yep. There is a level below a minimum scope where value becomes zero. This is similar to a Minimum Marketable Feature (MMF) in Naked Planning .
It's a good (though completely illogical) rule of thumb that the exact same piece of software as deployed successfully will have bugs if it wasn't tested. My experience at least seems to match this rule. :-)
Is this Shroedinger's Code?
> Well, there may be a difference between
> "economy" quality and irresponsible quality.
I'd counter with this: There is also a difference between "responsible quality" and gilding the hammer.
The way to navigate between these two extremes is frank discussion with customers about their needs and the risks we perceive.
And, yes, sometimes it's time to walk. After you've discussed, of course, so everyone is aware of what happened.
PS: I'm astonished - Google has finally failed me. I wanted to include a web definition of "gilding the hammer" but...
look at the games software industry. They usually have frozen release dates, especially at this time of year, and it can be difficult to reduce scope... Sure, this results in buggy games
Hmm, this may explain the apparent surge in use of Agile in the games industry this past year!
Who's going to write the app that will let us send out credit-card statements to management for their accumulated technical debt? With a Jira-compatible interface or something.
Call it "FemaCard" maybe? ;-> or the MasterCanary card?
Ok, I'm probably the guilty party since I wrote the post, but.... Are we over-analyzing the problem?
It seems to me that this is really a question of communication of goals or tasks.
If we communicate through goals, then we can have a scenario similar to Dave Rooney's comments above:
I do agree, though, that teams with good communication handle these issue quickly and efficiently. On a coaching gig about 18 months ago, I was working with a developer trying to bring a part of an application under test. He wondered out loud why a certain small feature was needed, and if corners could be cut by not implementing it. I said that it sounded like a question that needed to be asked of the Customer who, by virtue of this being a Whole Team in One Room, was a few metres away. Her answer was that the feature would allow (the product) to compete directly with (a product from a competitor recognized globally). In less than 2 minutes, the developer had a perfect understanding of the business value and why he had to do something.
If we communicate through tasks, then we could (and probably do) have customers and developers telling each other how to do their job depending on the more dominant partner.
I vote for scenario one! Then it is up to you - the team member - to decide how you are going to achieve that goal - deal with it! ;) When I'm given a Goal then I'll choose not to compromise quality - as in no bugs and no cut&paste - but I'll do my best to acheive the customer's goals and time periods. When in conflict we'll have a conversation and see what we can slice away... Both from my end and theirs. But that's just me.
Hey folks. I have a question. It's unusual that a thread goes on for so many days (but fun!).
We hope to get a way to provide notification for "watched" comment threads, but for now it's entirely manual. So can you tell me:
How did you follow this thread? Did you go back and reread it manually to follow the conversation? Just interested from an editorial point of view. Feedback is always good.
Thanks
deb
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
30 comments
Watch Thread Reply