software requirements again, retrospective

[ccc31807]

This isn't a complaint, gripe, or an appeal to sympathy. It's simply a
report on a conversation I had yesterday. You can draw your own
conclusions.

In case you missed the first installment, I vented on c.l.p.m. because
of a series of 'unknown' requirements that I had to implement after
the fact. The project was preparing a series of task documents
detailing specific tasks for several hundred people. The software was
already a week late when I discovered a major requirement that no one
had previously specified.

The project wasn't owned by IT, but by the business side with the
parameters and template dictated by HR. My role was to do what I was
told to do. I had no input into the requirements, design, or work
schedule.

Anyway, the conversation I had yesterday was with a friend of mine,
one of my upstream contacts, with a long time business background who
had been an IT manager for about three years. What he said was this:
"When you find out about a project, you start immediately. Don't wait
for people to tell you what to do, you start writing the code at once.
When you get the details, you can change what you have written."

The purpose of this conversation was to discuss a to-do list of about
six items that we know have to change, and a promise of a number of
other changes that we will get in several weeks. I said that I would
wait until I saw all the changes before I started on the updated
version. My friend said: "No, start making the changes now, and you
will be that far ahead."

Here's the point -- The business managers have a mind set that you can
get a head start on a project by building it before you know what it
is. Once you get word of it, you start on it. That way, when the boss
mentions it, you can say, "We've already started and it's underway."
That's what happened to me, with no knowledge that I was being fed
requirements piecemeal, with no thought as to how the tasks would be
specified. (Yes, I was stupid.)

I don't know what the lesson of this is, except that you do your job,
if you're lucky enough to have one, and do the best you can with what
you have, not expecting to change the culture of the business side.

Thanks, CC.

 

[Brad Baxter]

Here's the point -- The business managers have a mind set that you can
get a head start on a project by building it before you know what it
is. Once you get word of it, you start on it. That way, when the boss
mentions it, you can say, "We've already started and it's underway."
That's what happened to me, with no knowledge that I was being fed
requirements piecemeal, with no thought as to how the tasks would be
specified. (Yes, I was stupid.)

Makes me think of
http://en.wikipedia.org/wiki/Agile_software_development#Principles

My experience is that your experience will likely be all over the map.



My philosophy: You can't steer a canoe that isn't moving. But I
also have no illusions that I'm particularly competent at project
management. I'm okay with that.

 

[ccc31807]

WTF does any of this have to do with Perl?

Has the same relevance to Perl as analysis and design has to
implementation. Why is as much a part of the discussion as What.

clpmisc is not the place for these rants. LiveJournal is -->thataway.

Unfortunately, we write in the real world, interacting with real users
with real needs, dealing with real problems. Reality is often messy.
I'm sorry if it offends you, but you always have the option of not
reading these kinds of threads -- and it's not as if I snookered you
into reading it by false pretenses, I clearly titled the thread in
such a way that you would know the subject.

Kinda reminds me of the tom peeper who blamed his activities on the
women undressing in their bedrooms. ;-)

CC.