Re: The design is the code?
From: Doc O'Leary (droleary.usenet_at_2005.subsume.com)
Date: Sun, 13 Mar 2005 16:52:54 -0600
In article <email@example.com>,
"Jason Hawryluk" <firstname.lastname@example.org> wrote:
> My comment was based on your example. Let me rephrase my response.
Let me cut out the lengthy reply and just hit the "failure" points.
> You hand the spec of to the developers. They read it scratch their head
> nodding and walk of to plunk out some code.
If there is no two-way communication, your project has already failed.
As I stated previously on this thread, using a waterfall is naive and
usually dooms the project from the get-go. Being unwilling to push back
doesn't make the code the design.
> Opp's Margaret in finance needs to be able to filter on the Contact's GL
> number. No problem ? HA
> Opp's Shelly in shipping needs to be able to filter on the Contact's
> Account number. No problem ? HA
> Opp's John in marketing needs to be able to filter the list in order to show
> only those contacts that are part of the new widget campaign. No problem ?
You make my point for me. If the code is the design then, no, there is
no problem! Because you see the errors, you should also see that the
design needs to be fixed and then the code needs to be fixed to reflect
that. If you had caught that and addressed it at the "walks off" stage,
you'd be a better developer.
Your secondary mistake is to focus on the problems a missing feature
generates, and not look at the problems an unwanted feature causes.
What of the support costs of Shelly getting confused when your
non-filter gives her results only John wanted? Feel free to work out
*all* the combinations that could result in confusion.
> Project failed.
The project was *designed* to fail, not *coded* to fail.
> You wouldn't have to. The whole freaking department just got fired. Because
> your a hard ass architect and don't listen to the dev's.
No, as a dev you just walked off. That's why I'd have fired you. There
was no "listen" to be found. Understand?
> You give the orders
> and they follow. They are not supposed to use their creative talent that's
> your job. In closing because of your spec, and the idea that it is a bible
> for the dev's and thout shalt not do anything not in the spec commandment.
> The program took longer to create, added code and memory size, is very
> limited, and none of it is reusable.
All quite moot. My position remains that the design is broken, but the
code wasn't. You have done nothing to refute that, and have in fact
done more to support it.
> Who could I talk to that would listen. Someone that has written a line of
> code in 10 years. Someone who is willing to admit his spec was wrong coming
> from a mindless dev???
Take your own baggage elsewhere. If you're not listened to at your
current job, that's your problem. We're talking about an abstract
scenario here which you simply decided to break by setting up a
waterfall development model.
> A programmer is like an artist. If you always tell him what colors to paint
> with, he will stop painting for you. Developers need room to be creative, if
> a spec writer or architect takes that creativity away you will loose
> developers. Most people become developers because it's a passion and they
> enjoy creating and using their imagination. They day someone hands me a spec
> and say's do not sway from this spec I will quite that *job* in a
You're looking for "art" in the wrong parts of the project. Where you
get to be "creative" is not in pushing your view on the user. You
feeling powerless and lashing out has nothing to do with getting the job
done. As the saying goes, don't let the door hit you in the ass on the