From: Dr.Ruud on
Shmuel (Seymour J.) Metz wrote:

> IMHO, if the business process owner signs off on the specifications then
> it's his responsibility if they're wrong.

Do they really still exist, these environments where they write up
specifications and sign them off and such? What a waste!

Go and work in a communicative environment, where the "business" and the
"developers" continuously share and improve the business knowledge, and
help each other to get results, with noticeable improvements every day.

Most goals should never be defined, they should just remain a general
idea to works towards to. *Why try to fork reality?* Adapt to it, and
reality will work for you.

-- -- --

When I look back on successful changes of a larger scale, there was
often an Idea-A, -B and -C. The Idea-C approach was worked on in the
early stages, gets labeled as "research", and remains available as both
a reference and still an alternative.

Idea-B is there for if Idea-A is achieved much quicker than anticipated.
The Idea-A is about 60% of Idea-B (or even less).

The funny thing is that when work on Idea-A is started, there is also
work started on parts of Idea-B that are not in Idea-A. That superfluous
part of the work has its role, but gets postponed with the first signs
of trouble.

Then it is firmly decided to get Idea-A done first. But of course, the
"Idea-A" at that moment is different from the "Idea-A" at the start. It
has evolved and matured. That it still gets called by the same name, is
important too.

--
Ruud
From: ccc31807 on
On Apr 5, 6:30 am, "Dr.Ruud" <rvtol+use...(a)xs4all.nl> wrote:
> Do they really still exist, these environments where they write up
> specifications and sign them off and such? What a waste!

I work with many clients to whom ordering a script or a report is like
ordering a desk or a chair. You submit a purchase order, and the item
when delivered does what it should. I often get requests for reports
asking for "all" of something, for example, "all" people matching a
specific criteria. The client, who expects a list of several dozen at
most, screams and hollers when I deliver a list of 350,000 plus. The
client's problem is that he hasn't fully specified all relevant
criteria. My problem is that I don't know his relevant criteria -- he
might very well want "all" of something.

I think of this as the "don't touch a hot stove" lesson. You can tell
a child many, many times that, if he touches a hot stove, he will get
burned, and it doesn't do any good. However, let him touch a hot stove
once, and the lesson is learned forever.

(I used to call this the "don't play in the street" lesson until my
wife told me that wasn't humorous at all.)

> Go and work in a communicative environment, where the "business" and the
> "developers" continuously share and improve the business knowledge, and
> help each other to get results, with noticeable improvements every day.

In this day, having a job can be a lot more important that the
communicativeness of the environment.

> Most goals should never be defined, they should just remain a general
> idea to works towards to. *Why try to fork reality?* Adapt to it, and
> reality will work for you.

I agree with this totally. I think that the requirements should be
defined precisely ('total' equals the product of 'quantity' of each
line item and 'cost' of each line item for all line items). Software
is infinitely malleable, unlike a physical item, and I totally agree
that recognition and acceptance of this malleability is essential to
writing good software.

CC
From: J�rgen Exner on
"Dr.Ruud" <rvtol+usenet(a)xs4all.nl> wrote:
>Shmuel (Seymour J.) Metz wrote:
>
>> IMHO, if the business process owner signs off on the specifications then
>> it's his responsibility if they're wrong.
>
>Do they really still exist, these environments where they write up
>specifications and sign them off and such? What a waste!

I most definitely want something in writing, even if it is for my own
purposes only. Maybe you have a memory like an elephant but I can't
remember what was discussed or agreed upon or even what I was thinking
at the time when a month later that part of the project is due for
implementation.
And I cannot imagine how email or the Internet or Usenet would work
without any written specs and protocols.

jue
From: Dr.Ruud on
J�rgen Exner wrote:

> And I cannot imagine how email or the Internet or Usenet would work
> without any written specs and protocols.

Most of them document long standing practice.

--
Ruud
From: Charlton Wilbur on
>>>>> "cc" == ccc31807 <cartercc(a)gmail.com> writes:

cc> We'll get this sorted out on Monday so I'm not worried about
cc> it. The point is that the technical person can't work without
cc> knowing what the requirements are, and at least in my situation,
cc> I am often assigned work with unclear, ambiguous, or absent
cc> requirements.

Yes, and when a professional software engineer is handed unclear,
ambiguous, or absent requirements, it is one of his responsibilities to
see that they are clarified, disambiguated, or written at all.

That is the point that you do not seem to wish to understand.

Charlton


--
Charlton Wilbur
cwilbur(a)chromatico.net
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9
Prev: perl.libwww?
Next: How to convert "=?ISO-8895-1?Q?..." stuff?