software requirements again, take 483

[Charlton Wilbur]

cc> The business guy was out of the office at a conference. All I
cc> had was the log file and that he wanted it by Monday. Initially,
cc> I didn't even know what it was that he wanted, but it wasn't
cc> difficult to guess. I didn't want to wait until I knew the
cc> requirements in toto when I knew I could do 90% with the
cc> information I had.

You *guessed* the requirements? You dove in without being sure that is
what he wanted?

This is the core of your problem. Not only is the development process
at your workplace completely ass-backwards, you are *participating in*
and *reinforcing* its ass-backwardsness.

Until that changes, the only reasonable response to your complaints
about your workplace is really, "stfu, it's your own damn fault."

Charlton

 

[Dr.Ruud]

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.

 

[ccc31807]

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

 

[Jim Gibson]

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.

This has traditionally been known as the "Bring me a rock" method of
project management. Your boss tells you "bring me a rock". So you bring
him one. It is not the rock he wants. He says "no, bring me a different
rock". Repeat.

Google for it:

<http://bringmearock.blogspot.com/>

<http://workingsmarter.typepad.com/my_weblog/2008/12/bring-me-a-differen
t-rock.html>

 

[Jürgen Exner]

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

 

[Dr.Ruud]

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.

 

[ccc31807]

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.

It's not that I don't wish to understand the point. In some cases, the
end user doesn't know the requirements until he has a handle on the
data. An end user that doesn't understand the problem can't specify
clear and precise requirements.

In order to follow your advice to clarify, disambiguate, or reduce to
writing the requirements, it's sometimes necessary to write code that
does something. We don't always have the luxury of having a complete
and precise specification before writing the first line of code. This
is one of the challenges that the spiral development cycle was
designed for.

CC.

 

[Charlton Wilbur]

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

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

....and what you're doing is just writing the specifications iteratively
and interactively. If you don't know what your goals are, you have no
idea if you're making any progress towards them.

Charlton

 

[ccc31807]

...and what you're doing is just writing the specifications iteratively
and interactively.  

What's wrong with that? Seems to be that the basis of 'requirements
engineering' is that requirements are developed in an empirical,
deductive manner, rather than a top down all-or-nothing manner.

If you don't know what your goals are, you have no
idea if you're making any progress towards them.

This is a truism, and like all other truisms has limited application.
The 'goal' might be to grow the business, but the devil is in the
details. I did a project recently analyzing call center data,
developing scripts showing when, where, and why the users called. Some
areas had a lot more calls than others, and I recall a heated
discussion as to whether it was because these units were doing a
better job than the others, or a worse job than the others.

The 'goal' was to service the users. Does a high call volume mean that
you are doing a better job? or a worse job? Do you want to increase
the help calls, which might indicate that people were using the
product? Or do you want to decrease the help calls, which might
indicate that people were actually using the product rather than
having problems with it?

CC.

 

[Charlton Wilbur]

cc> This is a truism, and like all other truisms has limited
cc> application. The 'goal' might be to grow the business, but the
cc> devil is in the details.

"Make the business grow" is a strategic goal. Someone who knows the
business needs to derive some tactical goals from that -- things that,
if the workers should accomplish them, should result in the business
growing. But "make the business grow" is a completely useless goal to
give to a programmer.

More to the point, you cannot invalidate the usefulness of goals in
software development by pointing out the difficulty of working towards a
vague strategic goal. Yes, that's a goal. No, it's not a useful goal
for a programmer to work towards without an intermediate goal.

Time and time again you're given a vague specification or no
specification at all, you dive in headfirst, it turns out to be not what
the person actually wanted, you take all the blame, and then you vent
here. You are contributing to and enhancing the problem that you're
complaining about, and you're too stubborn or stupid to see it. You are
building the hell you're in, and when other people point out that you
are doing so, you come up with a paragraph of quasi-management speak to
justify why you should keep on building your own hell.

If you want help, you've come to the right place. If you want to vent
about how miserable your life is and how nobody understands you,
livejournal is that way.

Charlton

 

[ccc31807]

If you want help, you've come to the right place.  If you want to vent
about how miserable your life is and how nobody understands you,
livejournal is that way.

I think you might have misinterpreted the thrust of the conversation.
My intention was to provoke a discussion about the process of
developing applications, which in mu case means little scripts that
import data and export information.

I don't want or need 'help' in dealing with my personal employment
situation. I don't want or need to 'vent' in the sense garnering
sympathy. I certainly don't want to give the impression that my life
is miserable, because it's not.

These kinds of discussions have value (IMO) because they allow us to
share experiences and ideas, which help in the day to day practice of
our profession. My clients aren't stupid, ignorant fools who exist
merely to make my life hell, but smart, knowledgeable professionals
who want to grow the enterprise. It's my job to help them by giving
them the information they need.

The fact that they might lack the skills to do this, and the
vocabulary to talk about the process, just makes the job more
challenging, and my own role more important.

CC.

 

[Uno]

No, it hadn't and no you weren't. The software behaved according to the
spec, so there was no bug in the software.


By making sure that everyone who has a stake in the software attends the
spec review and signs off on the spec. If he doesn't speak up then a
flaw in the spec becomes _HIS_ problem, not yours.

I've heard that "the problem" that is forcing toyota's recall is a
software one. It sounds like "the problem" is going to be several
defects in combination. They haven't come clean yet, so this is
speculation.

If there is one, I'll be interested to see the source for the software
defect.

 

[Jürgen Exner]

I've heard that "the problem" that is forcing toyota's recall is a
software one. It sounds like "the problem" is going to be several
defects in combination. They haven't come clean yet, so this is
speculation.

If there is one, I'll be interested to see the source for the software
defect.

Well, if this is true and if history is any guide, then it is either a
decimal comma versus decimal point problem or a psi versus hPa
problem.

jue

 

[Eric Pozharski]

If you want help, you've come to the right place. If you want to vent
about how miserable your life is and how nobody understands you,
livejournal is that way.

That's not the first time you're producing sigs. Quite a habit.

 

[Charlton Wilbur]

EP> That's not the first time you're producing sigs. Quite a habit.

It has become apparent that coming up with terse bits of wisdom that fit
comfortably within four lines may be my only real shot at immortality.

Charlton

 

[Ted Zlatanov]

CW> It has become apparent that coming up with terse bits of wisdom that fit
CW> comfortably within four lines may be my only real shot at immortality.

Hey, it worked for Martial (http://en.wikipedia.org/wiki/Martial)

Ted

 

[Charlton Wilbur]

DF> On Thu, 01 Apr 2010 20:25:52 -0400, Charlton Wilbur

DF> In most orginisations that will never ever happen.

I refuse to believe that my organization is that unusual. Admittedly,
the statements tend to start out at a high-level, but the high-level
requirements and most of the medium-level requirements are in place
before any coding starts. A lot of the low-level requirements are
hashed out between developers and business owners when the need for them
becomes apparent.

Do people in "most organizations" *really* start coding madly before
anyone has a clear idea of what the problem to be solved is?

Charlton

 

[Jürgen Exner]

Usenet and email both where cases where existing protocols where
documented after they where implimented rather then the other way
around.

If today you were given the task of implementing a new email server from
scratch, would you rather reverse engineer the protocols by observing
the data flow in an existing system or would you consult the written
RFCs?

jue