Weblogs Forum - Architecture the Accelerator

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
Architecture the Accelerator

59 replies on 4 pages. Most recent reply: Mar 5, 2005 8:49 AM by Isaac Gouy

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 59 replies on 4 pages [ « | 1 2 3 4 | » ]

Levi Cook

Posts: 8
Nickname: levicook
Registered: Feb, 2002

Re: Architecture the Accelerator

Posted: Feb 24, 2005 4:02 PM

Reply

Advertisement

> I agree with you about fitness for purpose, especially
> if you mean business purpose.

Business purpose is exactly what I mean. But even this is a slippery issue. At a minimum, satisfying business purpose means delivering working software in time to capitalize on an immediate opportunity. On the flip side, which calls for a different strategy, you might be trying to capitalize on long term opportunity. There are probably a dozen other dimensions to conisder. My goal isn't to enumerate them, rather I'm trying to highlight the importance of knowing which situation you're in. If you fail to do something appropriate for your context, you've missed the boat on quality entirely.

> The way I map the stairs metaphor to software is via cost.
> ...

I appreciate the story, but I don't follow the relationship to quality you're asserting. It seems that you're simply pointing out the "plush" steps cost more. And that's OK because they're worth more. Maybe I just need to read closer...

<reading...>

I still don't see the relationship to quality. It feels more like an argument to make sound investments. Like financial investments, knowing your goals is half the battle.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Architecture the Accelerator

Posted: Feb 24, 2005 5:40 PM

Reply

But despite all that, quality is ultimately subjective. I may think a particular method name is bad that you think is just fine, and there's no right or wrong answer. But if either of us decided to rename that method to make it still better, it would take time and money.

Although imo we're in broad agreement, I think this is worth discussing further.

1) What does it mean for a method name to be good/bad?

Perhaps it means that the name may be misinterpreted, it doesn't say what it does as well as it could.

Could we measure the descriptiveness of a method name by having 10 peers write down what they though the method did from it's name? (And accept method names which 7 out of 10 developers figured out.)

2) We say that renaming methods costs time/money - and let's so we don't have IDE support for renaming just to bump up the cost.

What might not renaming the methods cost - what value do we give the expected benefits?
Is the method name so bad that other developers are confused about what the method does; is it so bad that they will make mistakes?

It's not just costs versus subjective quality; it's costs versus benefits.

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: Architecture the Accelerator

Posted: Feb 24, 2005 6:12 PM

Reply

> > The way I map the stairs metaphor to software is via
> cost.
> > ...
>
> I appreciate the story, but I don't follow the
> relationship to quality you're asserting. It seems that
> you're simply pointing out the "plush" steps cost more.
> And that's OK because they're worth more. Maybe I just
> need to read closer...
>
Plush steps cost more to build than cement steps, and it is worth spending the extra money up front on the lobby stairs because you judge that extra investment will help you make more money down the road. Well-designed, well-factored, well-tested software is more expensive to build than a quick hack, and it is worth spending that extra money up front only to the extent it will create business value down the road. (The way quality code does that, primarily, is by making that code easier, and therefore faster and cheaper, for programmers to understand and change in the future.)

Similarly, paying someone to vacuum the lobby steps twice a day costs more than paying someone to hose down the emergency steps twice a year, and you pay that extra money if you judge you'll get a good return. Paying developers to spend time refactoring and cleaning up existing code when making an enhancement costs more than paying developers to just hack the enhancement into place, and that is worth the extra cost only to the extent you judge it will give you some payback in the future. (Once again, the payback generally manifests itself by making future changes cheaper and faster.)

> <reading...>
>
> I still don't see the relationship to quality. It feels
> more like an argument to make sound investments. Like
> financial investments, knowing your goals is half the
> battle.

Yes. I'm talking about the programmer as an investor, someone who assesses risk and ponders return on investment when deciding how to approach each programming task. I believe Uncle Bob is talking about the programmer as a craftsperson, a "codesmith" who takes pride in his or her work. These are not at all mutually exclusive views of programming, but it is important that one not dominate the other completely.

Robert C. Martin

Posts: 111
Nickname: unclebob
Registered: Apr, 2003

Re: Architecture the Accelerator

Posted: Feb 24, 2005 6:54 PM

Reply

> I don't know if you've ever ran a business,

I am president and founder of Object Mentor Inc. One of the few consulting companies to survive the .bomb. We've been in business for about 12 years now.

> but that's
> what I do, and I can tell you that it's a dangerous world
> out there. When it rains, you just want an umbrella - if
> you waited for a hut to be build, you'd die of
> hypothermia. So you sometimes do have to reduce quality to
> reach an objective.

No.

Robert C. Martin

Posts: 111
Nickname: unclebob
Registered: Apr, 2003

Re: Architecture the Accelerator

Posted: Feb 24, 2005 6:59 PM

Reply

> These are
> the kind of statements filled with religious fervor that
> give me the impression of XP as cult.

This thread has nothing to do with XP. It is a thread about whether or not you can go faster by creating crap. My argument is simply this. The more crap you create, the slower you go. A little crap means you go a little slower. A lot of crap means you go a lot slower. No crap means going as fast as you can go.

Robert C. Martin

Posts: 111
Nickname: unclebob
Registered: Apr, 2003

Re: Architecture the Accelerator

Posted: Feb 24, 2005 7:04 PM

Reply

> And if
> that sometimes means hacking together a quick demo for
> that person to meet a deadline, even if it is more likely
> to crash, then I do that and I still respect myself in the
> morning.

You'll get done faster if you don't hack it together.

Like I said. I can't justify these beliefs. They are maxmims of professionalism for me. Call them religion, call them dogma, call them anything you like. I don't care. I simply will not accept that time and quality have an inverse relationship.

Robert C. Martin

Posts: 111
Nickname: unclebob
Registered: Apr, 2003

Re: Architecture the Accelerator

Posted: Feb 24, 2005 7:10 PM

Reply

> I also get the feeling Uncle Bob is frustrated that anyone
> would suggest that anything less than the utmost code
> quality is OK. While that is a noble ideal, I find it
> doesn't fit business reality.

I find the exact opposite. The most viable business strategy is a no-excuses attitude striving for zero defects.

Robert C. Martin

Posts: 111
Nickname: unclebob
Registered: Apr, 2003

Re: Architecture the Accelerator

Posted: Feb 24, 2005 7:16 PM

Reply

> My observation is that sometimes business people don't
> appreciate the business value of quality code,

Sane business people simple expect the code to be high quality. Only insane business people ask programmers to ship crap to their customers. Most are out of business. The rest will be eventually.

> I find that sometimes developers don't
> understand the business value of
> meeting deadlines even with a mediocre product.

Developers who think that reducing quality will help them meet deadlines are wrong. The way to meet deadlines is to keep quality high.

Robert C. Martin

Posts: 111
Nickname: unclebob
Registered: Apr, 2003

Re: Architecture the Accelerator

Posted: Feb 24, 2005 7:19 PM

Reply

> Plush steps cost more to build than cement steps.

Cement steps that are square, smooth, and even, are high quality. Cement steps that are angled, rough, and uneven are low quality. The latter cost more in both time and money.

Robert C. Martin

Posts: 111
Nickname: unclebob
Registered: Apr, 2003

Re: Architecture the Accelerator

Posted: Feb 24, 2005 7:26 PM

Reply

> After a point the Canoo test scripts
> become really unweildy because we had to test every
> element in the resultant JSP page with xpaths. Even a
> small UI modification like adding a row or changing the
> table layout meant struggling with Canoo for a couple of
> hours.

It may be that had you separated the UI from the business rules, and tested the business rules without the UI, then changes to the UI would not have broken so many tests.

It has long been known that separating the UI from the business rules is a good thing to do -- especially in a heavily tested environment. However many folks feel that they don't have time to do that separation.

Robert C. Martin

Posts: 111
Nickname: unclebob
Registered: Apr, 2003

Re: Architecture the Accelerator

Posted: Feb 24, 2005 7:32 PM

Reply

> But quality takes time and putting more quality into a
> a product can cause missing deadlines.

No. Compromising quality causes missed deadlines. Maintaining quality cannot guarantee that deadlines will be met; but fewer will be missed.

> The question is,
> how much time do you spend to improve quality when a
> deadline approaches rapidly?

None. You keep the quality high all the time.

> So you do not reduce quality but you
> compromise quality in order to just quickly make
> the product work. Isn't that even a principle of TDD?
> What else is faking some functionality just to get a
> a green bar?

It is a way of testing the test. It is a discipline in pursuit of quality.

> Maybe we can agree eventually on delivering quality
> incrementally.

We can.

> But that implies that quality is lower
> in the beginning.

Yes.

> and if you deliver periodically then you
> deliver with lower quality in the beginning.

Yes. But you do not intentionally reduce or compromise quality because you think it's a way to get done faster. It is not.

Dan Perl

Posts: 28
Nickname: nanov
Registered: Sep, 2004

Re: Architecture the Accelerator

Posted: Feb 24, 2005 8:27 PM

Reply

> > These are
> > the kind of statements filled with religious fervor
> that
> > give me the impression of XP as cult.
>
> This thread has nothing to do with XP.

Agreed. However, I would personally like to see a discussion on how some technologies and some methodologies are drawing a "cult-ure" of fanatics. I have seen that not only in the case of XP, but also in the case of python. It may seem odd (it seemed odd to me!), but I recently even saw it in at least one die-hard C programmer.

Perhaps another blogger will start such a thread? Something about new technologies and methodologies as cults and the effect on the community at large? Just a suggestion.

Dan Perl

Posts: 28
Nickname: nanov
Registered: Sep, 2004

Re: Architecture the Accelerator

Posted: Feb 24, 2005 8:48 PM

Reply

> ... you do not intentionally reduce or compromise
> quality because you think it's a way to get done faster.
> It is not.

I want to set things straight. Nobody intentionally develops low quality code or achitectures. It just happens. But quality involves improving code or architectures that initially came out bad or that became bad over time (e.g., code duplication). The improvements take time. And with limited time it may be a better choice to add functionality that is urgently required than to add these improvements.

Of course, such a compromise (like in the case of code duplication) incurs a high cost at a later time. But in the short term, improving quality is a cost in itself and that cost may not be affordable.

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: Architecture the Accelerator

Posted: Feb 24, 2005 9:51 PM

Reply

> > But quality takes time and putting more quality into a
> > a product can cause missing deadlines.
>
> No. Compromising quality causes missed deadlines.
> Maintaining quality cannot guarantee that deadlines will
> l be met; but fewer will be missed.
>
Thanks, Bob, for making this series of micro-posts. I think I understand better where you're coming from now. I think we agree in the long term, but not in the short. My experience has also been that "compromising quality causes missed deadlines" long term. What I don't yet understand is why (or if) you think compromising quality slows you down in the short term. Could you elaborate on how insisting on quality speeds you up in the short term?

Levi Cook

Posts: 8
Nickname: levicook
Registered: Feb, 2002

Re: Architecture the Accelerator

Posted: Feb 25, 2005 5:07 AM

Reply

BV> I think we agree in the long term, but not in the short.

Based on the following three points, I wonder if Uncle Bob would say there's no such thing as the short term.

RM> Too many quick hacks became long disasters.
RM> Too many trade-show demos crashed.
RM> Too many prototypes were shipped and maintained for years.

I can't know his thoughts, but my own experiences lead me to believe it's true. Then again, I keep telling myself that things like J2EE are a short term wart..but it keeps hanging around :)

Of course, the life cycle of business and the life cycle of technology are two different things.

Flat View: This topic has 59 replies on 4 pages [ « | 1 2 3 4 | » ]

Previous Topic

Next Topic

Sponsored Links

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use