Perception that high quality equals Rolls Royce

[Matthew Riley]

Hello everyone,

My team has been involved in developing an iPhone application using Agile methods with a very high degree of test automation.

We have successfully delivered the project with a minimum of defects and we are proud to have accomplished this.

The business manages a number of other software projects outside of our team, not using Agile methods, have a lot of defects and a lot of manual testing.

With this contrast a perception has formed that we build the Rolls Royce of software which may be overkill for their needs.

What they are really saying is they may not require the level of quality we have built into the software and may be willing to compromise on quality.

Throughout the course of the project, we have been trying to educate the business on the benefits of these approaches, with limited success.

It's obviously very difficult to prove the benefits objectively to non-technical people, and there's absolutely politics at play.

I doubt very much this is a unique situation. Has anyone had any success managing this scenario and how did you go about it?

Thanks, Matt

[Raoul Duke]

how much more do you really cost than the others?! how much sooner or
later do your ship than the others?! how many bugs do the others then
spend time dealing with after the ship date?! (of course, accounting
is subjective, so people who don't like your team approach can show
one way of accounting that shows you are too expensive if they like.)

[Ron Jeffries]

Hi Matthew,

On Apr 22, 2013, at 9:20 PM, Matthew Riley <mat...@matthewriley.name> wrote:

With this contrast a perception has formed that we build the Rolls Royce of software which may be overkill for their needs.

What they are really saying is they may not require the level of quality we have built into the software and may be willing to compromise on quality.

Throughout the course of the project, we have been trying to educate the business on the benefits of these approaches, with limited success.

It's obviously very difficult to prove the benefits objectively to non-technical people, and there's absolutely politics at play.

I doubt very much this is a unique situation. Has anyone had any success managing this scenario and how did you go about it?

If they really want more defects, all they have to do is ask for them.

There is no effective way to compromise on code quality over even the medium term. However, if the application doesn't have to work, you can slam any old crap together.

Ron Jeffries

www.XProgramming.com 

Before you contradict an old man, my fair friend, you should endeavor to understand him. - George Santayana

[J. B. Rainsberger]

First, it's their money. Ultimately, the business retains the right to pay for the defect level they can live with.

In this situation, your job includes showing them that they're not overpaying for a low defect rate, but rather profiting from it. How will you convince them of this from your experience with stories from your projects? Tell them all about the stuff you *don't* do because of how carefully you work. How much more would your last project have cost working with your company's typical defect rate? Tell a story that focuses on that.

-- 

J. B. (Joe) Rainsberger :: http://www.myagiletutor.com :: http://www.jbrains.ca ::
http://blog.thecodewhisperer.com
Free Your Mind to Do Great Work :: http://www.freeyourmind-dogreatwork.com

[Sleepyfox]

I've seen this straw man argument too many times in this industry from managers who don't understand management, let alone software. It's not the difference between a 'Rolls Royce' and a normal car, it's the difference between a normal car and a 'cut 'n shut'; i.e. the difference between fit for purpose and dangerously hacked-together and un-roadworthy. 

Fox

--

--
You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.
To unsubscribe from this group and stop receiving emails from it, send an email to software_craftsma...@googlegroups.com.
To post to this group, send email to software_cr...@googlegroups.com.
Visit this group at http://groups.google.com/group/software_craftsmanship?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[David Wilde]

I can actually see where management are coming from on this one. I went on an itil course where I was challenged by the question - if you went to a hosting company and specified an uptime of 99% would it be a good thing if they delivered 100%. We all said yes but when the instructor explained the costs involved in that extra 1% and how either they are passing that cost onto you the customer or they will soon end up broke.

Management have mistakenly attributed this same approach to your work. They feel that without all of the inbuilt quality the costs could be even lower. This is the false economy because building quality in is far cheaper than fixing it later.

If this were me I'd start banding around pseudo agile terms to get their business.  Suggest that your iphone app was developed with 100% code coverage in order to benchmark quality and the next projext will be delivered with 75% to reduce costs. Give them a higher estimate with 100% and the real one with 75%. Once you get the business no one will care when you exceed expectations. how many successful profitable projects before all the politics swings your way?

--

[Ron Jeffries]

David,

On Apr 24, 2013, at 4:38 PM, David Wilde <djw...@gmail.com> wrote:

If this were me I'd start banding around pseudo agile terms to get their business.  Suggest that your iphone app was developed with 100% code coverage in order to benchmark quality and the next projext will be delivered with 75% to reduce costs. Give them a higher estimate with 100% and the real one with 75%. Once you get the business no one will care when you exceed expectations. how many successful profitable projects before all the politics swings your way?

I don't think I would recommend lying, even if it worked. 

Ron Jeffries

www.XProgramming.com

I know we always like to say it'll be easier to do it now than it

will be to do it later. Not likely. I plan to be smarter later than

I am now, so I think it'll be just as easy later, maybe even easier.

Why pay now when we can pay later?

[Sleepyfox]

Gather data, make a business case. You can find a recipe for doing this in the slides that I produced for a briefing on Cost Of Poor Quality (COPQ) here: http://radtac-craft.github.io/breakfast-briefing-oct2012/#/

Fox

--

[David Wilde]

Your probably right, you usually are. I think, however that management are just looking to save hypothetical costs rather than judging on the success.

Maybe a more appropriate solution would be to isolate areas of future projects where they expect rolls royce quality and suggest your team work on those. There are invariably features of a system that business will not want to scrimp. Once you deliver your features on time and on budget the other teams will want to learn from you.

David

[Adam Sroka]

Management likes to feel like they are in control, but the reality is they have absolutely no idea how we do what we do. Tell them what they need to know to feel in control, but never appologize for doing or ask permission to do quality work. 

If you were an artist would you put your name on something that just sort of sucked? If you were an author would you publish something that was almost spelled right? Nonsense. 

[Sleepyfox]

@David - I'm not sure that would be my approach, as it's playing to the destructive mindset of 'software as manufacturing'. My approach has been to gather data on the cost of remediating work that I call 'sub-standard/unprofessional' but which sadly gets labelled as 'average' by most management.

When you calculate the cost of rework and schedule slippage and technical debt, the ROI on improving software quality to MVP (Minimum Viable Programmer rather than Product) level is typically at least 5:1[1] - once they see this they

Fox 

"If you think it's expensive to hire a professional, wait till you hire an amateur!" -- Red Adair 

-- 

[1] http://virtual.vtt.fi/virtual/proj1/projects/moose/docs/ieeesoftware_measuring_roi%20of%20spi.pdf

[Sleepyfox]

End of sentence should read: 'Once they see this they rarely complain'

[Caio Fernando Bertoldi Paes de Andrade]

On 24 Apr 2013, at 20:16, J. B. Rainsberger <m...@jbrains.ca> wrote:

First, it's their money. Ultimately, the business retains the right to pay for the defect level they can live with.

Before the money comes the craftsman.

Try to ask a doctor or any engineer to do a crappy job in order to reduce costs. Engineers can change product's materials to cheaper ones, they can change product's final characteristics, but they don't change their level of attention and their process of doing things the way they think it's right. Doctors can perform simpler or different procedures by patient request, impacting somehow on the final result, but the attention, caring and cleanliness will be the same.

If the client/patient/customer/employer insists, they act professionally saying "No, I won't do it, find another person to do it for you". Obviously, in the software field and in an employer-employee situation this is very hard to do. We are not used to act like that.

Technical discussions with client/customer/employer, if there has to be any, should be around tools, frameworks and user interface, i.e. the details in the architecture and their impact in the visible quality to the user (performance, interface). Code quality shouldn't be a handler that managers can twist (or even turn off).

Cheers,

Caio

Quality is inversely proportional to cost, and if managers don't get it, craftsmen do.

[David Wilde]

Im juat not sure that stats and data on software processes are the key to constructive dialog. Its the success that counts. you have a successful project so you should be building on that. However you go about it don't let a successful team become a worse one.

[Ron Jeffries]

Hi David,

On Apr 24, 2013, at 5:02 PM, David Wilde <djw...@gmail.com> wrote:

Your probably right, you usually are. I think, however that management are just looking to save hypothetical costs rather than judging on the success.

Yes, management's statement gives me concern as well. I'd be inclined to play the cards I have, rather than start making up stuff. It's too hard to keep track.

I would begin my conversation with them by asking them if they want more bugs. I'd be surprised if they did, but I'd be prepared to ask what bugs they wanted. I really don't think they'll want to go down that path. I would point out that we can't choose where the bugs go. They go in randomly … if anything it seems they go to the worst possible places. I would point out that it takes longer to find and fix a defect than it does to prevent it with tests. So if we back off on testing, we'll slow down rather than speed up. Even worse, I'd mention, is the fact that some of those bugs would creep out and affect customers, since, after all, we're not finding them with the tests we're not writing. That means that we still have to do more work to find the bug than we would have done preventing it, but that we do it with pissed-off customers and the need to express a fix out into the field. That's risky, and even if it works, we look like shitheads. 

I'd be pretty sure that we wouldn't have to go very far down the bug path before they'd back off on that aspect.

They would then want to talk about gold plating. I'd probably ask whether they could think of an example where something was gold plated and should have been only silver. Odds are they have no examples. If so, I'd say "that's right. There are no examples. We work to a suitable level of code quality, slated to keep us moving as fast as possible."

I might go off on a bit of a tangent about why clean code is better. My main reason is that clean code is mostly about removing duplication. Duplication slows us down and increases errors. We've already established that we don't want more errors. In addition, when we make changes, as we will, because they ask for them, we often have to make corresponding changes in multiple places, since we have that duplication. But each duplicated section is a little bit different, and we have to think about all of them separately. This, too, takes more time. When we remove duplication as soon as we created it, we reduce error creation and we save time as we move the product forward.

If this didn't work, I'd kill one of them as an example to the others. 

Maybe a more appropriate solution would be to isolate areas of future projects where they expect rolls royce quality and suggest your team work on those. There are invariably features of a system that business will not want to scrimp. Once you deliver your features on time and on budget the other teams will want to learn from you.

I really don't think this works. I don't think crappy code is ever really faster to build than good code, even over the middle term. To push something out this week just to see if people like it? Maybe. But even then, if it has to work, we're taking a chance.

Ron Jeffries

www.XProgramming.com

It's true hard work never killed anybody, but I figure, why take the chance?

-- Ronald Reagan

[Ron Jeffries]

Hi Adam,

On Apr 24, 2013, at 5:07 PM, Adam Sroka <adam....@gmail.com> wrote:

Management likes to feel like they are in control, but the reality is they have absolutely no idea how we do what we do. Tell them what they need to know to feel in control, but never appologize for doing or ask permission to do quality work. 

If you were an artist would you put your name on something that just sort of sucked? If you were an author would you publish something that was almost spelled right? Nonsense. 

Well, kind of. But in the end, whatever we're doing can always be improved. We do have to push it out the door, and we probably won't be entirely happy, because we know things that still should be done.

But we have to ship it. Which is why we do it as well as we can, as we go along. Because on shipping day, we want as few regrets as possible. Still, there will be a few.

Ron Jeffries

www.XProgramming.com

Don't ignore your dreams; don't work too much; say what you think; cultivate friendships; be happy. -- Paul Graham

[Raoul Duke]

you, sir, are hired! (too bad i'm broke.)

[Ron Jeffries]

Hi David,

On Apr 24, 2013, at 5:31 PM, David Wilde <djw...@gmail.com> wrote:

Im juat not sure that stats and data on software processes are the key to constructive dialog. Its the success that counts. you have a successful project so you should be building on that. However you go about it don't let a successful team become a worse one.

I agree with that. This is an emotional discussion. Facts are not a satisfying diet for the emotions. Oh, I'd have them at my fingertips, but somehow the discussion has to reach their emotions.

That's tricky for a guy like me, who apparently doesn't have any emotions and often doesn't recognize them in others. This is why I plan my approach in advance, when I have time to think about what other people probably feel. :)

Or else I do it because stupidity really pisses me off and I like to know what I'm going to say to have a chance of keeping my cool.

I forget which it is. :)

Ron Jeffries

www.XProgramming.com

I try to Zen through it and keep my voice very mellow and low.

Inside I am screaming and have a machine gun.

Yin and Yang I figure.

  -- Tom Jeffries

[Ron Jeffries]

Got any friends with money? :)

On Apr 24, 2013, at 7:19 PM, Raoul Duke <rao...@gmail.com> wrote:

you, sir, are hired! (too bad i'm broke.)

[David Wilde]

I do feel that the strongest argument in this case is that a team want to build on their success. They have obviously worked well together and acheved something they are proud of. Suggest that the high degree of confidence in the product motivated the team to work harder on it all the way through. You guys obviously want to work this way again.

The biggest issue for politics here would be if your approach bashes the non-agile teams more than emphasises your achievement.

Good luck!

[Sleepyfox]

Good response Ron, I especially like:

"If this didn't work, I'd kill one of them as an example to the others."

The only thing that niggles me is the feeling that I'm not sure that trying to explain to management why we work the way that we do is productive: I think that this reinforces their underlying belief that they have the right to tell us how to do our work because they know better than we do. This Taylorist model of thinking is completely inappropriate to us as professionals, and is an example of the meta-cognitive bias called the Dunning Kruger effect[1] (they don't know what they don't know).

I think @Caio's point about professional standards is really insightful too, clients don't try and tell their doctors or lawyers how to do their job, and if they do, they get short shrift (try telling your surgeon next time that you're in hospital that he doesn't need to wash his hands, after all you're both in a hurry...) We need the courage to stand up for our position as professionals, which is why 'courage' is one of the five Scrum values and one of the five XP values too.

Fox

--

[1] http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect

[Ron Jeffries]

Hi Fox,

On Apr 25, 2013, at 4:49 AM, Sleepyfox <slee...@gmail.com> wrote:

Good response Ron, I especially like:

"If this didn't work, I'd kill one of them as an example to the others."

Well it has worked for me. :)

The only thing that niggles me is the feeling that I'm not sure that trying to explain to management why we work the way that we do is productive: I think that this reinforces their underlying belief that they have the right to tell us how to do our work because they know better than we do. This Taylorist model of thinking is completely inappropriate to us as professionals, and is an example of the meta-cognitive bias called the Dunning Kruger effect[1] (they don't know what they don't know).

I tend to agree. I do think that some developers do gold plate things some times, and those of us on this list, who are interested in the craft, are probably more likely to fall into that trap. So it is a valid question, and worth considering whether the team are refining the code too much. "I still don't totally like these variable names, I think I'll try deriving them all from Latin instead of Greek …"

Now I generally find that the product owner and others will put the team under time pressure, and that time pressure will cause the team to do work whose quality is too low, not too high. But it is still possible that we're sanding fifty times when thirty would suffice.

And the other thing to remember is that they have the gold, and they make the rules. So we have to do our best to go at the best pace possible, and to help them understand what's going on.

I think @Caio's point about professional standards is really insightful too, clients don't try and tell their doctors or lawyers how to do their job, and if they do, they get short shrift (try telling your surgeon next time that you're in hospital that he doesn't need to wash his hands, after all you're both in a hurry...) We need the courage to stand up for our position as professionals, which is why 'courage' is one of the five Scrum values and one of the five XP values too.

It is certainly legitimate to ask the physician if there are ways to save. Can he find a suitable drug that is on your insurance? Is there a reasonable way for this procedure to be done on an outpatient basis?

So I think one question is whether everything we do rises to the level of necessity that hygiene has in surgery. My guess is that it does not.

Ron Jeffries

www.XProgramming.com

I'm not bad, I'm just drawn that way.  -- Jessica Rabbit

[Tomas Malmsten]

Hello,

This is an interesting thread with many very valuable insights. Thanks

Ron's last mail made me think about a very common human behaviour. We have a tendency to over compensate for things we have found to be wrong, which makes us swing from one extreme to the other instead of finding a good middle ground. I think this is something to be watchful of. If not there is a risk that we apply the gold plating in our strive to compensate for what used to be really bad hygiene without realising that we've done so.

I don't think there is a very high risk. Most clients I work with are still struggling to find the wash basin, let alone the soap. But due to this there is a risk, if we do meet a manager who values and understands quality, that we go to far.

Regards

Tomas Malmsten

Avega Group 

switchboard +46 40 10 51 00 | direct +46 40 10 51 31 | mobile +46 72 5150 121

Gustav Adolfs Torg 45 | 211 39 Malmö

Homepage: http://www.avegagroup.se/
Twitter: https://twitter.com/tomasmalmsten
Blog: http://www.tomasmalmsten.com/
LinkedIn: https://www.linkedin.com/in/tomasmalmsten

[Sleepyfox]

Ron:

"So I think one question is whether everything we do rises to the
level of necessity that hygiene has in surgery. My guess is that it
does not."

It does not. Of course. I used the metaphor because in my experience
the most common conversations are what the OP mentioned i.e. using
TDD, which I would propose is the equivalent of basic hygiene in
Medicine.

In my 25 years in the IT industry I've experienced a lack of basic
hygiene so many times I cannot count, indeed this is (shockingly)
still prevalent in most organisations that I see in London today. The
number of times I've seen gold-plating I can count on the fingers of
one hand; the combination of pressure to deliver and the prevalence of
YAGNI thinking means it is very hard to gold-plate on most of the
projects that I've experienced.

So yes: let's be careful not to speak in terms of absolutes, but let's
also not throw the baby out with the bathwater.

Fox
--

[Ben Fulton]

Very interesting thread.

I think you have to start from where management is. Presumably, like everyone else, they want software that is good, fast, and cheap.

It appears that Matt's team has moved too far in the direction of "good". I don't see that there's any point in asking management if they want the software to be less good (more buggy) - obviously they don't. They either want it delivered faster or they want fewer person-hours devoted to the project. I wonder, therefore, if they would be willing to compromise on scope to achieve this. Keeping the same level of quality but reducing the number of features might provide space to deliver the software more quickly or with fewer people devoted to the project.

[Sleepyfox]

> It appears that Matt's team has moved too far in the direction of "good".

I'd like to hear Matt's opinion on this, as that's not the read I get
from his OP at all. Instead I read it as "Management wants me to
compromise my and my team's professional standards, in the mistaken
belief that it will be cheaper (which of course it won't)".

Fox
--

[J. B. Rainsberger]

On Wed, Apr 24, 2013 at 6:23 PM, Caio Fernando Bertoldi Paes de Andrade <caio...@gmail.com> wrote:

On 24 Apr 2013, at 20:16, J. B. Rainsberger <m...@jbrains.ca> wrote:

First, it's their money. Ultimately, the business retains the right to pay for the defect level they can live with.

Before the money comes the craftsman.

Try to ask a doctor or any engineer to do a crappy job in order to reduce costs. Engineers can change product's materials to cheaper ones, they can change product's final characteristics, but they don't change their level of attention and their process of doing things the way they think it's right. Doctors can perform simpler or different procedures by patient request, impacting somehow on the final result, but the attention, caring and cleanliness will be the same.

…we like to think. We hope. Many health care disasters result from systemic cost reduction pressures, not only from incompetence or carelessness. Same for engineering disasters. The profit motive guarantees this behavior in general, although many individuals fight it very well.

 

If the client/patient/customer/employer insists, they act professionally saying "No, I won't do it, find another person to do it for you". Obviously, in the software field and in an employer-employee situation this is very hard to do. We are not used to act like that.

Technical discussions with client/customer/employer, if there has to be any, should be around tools, frameworks and user interface, i.e. the details in the architecture and their impact in the visible quality to the user (performance, interface).

Yes; we decide what we're willing to do and not willing to do. We continually negotiate this with our clients and employers. We retain the ultimate right to refuse the work. If we feel too much pressure to refuse the work, then we retain the right to change our lives to make it easier to refuse the work. (I did this.)

> Code quality shouldn't be a handler that managers can twist (or even turn off). 

Unfortunately, if it's their money, then it's their call. They can always find someone else to do the work. I find that I no longer have this problem, because I understand and accept that this is an ongoing negotiation. In the process, I can negotiate with my employer or client a 3-month experiment where I get control over the quality lever. They have to agree. If they agree, then I enforce the agreement ruthlessly. If they like the results, then we continue; and if they don't, then I apologise, and accept the consequences. Even so, it remains a negotiation. Making peace with this has helped me; it might help others.

-- 

[J. B. Rainsberger]

On Wed, Apr 24, 2013 at 8:15 PM, Ron Jeffries <ronje...@acm.org> wrote:

Hi David,

On Apr 24, 2013, at 5:02 PM, David Wilde <djw...@gmail.com> wrote:

Your probably right, you usually are. I think, however that management are just looking to save hypothetical costs rather than judging on the success.

Yes, management's statement gives me concern as well. I'd be inclined to play the cards I have, rather than start making up stuff. It's too hard to keep track.

I would begin my conversation with them by asking them if they want more bugs. I'd be surprised if they did, but I'd be prepared to ask what bugs they wanted. I really don't think they'll want to go down that path. I would point out that we can't choose where the bugs go. They go in randomly … if anything it seems they go to the worst possible places. I would point out that it takes longer to find and fix a defect than it does to prevent it with tests. So if we back off on testing, we'll slow down rather than speed up. […]

I might add that while I don't know how to add in only the right bugs in only the right spots, I do know some techniques for delivering smaller features with more essential value sooner than we do now. This results in more value per feature sooner without the risk of adding in the wrong bugs in the wrong spots. Would you be willing to try this with me?

Even if they don't go for it, the resulting discussion will tell me much more about what they're really worried about, and gives me an opportunity to allay their worries in a way that doesn't counter the way I know I work well.

-- 

[George Dinwiddie]

David,

On 4/24/13 4:38 PM, David Wilde wrote:
> I can actually see where management are coming from on this one. I went
> on an itil course where I was challenged by the question - if you went
> to a hosting company and specified an uptime of 99% would it be a good
> thing if they delivered 100%. We all said yes but when the instructor
> explained the costs involved in that extra 1% and how either they are
> passing that cost onto you the customer or they will soon end up broke.

There is a logical flaw in that argument. Uptime is partly about
preparation for problems, but it's also about the occurrence of
problems. If the hosting company worked for an uptime of 99%, but no
problems happened outside of the ones they'd covered to hit their 99%
goal, then there would be no additional cost.

- George

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[Raoul Duke]

> There is a logical flaw in that argument. Uptime is partly about preparation
> for problems, but it's also about the occurrence of problems. If the hosting
> company worked for an uptime of 99%, but no problems happened outside of the
> ones they'd covered to hit their 99% goal, then there would be no additional
> cost.

i don't think hosting is the only context in which that is true.

[George Dinwiddie]

Ron, David,

On 4/24/13 4:43 PM, Ron Jeffries wrote:
> David,
>
> On Apr 24, 2013, at 4:38 PM, David Wilde <djw...@gmail.com

> <mailto:djw...@gmail.com>> wrote:
>
>> If this were me I'd start banding around pseudo agile terms to get
>> their business. Suggest that your iphone app was developed with 100%
>> code coverage in order to benchmark quality and the next projext will
>> be delivered with 75% to reduce costs. Give them a higher estimate
>> with 100% and the real one with 75%. Once you get the business no one
>> will care when you exceed expectations. how many successful profitable
>> projects before all the politics swings your way?
>
> I don't think I would recommend lying, even if it worked.

Nor would I. But I think the cost estimates are reversed. I would
estimate the 75% solution as more expensive because of
- the time spent repeatedly doing manual testing
- the time spent debugging problems you didn't notice when you created
them
- the time spent figuring out what functionality was finished and what
was not
...

[David Wilde]

George,

This is what we had all thought on the course as well. The idea that chance could cause high availability was the first thought we had all had as well. No problems = Good fortune. 

However when you start to factor in mean time for failure for components, costs of failover systems, expensive zero down time maintenance jobs, business continuity and disaster recovery requirements, then the probability of achieving a high availability system through chance becomes very small indeed. 

There's much more information about high availability systems here - http://en.wikipedia.org/wiki/High_availability 

Try getting some hosting quotes for the difference between a 2 nines availability and a 6 or 7 nines availability system and you will soon realise that there are massive costs involved. Once you realise, you too would start to become concerned if a hosting company massively exceeded your SLA. If these aren't passed on to you the customer then your host will probably go bust soon! At the very least you would want to have a chat with them about how they have achieved this rather than just think "Oh I got lucky". 

David

--
You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.

To unsubscribe from this group and stop receiving emails from it, send an email to software_craftsmanship+unsub...@googlegroups.com.
To post to this group, send email to software_craftsmanship@googlegroups.com.

[Tim Ottinger]

It sounds as though they believe that you spent a lot more time on your low-defect work.

If that's not true, then their argument evaporates.

If it's true, then yours is hard to defend.

Is it faster to develop good software?
Is it considerably more expensive to make it really work?
That's the elephant in every room.


 

On Mon, Apr 22, 2013 at 8:20 PM, Matthew Riley <mat...@matthewriley.name> wrote:

Hello everyone,

My team has been involved in developing an iPhone application using Agile methods with a very high degree of test automation.

We have successfully delivered the project with a minimum of defects and we are proud to have accomplished this.

The business manages a number of other software projects outside of our team, not using Agile methods, have a lot of defects and a lot of manual testing.

With this contrast a perception has formed that we build the Rolls Royce of software which may be overkill for their needs.

What they are really saying is they may not require the level of quality we have built into the software and may be willing to compromise on quality.

Throughout the course of the project, we have been trying to educate the business on the benefits of these approaches, with limited success.

It's obviously very difficult to prove the benefits objectively to non-technical people, and there's absolutely politics at play.

I doubt very much this is a unique situation. Has anyone had any success managing this scenario and how did you go about it?

Thanks, Matt

--
You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.

To unsubscribe from this group and stop receiving emails from it, send an email to software_craftsma...@googlegroups.com.
To post to this group, send email to software_cr...@googlegroups.com.

Visit this group at http://groups.google.com/group/software_craftsmanship?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Tim
----
http://www.industriallogic.com/

[Jeff Miller]

I wonder if Toyota is the better point of comparison for high quality (reliable, holds value, few repairs) in preference to Rolls-Royce.

"Sure, we can quickly slap together a concept application for you, but expect rework.  We'd prefer to continue an ongoing project by adding new functionality in a way that makes it reliable."

-J

[George Dinwiddie]

David,

On 4/25/13 3:12 PM, David Wilde wrote:
> George,
>
> This is what we had all thought on the course as well. The idea that
> chance could cause high availability was the first thought we had all
> had as well. No problems = Good fortune.
>
> However when you start to factor in mean time for failure for
> components, costs of failover systems, expensive zero down time
> maintenance jobs, business continuity and disaster recovery
> requirements, then the probability of achieving a high availability
> system through chance becomes very small indeed.

Yes, I know all that. But there's a difference between doing the work
for 100% availability and not doing that work and having 100%
availability (for some specified period of time).

>
> There's much more information about high availability systems here -
> http://en.wikipedia.org/wiki/High_availability
>
> Try getting some hosting quotes for the difference between a 2 nines
> availability and a 6 or 7 nines availability system and you will soon
> realise that there are massive costs involved. Once you realise, you too
> would start to become concerned if a hosting company massively exceeded
> your SLA. If these aren't passed on to you the customer then your host
> will probably go bust soon! At the very least you would want to have a
> chat with them about how they have achieved this rather than just think
> "Oh I got lucky".
>
> David
>
>
>
> On 25 April 2013 19:14, George Dinwiddie <li...@idiacomputing.com