The Artima Developer Community
Sponsored Link

Weblogs Forum
The Tortoise and the Hare

30 replies on 3 pages. Most recent reply: Aug 8, 2005 3:22 PM by Larry Gadallah

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 30 replies on 3 pages [ « | 1 2 3 | » ]
Maurizio Turatti

Posts: 12
Nickname: mkj6
Registered: Jun, 2003

Re: The Tortoise and the Hare Posted: Jun 1, 2004 5:32 PM
Reply to this message Reply
Advertisement
I agree with Lisa: if you don't use good practices don't blame managers, blame yourself. Quality will slow you down a little the first week or two, but then you'll go faster. And you won't spend 75% of your time fixing bugs. Even the dullest manager will notice the difference (...or not?).

Marco Dorantes

Posts: 11
Nickname: marcodoran
Registered: Feb, 2003

Re: The Tortoise and the Hare Posted: Jun 2, 2004 9:52 AM
Reply to this message Reply
Mike Spille,
What maybe you don’t realize is that your argument sounds like the mafia: “we come to kill you, but don’t take it personal, it is just business”. Then, all kind of atrocities can be done for the sake of business wealth.

I understand that we as industry are just too young, many software developers do not realize just how little they know about software development; and as with kids: are you ashamed of the wrongdoing of the past (e.g. dot-com era)?...wait to see the evildoing of the future.

Sign of maturity is the ability to face wicked things of the ‘real world’ we have created, the immediate step always is about changing you first and learning from the past. So, business people must know about their business and their priorities, software people must know about software and how to provide the best possible service level to our clients. Just do not mix responsibilities.

Keith Ray

Posts: 658
Nickname: keithray
Registered: May, 2003

Re: The Tortoise and the Hare Posted: Jun 2, 2004 10:34 AM
Reply to this message Reply
Why do some managers managers value speed over quality? I can think of two reasons: they believe the buggy software is normal, or they get rewarded for delivering buggy software early.

The two ideas are often combined. If buggy software is normal, let's set an "aggressive" date for it to be "finished" (we're rewarded for meeting that date, even though nothing is really working well), and then spend twice that amount of time removing the bugs that were put in (and blame those programmers or those testers for any delays).

How did the idea of buggy software come to be "normal"? Because so few programmers are taught bug-reduction techniques like code reviewing, pair-programming, unit testing or test-driven-development in college, and relatively many programmers [none of whom read blogs like this or even books on these subjects] learn these techniques after college. And managers (with MBAs or otherwise), haven't gotten training on the value of these practices either.

[and check out these books - they're very timeless and enlightening: http://www.geraldmweinberg.com/books.html ]

Mike Spille

Posts: 25
Nickname: mspille
Registered: Nov, 2002

Re: The Tortoise and the Hare Posted: Jun 2, 2004 11:39 AM
Reply to this message Reply
Marco - atrocities, ashamed, wrongdoing, evildoing, wicked things?

For most people software development is a _job_. I personally try to deliver the best code I can, and feel free to interact with managers and business people if I think something is being done in the wrong m anner - but it's still a _job_.

Dale Emery

Posts: 4
Nickname: dhemery
Registered: Feb, 2004

Re: The Tortoise and the Hare Posted: Jun 2, 2004 5:01 PM
Reply to this message Reply
Keith said:
> Why do some managers managers value speed over quality? I
> can think of two reasons: they believe the buggy software
> is normal, or they get rewarded for delivering buggy
> software early.

I can think of an additional factor: functions are somewhat more visible than quality. Functions are especially more visible than internal quality.

A few other factors: The benefit of functions is here and now. The cost of poor quality is later (though not always as later as you think) and somewhere else (though the consequences always find there way back here). And the causal connection between functions and profits seems easier to see than the connection between quality and costs.

Whether they're making decisions about software development or anything else, people will tend to favor the options whose consequences are are more visible, more immediate, more personal, and more easily attributable to the decision.

If we want managers (and other humans) to choose different options, we're probably going to have to do something about those factors.

Dale

Marco Dorantes

Posts: 11
Nickname: marcodoran
Registered: Feb, 2003

Re: The Tortoise and the Hare Posted: Jun 2, 2004 6:25 PM
Reply to this message Reply
There is very good discussion about how external quality factors are based on internal quality factors in a chapter of "object-oriented software construction" by Bertrand Meyer

Johannes Brodwall

Posts: 19
Nickname: jhannes
Registered: Jun, 2003

Re: The Tortoise and the Hare Posted: Jun 3, 2004 1:02 AM
Reply to this message Reply
I often feel that developers see the "go well, not fast" as an argument to do a lot of up-front design and speculative "infrastructure frameworks".

The tricky balance is to advocate quality work without having people confuse it with an excuse to violate YAGNI.


~Johannes

Jeroen Wenting

Posts: 88
Nickname: jwenting
Registered: Mar, 2004

Re: The Tortoise and the Hare Posted: Jun 4, 2004 9:22 AM
Reply to this message Reply
> Keith said:
> > Why do some managers managers value speed over quality?
> I
> > can think of two reasons: they believe the buggy
> software
> > is normal, or they get rewarded for delivering buggy
> > software early.

They get rewarded for shipping on schedule or better yet, ahead of schedule.
THEY get the blame if the schedule isn't met, because they should have more vigorously persued meeting it.
When they deliver on schedule but the product is poor they'll just blame it on the people that made that product, after all as a manager they're not responsible for doublechecking the quality of the product (that's what QA is for who get told that they have 10 minutes to sign off on the product instead of the 2 months they'd need for a really thorough shakedown if they even exist).

Burek i Jogurt

Posts: 1
Nickname: burek
Registered: Jun, 2004

Re: The Tortoise and the Hare Posted: Jun 9, 2004 12:17 PM
Reply to this message Reply
Mike,

There is a difference between disregarding the deadlines and bussines goals to attain some (to these ends) usless code perfection, and controling the impulse to bang out code in order to actually meet those deadlines and goals. A developer is a part of the whole. The whole is the business with certain goals. In order to meet those goals, the developer's job sometimes is to complete something "as fast as possible" producing "good enough code". The best way to do this might be by going slow :).

Jack Ashburn

Posts: 1
Nickname: jashburn
Registered: Jun, 2004

Re: The Tortoise and the Hare Posted: Jun 9, 2004 2:23 PM
Reply to this message Reply
Most of the posts here focus on the programmer/developer and manager/company elements. I'd like to bring in the customer element as well.

How often have we heard customers screaming asking for a bug fix or implementation of an enhancement, and they want it yesterday? How often do you get customers asking for features that'll do everything under the sun, but are unwilling to pay for what it's worth?

To me, it looks like the perception is software is cheap and easy to produce, and it should be able to do everything. Take the counter-example of an airplane. It's expensive, it's difficult to produce, and it does only one thing - fly. Customers are willing to pay the price of an airplane, but are unwilling to pay for software. Am I missing something here?

True enough, airplanes are safety-critical, but if software is mission-critical enough for a business, why do customers often go for a vendor who offers a similar product at a lower price?

In my opinion, all parties (developers, employers, customers) in this industry need to attain a further level of maturity. I personally have seen customers who "get it", and opt for quality over price. But they are the minority. I'm afraid the majority are "spoilt" by vendors producing software too quickly and cheaply, favouring speed over quality, that we are forever stuck to the produce-crappy-code, maintain-crappy-code cycle...

Jeroen Wenting

Posts: 88
Nickname: jwenting
Registered: Mar, 2004

Re: The Tortoise and the Hare Posted: Jun 10, 2004 2:28 AM
Reply to this message Reply
> To me, it looks like the perception is software is cheap
> and easy to produce, and it should be able to do
> everything. Take the counter-example of an airplane. It's
> expensive, it's difficult to produce, and it does only one
> thing - fly. Customers are willing to pay the price of an
> airplane, but are unwilling to pay for software. Am I
> missing something here?
>
That's not in the least to blame on the open source crowd and their insistence that software should be free.
People outside the software industry because of that (if even the people that make it say it should be free why should I pay for it?) think that software doesn't cost anything to create.
Also, customers get shipped a CD with the product at best, ever more only get a URL where they can download it.
Therefore the only physical product they get is a piece of plastic which they know the price of (after all, the CDRs at the local supermarket sell for under a Euro each).
The aircraft is a large physical object, they get factory tours in Toulouse or Seattle where they see thousands of people working in huge buildings creating those aircraft.
A software shop is just an office where young people (therefore cheap people) punch away at keyboards much like their secretaries (and those are cheap too).
All these kids do is type away at computers, that's not something that should get paid a lot...
And that's if they get the factory tour at all in the software shop, which purchasers of shrinkwrapped software rarely do.

> True enough, airplanes are safety-critical, but if
> software is mission-critical enough for a business, why do
> customers often go for a vendor who offers a similar
> product at a lower price?
>
Because people are cheap... With the aircraft they can project the running and maintenance cost well into the future.
Gas use is well published and so are the costs of regular maintenance. Figure in inflation and you can compare what buying type A will cost you as compared to competing type B.
With software that cost is largely hidden at initial purchase (unless you contract a longterm maintenance contract), so all the customer has to go on is a product demonstration (of course carefully tailored to show only the best parts of the product) and the initial purchase price.

Given the percentage of pirated software (so no support, no maintenance, no nothing) in use with companies around the world, so essentially software with a zero initial price but extreme potential maintenance cost, you should not be surprised about the trend to get the cheapest option without looking further than the pricetag.

tim norton

Posts: 1
Nickname: free2form
Registered: Jun, 2004

Re: The Tortoise and the Hare Posted: Jun 10, 2004 11:40 PM
Reply to this message Reply
I have hope for all the cause that we are all aiming @, a day when business and all its functional constituents engineer a position where it delivers high quality software which meet time to market & business continuity requirements.

In the comments, noting Mike Spille i see signs of a critial bridging role which will continue to further aid how we as people collectively work together to create better software and business applications; someone technical with a fuller appreciation for the realities of business and the difficulties of managing 'overall business success' in light of the product being software.

As someone who has to for reasons of maintaining 'business balance' kept a deliverable/product focus while always striving to increase quality and longevity of software outputs, i have a different yet complimentary view from the core article body presented here. Although i may not be able to do the actual yards required, as a technology business person endevour to create the organisational and business environment that enables this; such as getting the capital to employ those who can directly increase quality, secure initial customers and deadlines which will give the product momentum and exposure so that there will be time for additional review and focus on process. From here their can be a future with more empathetic customers who will be more understanding of the quality issues we face as software development companies trying to meet their often tight deadlines. I have come to learn that customers can grow to understand to appreciate the value of quaity in the underlying application they are buying into, but to get them there a relationship of customer fcused deliverables has to first be built. Something often only seen on the front line with the customer.

I often find myself a little isolated with teams of highly technical people who for valid reasons of facing the hugely complex task of deisigning and building the software that delivers the marketable application, find it at times difficult to empathise with what are in the current world framework, relatively fixed business requirements.

The negotiation which goes on with clients is not always ignorant, the discussions of mgmt not always naive to the the downfalls of doing things fast, but when considering things strategically, and ensuring the business is a going concern with acceptance from customers and shareholders, quality of the software which is no doubt a huge part of the businesses asset, still in the end has to remain just that, a part! In the end the right customer relationships are also as huge an asset, and securing these desired relationships almost always comes with short term demands and time to market soon becomes the 'current top priority'. Flexing your powers of persuasion and asking customers to understand your position as a vendor 'and' the reqests of your developers, often has to come in the second round , as customers unfortunately firstly expect you to open your ears and not your mouth ; )

Although often spoken ignorantly, these are not just words for ignorant marketing & sales exec's, these are realities of the business world, not to say they need drive everthing, else we would just create rubbish software delivered on time, but they play more of a factor than is often understood by software developers when a software development business makes decisions.

My experience suggests this gap in understanding, which i am only suggesting is a two way street, not the one way suggested in the guts of this article, is exactly the issue that creates the conflict and unhappiness i can hear through this article, and experience with developers.

Business people need education to appreciate the realities of software development and its absolute cornerstone/primary value in building a sutsainable business, and the fact it is no simple thing. While this is true we need to acknowledge that take-up is limited and need to focus on the issues preventing take-up. Maybe as the leaders of this change developers might start to consider the importance of themselves understanding the fuller business environment, and the factors that influence the decisions that come to burden them so much; such as 'unrealistic deadlines'

Maybe the business was faced with the challenge of :

'its unrealistic to deliver this application in the extended/desired time frame of the developers and still keep our customer/revenue, therefore it is unrealistic that we shall continue as a going concern' the outcome of this i am sure is clear, there is no business and no continued development.

I speak of this from nothing short of real experience, where this extremely difficult challenge is what management was/is faced with.

Perhaps it really hurts certain technically oriented business people to see a piece of software hacked together, perhaps they can see how it comprimises there business & product strategy, but perhaps they also have little choice, as faced with making adecision they are left in isolation to make the best one for the business as developers remain only concerned with quality and longevity of the software, not longevity of the business.

John

Posts: 4
Nickname: firefalcon
Registered: Apr, 2004

Re: The Tortoise and the Hare Posted: Jun 11, 2004 4:47 AM
Reply to this message Reply
> Quality will slow you down
> a little the first week or two, but then you'll go faster.
> And you won't spend 75% of your time fixing bugs. Even the
> dullest manager will notice the difference (...or not?).

Maurizio exactly right. With usual development practices developers spend about 80% fixing bugs, digging into code and trying to understand how the code works and what's going on (Wow, I pushed the button and OS crashed!..) So only 20% spends on new functionality implementation.

Using TDD, for example, one can reduce 80% to 60% or even 50%. That's great.

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: The Tortoise and the Hare Posted: Jun 14, 2004 11:03 AM
Reply to this message Reply
> Mike Spille,
> What maybe you don’t realize is that your argument sounds
> like the mafia...

Strange. To me it looks like one of the few sensible and considered entries in this thread.

Vince.

Robert C. Martin

Posts: 111
Nickname: unclebob
Registered: Apr, 2003

Re: The Tortoise and the Hare Posted: Jun 20, 2004 12:30 AM
Reply to this message Reply
> Martin here is ASSuming that software developers know
> better than their managers and the business people what is
> needed, what the schedule should be, and what the
> priorities are.

No, I am assuming that software developers have the right to not make the messes that would slow them down. They have the right to say "no" to managers and customers who presume to tell them how to do their jobs.

I am quite willing to let the business folks set the priorities and schedule. I, on the other hand, reserve the right to determine whether or not those goals are achievable, and the best way to achieve them.

A managers who tells me: "Your unit tests are slowing you down, stop writing them." will recieve a flat rejection from me. I know they are not slowing me down, and I will not let the manager force me to compromise my professional judgement.

Flat View: This topic has 30 replies on 3 pages [ « | 1  2  3 | » ]
Topic: Designing the Heron Standard Library Previous Topic   Next Topic Topic: x = f();


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us