Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

Software specifications: Theory and Practice

By ucblockhead in Technology
Sun Jan 06, 2002 at 09:07:49 PM EST
Tags: Humour (all tags)

The truth about how software specification works. Two case studies.

How they say it will be

You get out of college eagerly awaiting your first project. You are pretty sure you know how it will go. According to all the software engineering books, it goes something like this:

Client: We need a widget analyzer. Here's a specification. Please let us know how long it will take. [thud]

The client drops a five hundred page document on your desk.

Client: Please take special note of Appendix A, which contains mock-up screen shots and Appendix B which lists potential extensions for version two.

You: Thanks, I'll get you an estimate in a week.
Client: Ok.

A week passes as you and your team feverishly analyze the specification.

You: Hi! Here's our detailed analysis. We believe it will take 857 man-hours to write, test and debug to this specification. Since we have four people available, it should be complete in six weeks.
Client: Well, we need it in five. I see from your estimate that the widget color specification screen will require four man-weeks to complete. This is not that important to us, so let's move that to version two.
You: Ok.

Five weeks pass. There is much coding, testing and debugging. You deliver the software.

Client: Wow, this is exactly what we want! You guys rule!

In your dreams....

How it will actually happen

Instead, your first project (indeed, most of your projects) will go something like this:

Client: We'd like a widget analyzer on April fifteenth.
You: Uh, ok, do you have a specification?
Client: What?
You: You know, a document that specifies the software?
Client: It should analyse widgets.
You: I need a detailed description so I know how long it will take.
Client: April fifteenth. It should take until April fifteenth.
You: But I need a specification in order to determine if we can meet that date.
Client: Oh! That makes sense. I'll get right on it. I'll have one next week.

A week passes.

You: You were going to give me a specification today.
Client: What? Oh yeah, I will, by the end of the day.

Three days pass.

You: I'm still waiting for the specification. I can't start until I get one.
Client: What!!! You haven't started!?!?
You: No, I need the specification first.
Client: Oh! I didn't realize it was that important! I'll have on in an

Three hours later, an email arrives:

To: You
From: Client
Subject: Specification


A widget analyser allows a usr to imput the number of widgets, there type, color and then determins the box that will appropriately except all of the widgets.

Let me know if you have any questions!


You: I still need that specification.
Client: Didn't you get my email!?
You: I need a lot more detail than that, you know, a list of all the inputs, screenshots, expected results, error messages, that kind of thing.
Client: Oh! Screenshots! I can do that!

A month passes. At the end of it, you receive a powerpoint presentation containing a bunch of screens that look vaguely like they might be implementable in Windows.

You: Well, thanks, though we still could use detail on the inputs, how the data flows through the system...
Client: [interrupts] Jeez! You want us to do all the work!!! What the hell did we hire you for!?
You: Sigh, ok, we'll estimate it for you.

You spend a week making an estimate. Most of it is going to be wildly inaccurate, and it is based on wild assumptions, but you've been worn down, and you need to get the project done.

You: It will take around 1000 man-hours. We have four people, so it will take six and a half weeks.
Client: Ok, so you've got about a week left. Cool! That means you'll be two weeks early!
You: No, six weeks from now.
Client: What!!! But we'll miss the deadline!!!
You: Well, you could cut out some features.
Client: No! We can't do that! I'll talk to my boss. In the meantine, start work.

You start work. You code for four miserable eighty hour weeks trying to get everything done as soon as possible. You deliver on April 22nd.

You: Here you go!
Client: Late...that's ok though, it isn't too late. We'll give it a look and let you know.

A month passes.

You: Does the software meet your needs?
Client: Hey, I'm on the other line, I'll call you back.

A week passes.

You: Did you look at the software?
Client: Oh, hey, good to hear from you! We'll look at it this week.

Three weeks pass.

Client: Hey, you know, the thing with this software is that it doesn't do gizmos.
You: Gizmos?
Client: Yeah, gizmos, it should analyse gizmos too.
You: But you didn't say anything about gizmos.
Client: I know, but I was talking to a guy in accounting, and he suggested it, and since gizmos work just like widgets, it should be snap.
You: Ok, we'll have it done in a week.

A week later you deliver the software.

Client: You know, we're really getting irritated at you guys, always late, always buggy...
You: You found a bug?
Client: Yeah, it crashed.
You: Where?
Client: I don't know...she said there was an error message.
You: Who, what message?
Client: I don't know, she didn't write it down.
You: Ok, we'll look at it. Anything else?
Client: Yeah, it doesn't do gizmos right. Color isn't important for gizmos, but you need to look up their price in the gizmo price warehouse site at www.gizmos-r-us.com.
You: What? But that requires us to do all sorts of internet protocol stuff that we hadn't planned on!
Client: That's ok, there's no hurry.
You: Uh, ok, what happened to the deadline?
Client: Oh, we just use the deadline to make sure you guys aren't slacking off.

A month passes as you scramble to code the internet connectivity portion. You deliver the software.

Client: Oh, you can drop the widget stuff, we barely do any widget analysis anyway.

You spend three days dropping the original portions of the software.

Client: Thanks, we'll review it.

A week passes.

You: Is the software ok?
Client: Yeah, we're just waiting for the senior VP to review it.

A week passes.

You: Is the software ok?
Client: Yeah, we're just waiting for the senior VP to review it.

A week passes.

You: Is the software ok?
Client: Yeah, we're just waiting for the senior VP to review it.

A week passes.

You: Is the software ok?
Client: Yeah, we're just waiting for the senior VP to review it.

A week passes.

You: Is the software ok?
Client: Yeah, we're just waiting for the senior VP to review it.

A month passes.

You: Is the software ok?
Client: Yeah, we're just waiting for the senior VP to review it.

A month passes.

Client: Ok, the thing is, the senior VP doesn't like the color.
You: The color? But those are standard Windows colors...
Client: But you can change them, right?
You: Well, yeah, I suppose...what colors?
Client: I'll set up a meeting with the senior VP.

A month passes during which the senior VP misses three meetings. Finally, you get your meeting:

Senior VP: Navy Blue screens with yellow listboxes and magenta error messages.
Client: Yeah! Great choices!
You: Uh...ok.

You spend a week changing the colors. You deliver.

Client: Thanks!

A month passes.

You: So how is the software working out?
Client: Oh, the users hate it because they have to do the widgets by hand and half of them can't stand the colors. They don't do much gizmo analysis anyway, so we're just going to drop it. Thanks, though, here's your check!


Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure


I've been there, done that.
o Yes 82%
o No 17%

Votes: 101
Results | Other Polls

Related Links
o Also by ucblockhead

Display: Sort:
Software specifications: Theory and Practice | 125 comments (117 topical, 8 editorial, 0 hidden)
you get screenshots? (3.63 / 11) (#3)
by rebelcool on Sun Jan 06, 2002 at 07:02:43 PM EST

lucky bastard...

COG. Build your own community. Free, easy, powerful. Demo site

Reminds me of... (4.20 / 5) (#4)
by kongslund on Sun Jan 06, 2002 at 07:06:09 PM EST

http://www.kongslund.dk/download/all_of_that .wav

Jonas Kongslund, Denmark
Agnostic and secular individualist

Wow (3.33 / 6) (#5)
by terpy on Sun Jan 06, 2002 at 07:08:07 PM EST

You worked for these people too? ex: "You mean yellow text on a red background looks this bad even though they are the colors in our logo?" +1

<joh3n> BUKKAKE: the final frontier
<joh3n> these are the stories of the starship: jizziprize

Dilbert (3.00 / 7) (#7)
by vambo rool on Sun Jan 06, 2002 at 07:18:39 PM EST

You must have seen today's Dilbert.

Or... (none / 0) (#62)
by Devil Ducky on Mon Jan 07, 2002 at 01:01:59 PM EST

It's just possible that Scott Adams read this story off of K5 and made that comic...

Notably that comic was probably submitted to his publisher several weeks ago and created some time before that; and this story was posted after the comics appearance... but all that means is that Scott Adams has a time machine... Lucky bastard.

Devil Ducky

Immune to the Forces of Duct Tape
Day trading at it's Funnest
[ Parent ]
It sucks, but I do it to people. (3.71 / 7) (#12)
by Sawzall on Sun Jan 06, 2002 at 08:37:06 PM EST

The reality is that if I had time to do the requirements right (anybody else had to use Doors?), create screenshots, process flows and all the other stuff that ought to be done, I would have written the damn thing myself. Instead, I am paying someone else to do it. But at least I am upfront about it.

But I have a developer who probably has my picture up on her dartboard anyway...

Opposite can be worse (4.00 / 7) (#13)
by spacefrog on Sun Jan 06, 2002 at 08:46:42 PM EST

I've worked on several software projects that resemble this article.

It can be hectic, It can be stresful. It can rob you of your evenings and weekends.

Scary as it may sound, if the engineer(s) are working as a closely knit group and are very familiar with the subject matter / problem / industry / etc, it can also be incredibly efficient.

But when the client doesn't know what they want (or aren't willing/able to tell you) and the engineers don't know a damned thing about widgets or what the needs of a widget analyzer clerk are, all hell can break lose. Those are the projects that generally end in failure. Failure of the project and usually failure of the business relationship.


On the other hand...

Doing it "by the book" can be as bad or worse. Twiddling your thumbs while you wait for a functional analyst to spit out a specifications book. Then waiting two weeks for the v.p. or project manager to sign off on the spec. A month has now passed and you now have a ridiculously detailed schedule (that will bear no resemblence to reality no matter how hard you try) and enough documentation to crush a Yugo.

In the meanwhile, if you had just locked the analyst, user, and dev team lead into a room for three days, the software would be done already (or at lesat in QA)....

Such an interesting industry in which we work.

Oh well, now I've vented, so it's back to trying to finish the project that was supposed to be done at end of the year....

pipeline your developers (4.50 / 4) (#21)
by andrewm on Sun Jan 06, 2002 at 11:33:49 PM EST

If you can't have your coders working on another project while other people work on the spec for the next, there's something to worry about. (If you're a very small company, chances are the coders will be helping with the spec, anyway, not spending a month playing quake.)

Oh, and that month you had them coding before you knew what the actual program was going to do - how much of that code do you really think is going to be exactly what was wanted? How much time do you want to sacrifice when it comes to changing all the old code to match the spec? Or will you change the spec to match the code, and who gives a damn what the client wants? (Hint: not much. and if you change the spec to match the code, you've got more problems to worry about than your supposedly "stupid" customers.)

If you can't design, hire someone who can. if you can design, why not work out what the customer wants before wasting time coding at random?

You definately need someone who can extract a client's real needs from them - this skill has very little to do with computers, and a lot to do with communication and business skills. Not something that makes much of an appearance in programming courses, though...

Not that I expect me ranting will change anyone's opinion :) It just annoys me that "I can't talk to customers" and "I don't know how to design anyway" usually get translated to "and anything that I'm not good at is obviously worthless."

(Not directed at anyone here: just because I'm replying to a particular message doesn't mean I'm commenting on that poster - this is more rant than flame)

Oh, and that schedule that doesn't have anything to do with reality - look at the people responsible for said schedule, and ask just how competent they are. There may be stupid customers, but just because your own management needs beaten with a clue stick doesn't mean realistic schedules are impossible.

[ Parent ]

The real problem (5.00 / 2) (#24)
by rusty on Mon Jan 07, 2002 at 01:19:35 AM EST

I don't think anyone would disagree with you. Having been there, I sure as hell don't. The problem is that people like you are rare as hen's teeth. People who understand how the technology works enough to talk to the coders, and how people work enough to talk to the clients, and who are willing to spend their time actually writing it all down, just don't exist in vast swathes of the software consulting world. I've only ever met one, and he was constantly fighting against both his management (who wanted the code "just done as soon as possible and no more of this mucking around with specs") and the clients (who wanted "You know, a widget analyzer" and then see above story).

So, the alignment of planets has to produce:

  • A client who realizes they actually need the expertise of the software company they are hiring to create a successful end product, and are willing to work with them to determine the project.
  • A consulting company which understands the necessary process and how much it costs, and can actually sell that to the above client so as to stay in business.
  • A person such as yourself, who can do the analysis.
I've never seen these things all happen at the same time. We all know they should, but they just don't. I don't think this has anything to do with anyone's attitude or tech-savvyness -- it's a fact of life in software consulting. At least, it always has been in my experience.

Not the real rusty
[ Parent ]
That person in the middle (5.00 / 2) (#27)
by ucblockhead on Mon Jan 07, 2002 at 01:47:13 AM EST

Whether or not I personally was one of those people is an interesting philosophical question. I can do it, but I won't. I've twice been the guy stuck between the developers and the people who we were developing for (though both entirely internal to a single company). It was, as you say, a battle, and I constantly felt like I was the guy no one wanted to talk to.

In both cases, the projects got done on time, and people were happy with the results, but in both cases, my blood pressure was killing me and I literally hated my job. I'd much rather be a simple coder.

The perfect place to be is in a situation where I am now (or was, or whatever) where we develop software not for a client but for general end users. (i.e. as part of a website, yada yada yada.) We've got a group that designs and creates the software and specifications are minimal. They are minimal because they can be minimal, because in a very real sense what the software does is determined as it is built. The software is its own spec. And sense everyone in the group has a reasonable sense of what can be done, the problems are all fairly minor. And because we are a small company, deadlines are inherently soft. It's done mostly when it's done.

IMHO, That's the main reason people like to work on open source, BTW. When you develop for yourself, you don't need a spec, and you don't worry as much about dates.
This is k5. We're all tools - duxup
[ Parent ]

Yes (none / 0) (#53)
by rusty on Mon Jan 07, 2002 at 11:10:59 AM EST

About developing for end users, and growing the spec as you go, I wholeheartedly agree. That's why working on Scoop is fun. I unveil a new feature, and immediately get feedback from the actual people who use it, telling me what's good and what's bad and where we should go next. It can be stressful, but it's fun stress. It's the pressure you put on yourself to live up to their expectations, not external pressure to meet absurd deadlines.

And I agree that that's why people enjoy working on OSS. I'm not worried about the viability of open source, mainly for that reason. It's fun.

Not the real rusty
[ Parent ]

so then rusty ... (none / 0) (#55)
by Kalani on Mon Jan 07, 2002 at 11:21:22 AM EST

What do you think of this slashdot feature that allows users to define their relationships with other users? I want my page littered with blood-red crystal balls!

No really, I haven't got any enemies, but how about just the blood-red crystal ball?

"I [think] that ultimately physics will not require a mathematical statement; in the end the machinery will be revealed and the laws will turn out to be simple, like the checker board."
--Richard Feynman
[ Parent ]
Um (none / 0) (#58)
by rusty on Mon Jan 07, 2002 at 11:53:09 AM EST

You mean the journal/friends thing? I can't figure out how it's supposed to work.

Oh, I see. This friends/foes killfile thingy. Actually, that's kind of neat, except I still hate the killfile idea. Maybe we can develop something similar. Of course, if we do it, it's likely to have an interface humans can undersand. ;-)

Not the real rusty
[ Parent ]

How was the move? (none / 0) (#56)
by wiredog on Mon Jan 07, 2002 at 11:21:43 AM EST

Looks like the storm that missed us is gonna hit you.

And, hey, what are you doing up this early? Lately it seems you've been posting at 2AM.

Peoples Front To Reunite Gondwanaland: "Stop the Laurasian Separatist Movement!"
[ Parent ]

the move, etc (none / 0) (#57)
by rusty on Mon Jan 07, 2002 at 11:44:55 AM EST

The move went pretty well. This place was filthy, but we've got a handle on it now, I think. The spiders have mostly been evicted, and the bird skeleton cleaned out from under the bed (I'm not making this up). Other than that, it's a great house. Much better suited to us than the old one.

I've been posting at 2AM lately because my days have been filled with Other Work. Today is the first chance I've gotten to sit down and read K5 during the actual day in quite a while. Of course, I'm supposed to be doing other stuff, but my wife isn't here to monitor compliance, so like an Iraqi chemist, I'm doing what I want to instead. :-)

Not the real rusty
[ Parent ]

Evicting Spiders (none / 0) (#59)
by wiredog on Mon Jan 07, 2002 at 12:00:24 PM EST

At my old place in Utah I only evicted spiders if I found them hanging out in the bedroom or bathroom. Scorpions, however, always got evicted to the back yard. Nothing like going in to answer a call of nature at 3AM and seeing a scorpion there waving claws and stinger with a "Come on! Step on me!" attitude.

And I never had a cricket chirping at 2AM.

Peoples Front To Reunite Gondwanaland: "Stop the Laurasian Separatist Movement!"
[ Parent ]

Spiders (none / 0) (#61)
by rusty on Mon Jan 07, 2002 at 12:54:00 PM EST

Spiders, in my house, get "evicted" with extreme prejudice. Usually they end up carried out in the trash, in much more comact state than they are used to.

I know, I know, they kill bugs, blah blah blah. That's what bats are for, as far as I'm concerned. Spiders may pursue their livlihood anywhere I don't live.

Scorpions are not a problem in Maine. Slugs also get kicked out, though, but usually not killed. They're too messy.

Not the real rusty
[ Parent ]

So then, (none / 0) (#63)
by wiredog on Mon Jan 07, 2002 at 01:17:36 PM EST

How does your lovely wife feel about bats flying around the place keeping the bug population under control?

Peoples Front To Reunite Gondwanaland: "Stop the Laurasian Separatist Movement!"
[ Parent ]
Bug-eaters (none / 0) (#91)
by BehTong on Tue Jan 08, 2002 at 11:54:25 AM EST

I'm not particularly fond of spiders, but I vote for lizards! Back when I was still in Malaysia, the lizards were almost welcomed into the house, because of the inexhaustible multitudes of (potentially disease-bearing) mosquitos, small moths that insist on landing on your dinner plate, and other unpleasant hexapods. The lizards were harmless, even pleasant to the eye (to me :-P), and kept the bug population under control.

Of course, they also love to scavenge, which can be annoying if you forget to empty your trash can at night. And they also sometimes get into brawls with each other, and make loud clicking noises. (But if you've lived in Malaysia for any considerable length of time, you'd probably not even notice the sound.) Now, if only they would stop hiding behind the cereal boxes and come out for food-snatching during dinner...

Yeah, they can be rather annoying. But not any more annoying than web-spinning spiders (and boy can those Malaysian spiders spin webs). Plus, many arachnid species in Malaysia are actually poisonous...

Beh Tong Kah Beh Si!
[ Parent ]

Open Source Software and analysis/specifications (none / 0) (#100)
by CodeBhikkhu on Tue Jan 08, 2002 at 06:15:20 PM EST

In my experience it is a misconception that open source software doesn't have an analysis period or specification. If you aren't aware, the linux kernel has a large grace period between releases where thousands of people discuss, with Linus and his lieutenants, feature additions to the kernel, design issues, the reasons for additions, and timetables. The analysis and the specification are in the mailing list archives.

As you have pointed out though, opensource software only gives them the ability to let the schedule slip a little more than is acceptable in a closed source software world.

The point of this post is not to challenge your statements or anything like that. I'm just pandering about oss.


"A week long Dalai Lama Fantasy Camp where you get to run around in red robes and eat rice and chant mantras with the Twelfth son of the Lama himself wont teach you what zen is." -- skyhook
[ Parent ]
OSS Projects (none / 0) (#104)
by ucblockhead on Tue Jan 08, 2002 at 08:49:43 PM EST

Yeah, I get what you are saying, though I think that projects like the Kernel, Apache, Samba, what have you are a bit unusual as Open Source projects go. A more typical project is like Scoop, where you've got a small group and the scope of the project allows a more seat-of-the-pants "Let's try it and see what sticks" approach.
This is k5. We're all tools - duxup
[ Parent ]
The horror (3.75 / 12) (#14)
by Tatarigami on Sun Jan 06, 2002 at 09:18:59 PM EST

Me: "This database app... you specified a character width of 50 for the name field, but some of the sample records you've given me have longer names than that in them. I can rework it to fit, but I'll need to revise some of the reporting functions."

Her: "Don't worry about that, we'll just use lower case letters. They don't take up as much room."

Me: "Uh, when they're stored on the computer they take the same amount of room. They're stored as codes rather than actual letters, you see."

Her: "Codes?"

Me: "Yeah, ASCII codes. 256-byte codes that represent letters, punctuation, etc."

Her: "Well, just take out all the codes for punctuation, we don't need those."

Here's one. (4.57 / 7) (#25)
by Mr.Surly on Mon Jan 07, 2002 at 01:32:36 AM EST

This really happened, with a customer that has tens of thousands of clients in their database, whom they invoice.

Customer: Take all of the last names in the database, and change them to upper case, and remove all spaces and punctuation. Oh, and make sure that future data entries are converted.

Me: Uh ... okay. (click)

So ... I check their data. Last names like this "Smith III", "Jones Jr." So I call them back ...

Me: You sure you want the database updated like that? You have stuff like Junior and the third in the names, plus some of the names have spaces such as Von Karmen.

Customer: That's okay!

Me: Okie Dokie ...

So I did it. About 2 weeks later, they called screaming about how their invoices have screwed up names on them. I pointed out that they asked for that, and I had told them it would look like crap. They said "oh yeah ..."

[ Parent ]
Mine gets better (5.00 / 3) (#68)
by Tatarigami on Mon Jan 07, 2002 at 04:32:52 PM EST

After telling the client that it was impossible to remove the unwanted characters from ASCII code, I got a 15 minute lecture on how nothing was impossible, and how the first computer-animated detergent advert had been created right there in that office by a graduate student who slept on the floor overnight because his PC took 80 hours to render the 1.5 seconds of animation. And this was after his teachers told him it couldn't be done.

So I patiently explained that she was right, it could be done, but it would require a team of developers, an OEM manufacturer's licence and a couple years work. So while it may be possible it wouldn't be practical for a DB she wanted by the end of the week and only planned to use on three workstations.


In the end, neither one of us got our own way... they decided to work around the 50 character limit by abbreviating their customers' names.

[ Parent ]
I'd be able to get so much work done, if it wasn't (3.25 / 8) (#15)
by sgp on Sun Jan 06, 2002 at 09:30:00 PM EST

... for the customers.

I'm a systems guy, not (officially) a programmer. But we have similar setups.
A common request is to set up some disk storage.
ME: "How do you want it set up? We can do RAID 0, 1, 5, 1+0, 0+1, the 1+0 can be done in two ways, ...."
Cust: "Whatever's best"
ME: "Nothing's 'best' - here's the pros and cons to each, which do you want? Surely the salesman went through this with you when you bought the stuff?"
Cust: "He said we'll get great performance"
ME: "Okay - do you want great read or write performance, or a compromise? Also, what reduncancy do you want?"
Cust: "Oh, not sure about read/write ratios ... best go for best of both - and we want redundancy, sure."
ME: "Well RAID5 is good redundancy, as is RAID 1+0; RAID 1 is good read performance, RAID5 is bad write performance. What do you want, you stupid bastard?"
Cust: "What the salesman said: the best for us"
ME: "But what the f**k do you do?!!!"

PS. Doing some programming too, which is "We need HTML because we do, and we need RTF because we want people to be able to edit it in a Word Processor"
ME: "You can edit HTML in most WPs these days"
Boss: "Yeah, but ... you can edit it in a WP if it's RTF"
ME: Ditto
Boss: Ditto
ME: "Okay, we'll do RTF, even if it's a pain in the arse"

There are 10 types of people in the world:
Those who understand binary, and those who don't.

That's your job (5.00 / 10) (#30)
by Sunir on Mon Jan 07, 2002 at 02:12:14 AM EST

The customer doesn't know anything about RAID controllers. That's why they hired you. Unsurprisingly, the customer doesn't know the answers to your questions.

Change your perspective. Your job is not to install a RAID controller. You job is to solve their data problems. If this involves a RAID controller, good for you. Ask the customer only questions they have answers to (always a good strategy), like what their immediate goals are for the system and what problems they are trying to solve.

Sometimes they don't know. That's why you measure. If they do more reads than writes, optimize reads or vice versa. Again, they can't answer your question because they didn't know that such a question existed. If you're going to ask the question, make sure you know the means of answering it.

"Look! You're free! Go, and be free!" and everyone hated it for that. --r
[ Parent ]

lighten up (3.00 / 2) (#40)
by kubalaa on Mon Jan 07, 2002 at 08:44:20 AM EST

Geez, can't developers go anywhere to bitch these days? If you ask me, it's the customer's job to know what they're doing as a company and to come up with a strategy to get there. That's why they're the company, and not you. If RAID controllers happen to play a key part of their business, then they damn well better know something about them.

(I really agree with you, but you're being a spoilsport pointing out the obvious and ruining a perfectly good rant-fest.)

[ Parent ]

Eternal struggle (4.00 / 1) (#51)
by silent communication on Mon Jan 07, 2002 at 10:27:12 AM EST

The setup of this forum encourages spoilsports by allowing replies. :-) Plus, we're all professionals, and aren't the types to want to continue making mistakes.

Clueless customers are your bread & butter. The salesguy actually convinced the customer to buy something without knowing exactly what he paid money for.

Programmers can be just as bad. "So, a balanced tree, or a hash? C'mon, are you accessing sequentially or randomly?"

Anyway, I don't think anyone likes being put on the spot. Email is a much better way for all parties, and make the emails reusable.

[ Parent ]
Or (none / 0) (#101)
by jayfoo2 on Tue Jan 08, 2002 at 06:47:36 PM EST

They could always hire someone who knows about them (hmmm, you?).


[ Parent ]
It's my job, but their system. (3.00 / 1) (#87)
by sgp on Tue Jan 08, 2002 at 10:28:32 AM EST

Okay, I wasn't too clear, we're not talking about "a RAID controller", but more typically 0.5-2 TB of data controlled by software RAID, where the hardware in the system (server, storage, network, etc) is typically worth a good few hundred thousand dollars. When a customer has a system like that, they'd better understand their application well enough to be able to tell me how they want their storage setting up - if they don't understand their application, and how it works, well enough to do that, then they probably don't know what they're doing at all, and their project is going to fail anyway.

There are 10 types of people in the world:
Those who understand binary, and those who don't.

[ Parent ]

Their business is not your problem (none / 0) (#105)
by Sunir on Tue Jan 08, 2002 at 10:21:49 PM EST

The customer bought a solution from you, making it your responsibility to deliver. You wouldn't be diligent to your company if you lost the sales contract. You could recommend to those responsible for the contract that it's a liability, but you'd better be sure it's a liability. The pont is, even if the customer's company is not going to succeed, even if they are insane, it doesn't make it your problem unless it's really is creating a problem for you.

Your job is to set up their data storage requirements. If they don't know what to do, it's because they don't know what to do. That's why they contracted it out. So, either figure out for yourself, or give them something that would definitely handle their needs even if it's more expensive, or maybe there's an interim solution you can use until more data is available at which point you will upsale them to the appropriate system.

Ignorance on their part means they are going to spend more than they had to. (Although maybe less than finding out the right answer + implementing the right answer.) This is a good thing for you and a choice the customer made of their own free wills. Sounds like a win.

"Look! You're free! Go, and be free!" and everyone hated it for that. --r
[ Parent ]

Tricks ... (4.28 / 14) (#16)
by iwnbap on Sun Jan 06, 2002 at 09:52:40 PM EST

On every official looking document, include a cover page, with a sign-off box. On the page put something like, "If no feedback concerning this document is provided within 10 working days of delivery, Gnomoco will assume that it is approved in its entirely by recipient <guy managing your contract>". Send one to the guy and one to his boss.

Monthly status reports. Ensure that every monthly status report you're seeing not only the guy in charge of you, but that guy's boss as well. In the report include a set of "outstanding actions". Inevitably there will be lots of "EmployerCo provision of specification x" or "EmployerCo conducting on site-tests of product y". As soon as anyone mentions the word "slip", a timesheet will appear showing the amount of time spent waiting for some customer action.

If they won't tell you what to do, tell them what you're going to do, (preferably in a big thick document) and ask them to sign off on it. And then bill them for the time to prepare the document.

Don't stop talking to them. Don't stop visiting them on-site. Don't stop telling them about the problems your having, or telling them how hard your working. Don't ever, ever stop sending them invoices.

Whoa, too cynical. (4.25 / 4) (#29)
by Sunir on Mon Jan 07, 2002 at 02:05:21 AM EST

Why would you try pissing off your customer? That's so cynical, it's suicidal. Do you think your customer will be happy if you start randomly charging them for make work projects you arbitrarily decided to charge them for? The customer expects you to be working on solving their problem, not on creating their bill for four months.

An easier solution that's less cynical is to begin solving the problem. Get as much of an onsite customer as you can muster. Have carding sessions to determine the user stories. Give them a version every two weeks, and get feedback. No feedback means the software is useless and (therefore) the project is failing.

The problem is that the customers are the only people who know what they want--and even they don't know what they want yet. The engineers are the only ones capable of realizing what the customer wants--and even they don't know how yet. Not only do you have to iterate development to gain valuable feedback, but you have to do so cooperatively. If you begin by cynically assuming the customers are evil, the consequences are your fault, nine times out of ten.

Maybe I'm wrong, but I'll tell you this. Whenever I get the chance, I work like the above. In every case, the powers that be prefer my team over the other teams because we always say yes and the other teams say no. In the end, the customers get software they actually like instead of software they "just have to live with."

"Look! You're free! Go, and be free!" and everyone hated it for that. --r
[ Parent ]

No feedback (4.00 / 3) (#35)
by codemonkey_uk on Mon Jan 07, 2002 at 05:15:32 AM EST

No feedback doesn't nesseserly mean the project is failing. It might mean "it just works". In my experiance people are much more likly to send negative feedback than possitive feedback. A customer with working software, doesn't feel they have to tell the developers anything - there doing okay as they are.

Of course, this is also a big buisness / small buisness thing. Your approach works great when your dealing with small companies, but somethimes, especially when dealing with large corporations, iwnbap's approach is neaded as well.
"The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
[ Parent ]

Differing Perspectives (none / 0) (#95)
by Bear Cub on Tue Jan 08, 2002 at 02:21:18 PM EST

We're all painfully aware that there's often a huge culture clash between geeks and management. (Or, in this case, geeks and their customers. A comparison of the Hacker FAQ and the Manager FAQ shows exactly what I'm talking about.

From a geek's perspective, iwnbap's advice might be cynical. From iwnbap's customer's point of view, she's ensuring continuous feedback between the customer and the development team, and making sure she's getting the information that she needs to get the job done.

No, her techniques are not subtle, but they do get the message across: yes, this is actually important. And they're easily modified so as not to ruffle too many feathers: Submit requests for sign-off to your customer, but not his boss. Follow up with a call. If he doesn't get back to you in a reasonable time, then start with the pressure.

------------------------------------- Bear Cub now posts as Christopher.
[ Parent ]

This is called "Analysis" (4.27 / 11) (#17)
by Shimmer on Sun Jan 06, 2002 at 10:15:34 PM EST

I know this story is meant to be funny, but it's actually kind of sad to see it on a supposedly tech-savvy site.

The act of creating a software spec is called "Analysis" and it's typically every bit as critical to the success of the project as the programming.

I happen to do analysis for a living these days (and I probably make more than the average programmer as a result). If you think your customer is going to do it for you for free, you've got another thing coming.

-- Brian

Wizard needs food badly.
Analysis (4.50 / 6) (#19)
by ucblockhead on Sun Jan 06, 2002 at 10:50:21 PM EST

All true, yet it requires clients who understand the need for analysis in the first place. I've run into too many situations where customers simultaneously wanted completely control over every little thing and simultaneously wanted no involvement whatsoever. You can't do good analysis without talking to the people who want the sysytem, and that takes their time as well as yours. But when you've got managers who don't understand the technology (the person who demanded the color changes said "What's Microsoft Word" when told the color changes were the same as all standard Windows apps...in 1996!) but insist on "input", well, you've got the sort of thing outlined above.
This is k5. We're all tools - duxup
[ Parent ]
What *should* have happened (4.80 / 10) (#33)
by codemonkey_uk on Mon Jan 07, 2002 at 05:00:59 AM EST

Where this happened:
Client: We'd like a widget analyzer on April fifteenth.
You: Uh, ok, do you have a specification?
Client: What?
You: You know, a document that specifies the software?
This should have happend:
Client: We'd like a widget analyzer on April fifteenth.
You: Uh, ok, do you have a specification?
Client: What?
You: That's okay. We can do that for you as well. We'll need to come on site and talk to a few people before we get started. Can you arrange that for me?

"The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
[ Parent ]
Closer, but still no cigar (3.00 / 1) (#77)
by Shimmer on Mon Jan 07, 2002 at 11:48:06 PM EST

Analysis for any significant size project requires more than "talking to a few people before we get started". You need to establish a project plan for analysis (with deliverables) just like you do for design and implementation.

So the actual conversation usually has to go something like this:

Client: We'd like a widget analyzer on April fifteenth.
You: No problem. We'll do this in phases. In the first phase, we need a week or two to sit down with your experts and understand your business requirements in detail.
Client: Uh, okay. When can you get started?
You: Right away! I'll send you the project plan.
-- Brian

Wizard needs food badly.
[ Parent ]
Nah (3.00 / 1) (#82)
by Sunir on Tue Jan 08, 2002 at 02:23:50 AM EST

If the project is due by "April 15th", it isn't significant enough to do an up front risk and business value analysis. That would cost more than developing the product, and definitely more than the product would create in business value.

Moreover, 19 times out of 20, the customer just doesn't care about the analysis. Therefore, the analysis documents are not deliverables.

"Look! You're free! Go, and be free!" and everyone hated it for that. --r
[ Parent ]

Come again (none / 0) (#84)
by Shimmer on Tue Jan 08, 2002 at 09:40:16 AM EST

You're trying to tell me that an "857 man-hour project" isn't significant enough to warrant a short analysis phase? Please. If it's so insignificant, why are we arguing about the best way to accomplish it successfully? Just whip it out (no XP or other methodology necessary).

Meanwhile, back in the real world: If the customer doesn't care about the analysis, you have to explain to the customer why it's important. Hint: If you do it right, the project will take less time.

-- Brian

Wizard needs food badly.
[ Parent ]
my wholehearted agreement (none / 0) (#99)
by CodeBhikkhu on Tue Jan 08, 2002 at 05:54:40 PM EST


I agree with you. Even a seemingly small project, in my experience, needs a period of requirements gathering and domain analysis. It is unfortunate that most managers don't realize the payoff of an analysis period. In fact most programmers don't either. I believe that it is the belief of many managers in small software companies that any time NOT spent coding is time wasted. In my studies of software engineering I've come to understand the relationship between analysis, design, and coding. It is a myth that software will be completed on time and on schedule if analysis and design are not peformed prior to coding. Massively changing requirements have the single most detrimental effect on software schedules and costs. A monumental requirement change in the middle of the coding cycle could easily double the delivery time of the software if the feature wasn't previously discussed.

I would rather trade two weeks to a month in analysis and one month in design for an extra ten months in coding due to changing specifications.

As you've pointed out, it is interesting to note that taking more time at the beginning of the project for analysis and design work will actually result in the product being delivered cheaper and faster in the long run. Coding on the project takes the most time and if the lead designer can eliminate and factor into software designs as many factors as possible right away then they have eliminated the most costly portion of software development.

From a cost analysis perspective, I'd rather pay two software engineers two months pay to analyze a project's domain and produce a design than to pay four software engineers four months pay (original projection) and then another four months pay due to changing requirements or unseen factors.

One final thing. You say to tell the customer that "if you do it right, the project will take less time." This is a great idea, but unfortunately in my experience not even my managers believed that, and that is as far as that got. Needless to say I quit that company and work somewhere where analysis and design are instrumental to our software delivery process. Luckily we also work on a release schedule that is years ahead of current technologies.


"A week long Dalai Lama Fantasy Camp where you get to run around in red robes and eat rice and chant mantras with the Twelfth son of the Lama himself wont teach you what zen is." -- skyhook
[ Parent ]
Amen (none / 0) (#103)
by Shimmer on Tue Jan 08, 2002 at 08:20:44 PM EST

You're right that alot of people resist analysis (witness the many "well-informed" XP fans on this thread).

I think the main reason for this is that analysis has a bad name because most programmers don't know how to do it. Lord knows I sure didn't for the first 10 years of my professional software development life.

For example, many developers seem to think that knowing OOP makes them competent to practice OOA&D. You might be interested in an article I wrote that addresses this issue.

-- Brian

Wizard needs food badly.
[ Parent ]
Staticware (none / 0) (#111)
by Sunir on Wed Jan 09, 2002 at 12:09:58 AM EST

Maybe I'm missing a fundamental point, but I reject your article on the simple basis that we're working in software. For instance, in your article, you suggest systems degenerate into spaghetti code (and in OOA&Dland, ravioli code). This is just another unsurprising phenomenon created by entropy kicking us in the teeth; you know, things get worse unless you make them better. Fortunately, since we're working in software, it's not difficult to keep the system clean and efficient for long periods of time. Write unit tests, refactor constantly, integrate constantly.

Later on, you suggest OOA is based on the world being static. It's apparent though that the world isn't static. Structures change all the time. Your example, that a labrador retriever will not become a poodle while true in that case startingly doesn't pan out in general. Often scientists discover that two previously thought to be unrelated "species" are actually the same species. Look at the case of the red fox Vulpes vulpes for instance.

Maybe more interesting to us, consider a payroll system. Before you are done implementing it, the next union contract will be ratified and the very expensive OOA will be invalidated. Secondly, it doesn't matter because the software is not static. It's not a building or even a chip. As you code for new cases, you can reorganize the code to deal with it. This is far less expensive than attempting to do everything perfect from the beginning. What happens if the OOA is wrong? Recall the Waterfall graph of progressing costs of defects. If it's cheap to detect and repair defects, then defects won't cost you much if you're diligent. The trick is in keeping the costs down, hence the small iterations, testing, and continuous integration (detection) and the testing and refactoring (repairing).

Finally, you discuss the Employee class. You very excellently describe the need for separation from thing and role. Still, your model still fails to describe Western society adequately. Some people don't have last names. It's unreasonable to model Jane as a Woman because her sex is either irrelevant or possibly alterable--and that really is a serious concern. The salary member is in the wrong class as hourly employees are paid by a wage. You haven't modeled union benefits correctly, or bonuses, or insurance.

We could add all of those, of course, but like I said, it's going to change as soon as the contracts change. Quite frankly, you can't capture all the requirements ahead of time. The question is, how are you going to adapt?

So, to turn your retort back on yourself, many "well-informed" OOA&D fans insist on analysis despite the fact it's typically turns out to be wrong at the end. ... Why?

"Look! You're free! Go, and be free!" and everyone hated it for that. --r
[ Parent ]

Thanks for the feedback (none / 0) (#117)
by Shimmer on Wed Jan 09, 2002 at 08:32:49 PM EST

I reject your article on the simple basis that we're working in software.

Later on, you suggest OOA is based on the world being static.

I would be the last one to deny that the world is a very dynamic place. Data changes, new requirements come in, etc.

The fact remains, however, that even in software you have to pick a set of fixed entities that you're going to deal with. These entities are static in the sense that you write hard-coded classes and tables for them. E.g. A Person class and table, a Company class and table, an Automobile class and table, etc. I don't see how you can get around this, even if you practice XP.

The challenge, then, is to pick the right set of entities to hard-code. Right how? Well, common sense says to pick the entities that are least likely to change their structure and relationships over time. Otherwise, you spend all your time "refactoring" code every time a new requirement comes in. This is the essence of good analysis, a sorely neglected part of software development.

Thanks again for reading the article. I appreciate your comments.

-- Brian

Wizard needs food badly.
[ Parent ]
The factors in cost analysis (none / 0) (#119)
by Sunir on Thu Jan 10, 2002 at 02:23:13 AM EST

The question is, does the cost of refactoring exceed the cost of analysis?

I'm no fool. I know that the answer to that is not always yes or no. For a lot of code, the cost of refactoring is actually very low compared to analysis because it's part of keeping the system quality high. Bugs cost a lot of money, and spaghetti code costs you a lot of bugs. The analytical solution would essentially require writing the system anyway, except typically analysts do this in a less formal language than code (which adds ambiguities too).

On the other hand, there are some things you just cannot refactor. Published specifications, for instance. GUIs are very difficult to refactor. Database schemas are very expensive to refactor once you've committed to them. Contracts are almost impossible. Analysis here can help.

The point where we mostly disagree is that you think that the Person class is hardcoded, when I think that the Person class is just part of the internal data model of the system and thus completely soft. The only parts of the system that really meet friction when changed are those that interact with "The Rest of the World." GUI, network protocols, database schemas. But anything inside the program itself (and in general, any code owned by the company) is up for grabs.

As for XP, there was some mention of writing an optimizing compiler using XP principles from scratch. Would it end up having a lexer, a syntatic transducer, ASTs, and a code generator? Or something else? This isn't a strange suggestion. XP people just don't believe in hardcoded things.

Many people (including myself) think this has to do with the difference between the Alan Kay "object-oriented" and the Grady Booch "object-oriented." XP comes from Smalltalk culture, not the Waterfall-lawsuit culture that resulted in Rational. I think this is why I no longer take OOA&D seriously. It's just another pointer to dereference, not a crystal box.

"Look! You're free! Go, and be free!" and everyone hated it for that. --r
[ Parent ]

Mandatory subject line (none / 0) (#122)
by Shimmer on Thu Jan 10, 2002 at 11:40:28 AM EST

The point where we mostly disagree is that you think that the Person class is hardcoded, when I think that the Person class is just part of the internal data model of the system and thus completely soft.

I think you are seriously underestimating the investment that organizations make in these data models. In many cases these days, an organization's software is among its most valuable assets. Saying that a class is "just" part of the data model is like saying a person is "just" an employee or "just" a customer.

XP comes from Smalltalk culture, not the Waterfall-lawsuit culture that resulted in Rational.

Personally, I'm completely anti-waterfall and don't have much respect for Rational. I actually love Smalltalk and came out of the Smalltalk world myself -- I worked on the world's largest commercial app written in Smalltalk and even had lunch with Kent Beck once (a long time ago).

That said, I believe that Smalltalkers need OOA as much as anyone. Possibly more, because writing Smalltalk can be like playing tennis without a net -- it looks easier than playing with a net, but is actually harder if you're not careful.

-- Brian

Wizard needs food badly.
[ Parent ]
Yep (none / 0) (#76)
by Shimmer on Mon Jan 07, 2002 at 11:42:40 PM EST

That's what sales folks and project managers are for. Seriously.

-- Brian

Wizard needs food badly.
[ Parent ]
I've been burnt (4.42 / 7) (#18)
by sludge on Sun Jan 06, 2002 at 10:33:30 PM EST

I've spent the last year and a half as a contractor. In this time, I've been burnt by something that is familiar to this. As such, I've come up with a few answers to these problems.

First: I write the spec. I talk to people and take notes, and spend a while listening to what people want in the software. I feed back the notes to my main contact in the company, and upon confirmation, the spec gets drafted.

At this point, I slash a major feature out of the document. Boom. On the floor. I send it in for review to make sure it's what they want. I have never had the major missing feature pointed out to me. No one seems to read my specs, even though they're very nicely formatted and articulately described. I put the feature back in as I intend to give them the results they want.

I give two billing options. First, I offer a time estimate. The time estimate is not contractually binding, and I will need to be compensated for my time.

If the project is small (around one man month), I offer that they pay for results. I give my time estimate and they do not pay if I go 1/4th of the project's time over. This works out well for me, and the fact that I cap this allows me to have some room to bargain if they are making me put my professional life on hold for two months while waiting for a password to the database.

So far everyone is interested in paying for results. That's fine by me. I've done projects on budget and on schedule, but never less than budget or schedule. Things have worked out pretty well since my original burning. My current contract is on schedule enough that I am finding time to post this message.
Hiring in the Vancouver, British Columbia area

Yeah, but ... (3.00 / 2) (#23)
by Mr.Surly on Mon Jan 07, 2002 at 01:16:52 AM EST

    First: I write the spec. I talk to people and take notes, and spend a while listening to what people want in the software. I feed back the notes to my main contact in the company, and upon confirmation, the spec gets drafted.
Okay, in my experience, writing a spec can take many hours, in the actual writing, phone calls, meetings, ect. Time is money. Clients rarely want to pay for any of this.

Therefore, crappy spec, crappy product, pissed off client.

Of course, it's okay with my boss if we have to pursue a project that is best described as a "cluster fuck," because "it pays the bills." Doesn't matter if it's not the best thing for the client, or my sanity.

In any case, this reads as more of a documentary of my career rather than a humorous article.

[ Parent ]
There's a lesson there (4.33 / 3) (#28)
by Sunir on Mon Jan 07, 2002 at 01:49:35 AM EST

If no one is reading the specification, stop writing the specification. It's a waste of money and it's could create massive liability for you if you fail to meet the specification. My motto: traceability is liability.

"Look! You're free! Go, and be free!" and everyone hated it for that. --r
[ Parent ]

useful for self (4.00 / 2) (#39)
by kubalaa on Mon Jan 07, 2002 at 08:33:27 AM EST

In writing the spec, you resolve lots of issues that you otherwise might not have encountered until coding time. Sometimes just spending a few minutes thinking can save you from hours trying an implementation that won't work. So it's still good to write and have a spec for your own reference, even if nobody else reads it.

Following the same philosophy, when I sit down to write a chunk of code I write the comments first. If something's not clear in the comments, it sure isn't going to be clear by the time I get to coding it. Usually just doing this will get things clear enough that the implementation is a breeze, and it's already well-commented to boot.

[ Parent ]

I am a good contractor. (5.00 / 1) (#75)
by sludge on Mon Jan 07, 2002 at 11:01:34 PM EST

You are making a goofy assumption that if I don't write a spec doc, I will have to implement less features and people will be satisfied sooner. This is never the case. What happens in reality is that people will continue to ask for more and more until you are far beyond what you initially agreed to.

At this point, it becomes very handy to point out the spec, show what they agreed to, and give a quote for the additional features.

A lot of people have contracting anecdotals which tend to include a lot of animosity towards other parties. Some of it is justified, but a lot of the time it can be prevented by intelligent project management.
Hiring in the Vancouver, British Columbia area
[ Parent ]

hourly rates (none / 0) (#79)
by ucblockhead on Tue Jan 08, 2002 at 12:11:13 AM EST

What happens in reality is that people will continue to ask for more and more until you are far beyond what you initially agreed to.
That's when you say to yourself "thank God I charge by the hour!"
This is k5. We're all tools - duxup
[ Parent ]
Scope creep is no problem (5.00 / 1) (#81)
by Sunir on Tue Jan 08, 2002 at 02:05:56 AM EST

Here's a very simple solution to scope creep. I (meaning any team that foolishly agrees to listen to me) work doing something called a work queue. Essentially, whenever you are done a task, you pick a new task off the top of the pile of index cards. Well, near the top. Developers still get to choose what they work on.

I let the customer add as many tasks to the pile as he or she wants. What the heck. It's only more index cards. The catch is that the customer is also responsible for sorting the cards in priority. Since I only work forty hour weeks, and each iteration deadline is a hard deadline, the customer quickly learns that prioritizing poorly is a bad idea. (Iterations are only a couple weeks.)

The goal is to teach the customer to prioritize in terms of the most pain. What hurts the most now? We will fix that next. No visions. No grand plans. Just focus on the problem.

The nice thing is that at any time, the customer will have something working that represents their investment so far. They can terminate the project at any time, even after the first iteration (which I always suggest), and say "That's enough for us, thanks." This limits the chance they will sue you (unlike an up front spec which increases the chance they will sue you). Additionally, after the initial time period has expired, the customer will still have a big pile of cards leftover. You might be able to extend your contract if you want, provided you did a good job.

It seems to work for me. But I'm not a contracter; I'm an employee. Software contracts are really evil, and lead to the creation of Waterfall. Lawsuit after lawsuit, we got this big bloated pile of "liability-reducing" crapola as the standard software engineering practice. Bleh.

"Look! You're free! Go, and be free!" and everyone hated it for that. --r
[ Parent ]

I know this is supposed to be a joke.. (4.53 / 13) (#20)
by andrewm on Sun Jan 06, 2002 at 11:21:30 PM EST

Clients generally speaking are not stupid. Managers generally know how to run a business for a profit (and the ones who don't can actually lose their jobs)

That said, they are not software designers. If you expect them to come to you with the design already done so you can just write some code, you're not doing your job (or perhaps your company needs to hire someone to take care of that part of the process so they can provide you with a high quality spec for what's needed). A far more rational situation has them come to you with nothing but problems - then once you know what the problem is, you work _with_ the customer to figure out the best software to meet their needs.

When you do get a 'stupid' customer to deal with, treating them like crap isn't going to help. It's more useful to make sure someone on the team is skilled at talking to the customers, finding out what they need, and then translating that into the spec for the software. Then the developers can start working on the 'how to build it' and actually doing the coding. (Most of the problems I've seen have had more to do with communication problems with non technical people, rather than anyone being stupid - if you'ld rather not deal with all that fuzzy stuff working out what a program should do and just want to code, get someone else onto your team who can do that. Then the customer will be happy, you'll be happy, and they won't go looking for a company that will treat them decently - driving paying customers to your competition tends to be a really stupid business plan.)

If they've been sold something (eg, a RAID system) by a salesman who was concerned about making the sale and not the least bit interested in what they actually need it for, then there's a reasonable chance they won't know why they got it. (Ok, so I've contradicted myself here - anyone who buys something without understanding what they need it for is probably not all that competent to run a business. Still, there's almost certainly going to be something that motivated them to go talking to the salesman in the first place - I wouldn't want to be the one telling them that my company just sold them an expensive machine they don't need, though ;)

A wise system analyst once told me: (4.33 / 6) (#22)
by sakusha on Sun Jan 06, 2002 at 11:51:38 PM EST

"In theory, there is no difference between theory and practice."

Yogi Berra and the full quote (4.60 / 5) (#41)
by wiredog on Mon Jan 07, 2002 at 08:51:33 AM EST

The Great American Philosopher Yogi Berra said:

"In theory, there is no difference between theory and practice, in practice, there is."

Peoples Front To Reunite Gondwanaland: "Stop the Laurasian Separatist Movement!"
[ Parent ]

Hey, I've got a secret... (4.46 / 15) (#26)
by Sunir on Mon Jan 07, 2002 at 01:34:27 AM EST

Why are you killing yourself doing Waterfall? The failure rate is 92%. Stop that. No really, stop that.

Sure, I know you learnt somewhere from some whizbang professor or some author who doesn't code that you have to do Requirements, Analysis, Design, Implementation, Integration, Test, Fail, but it doesn't need to be.

Try something else. If you've got the chutzpah, try XP. If not, at least give Alistair Cockburn a read or two.

We don't use specifications or MS Project. We replaced them with $5 of index cards. We don't need a specification. The requirements change every three days anyway. That's because we release a new version every hour, so the clients can tell us where it hurts very quickly.

By now you might have noticed the links to the venerable WikiWiki. Read the whole thing. It'll take you a year, but if you've just come out of college, you've got the time. It's worth it. There's no reason to waste millions of dollars a year, or to work 80 hours a week.

Deprogram yourself, comrade..

"Look! You're free! Go, and be free!" and everyone hated it for that. --r

Oh no, not the XP lemmings again... (3.66 / 3) (#66)
by valency on Mon Jan 07, 2002 at 03:34:10 PM EST

"Don't worry, we're going to start running in this direction, and if it turns out to be the wrong way, we'll just turn around. It won't cost you any extra, because turning around is free."

-- bad-managers.com

If you disagree, and somebody has already posted the exact rebuttal that you would use: moderate, don't post.
[ Parent ]

*I* am an XP lemming? (4.50 / 2) (#69)
by Sunir on Mon Jan 07, 2002 at 04:52:42 PM EST

I read that earlier today when it was on WikiWiki. It's hilarious, and definitely true.

But give me a break. I ain't no lemming. I have been traditionally very vocal against the XP zealots because they take what is indeed almost sensible and turn it into another useless methodology in the snide sense. Personally, I don't think Kent Beck has been the sterling leader, holding back the hordes of ignorant wankers, that he should be. Maybe a little of the opposite.

While XP is interesting, that doesn't mean it's right. I find XP's intransigence to self-reflection hypocritical, especially since they've changed it several times over the last few years in very confusing ways.

Look, there was XP before The Book (Extreme Programming Explained: Embrace Change) and XP: the consulting business afterwards. One was interesting (though imperfect), the other has turned into mostly noise (at least to me).

If I had to pick one methodologist to listen to, I'd pick Alistair Cockburn. He at least listens to the client before suggesting things. His latest is a good testament to that.

"Look! You're free! Go, and be free!" and everyone hated it for that. --r
[ Parent ]

Heh ... (4.50 / 2) (#70)
by Simon Kinahan on Mon Jan 07, 2002 at 05:54:18 PM EST

Well that was funny, and in some places even insightful, but the author spoils it by being rude in ways I don't think are warranted. Like inferring that "refactor constantly" means "diddle endlessly with your code".

None of the explanations on WikiWiki, which seems to be to be the best explanation of XP, would endorse that: its intended just to mean "if its wrong, change it *properly*". I find that rule very important (although I don't do XP, and probably wouldn't), because I've seen lots of projects where people put in badly-written "patch" code to avoid refactoring stuff they did not understand. Along with some of XPs other rules, the idea seems to be to keep real understanding of the code alive, which on long projects really matters.

Interestingly, the one thing that it doesn't even mention is that XP relies on "release early and often" to get real user feedback. I do think this is probably the most important element, and how they get away with not doing analysis.


If you disagree, post, don't moderate
[ Parent ]
Not a great critique (5.00 / 2) (#89)
by ajf on Tue Jan 08, 2002 at 11:24:35 AM EST

I'd agree with you that he has some good points, but in places he's refuting things that just aren't part of XP at all. For example:

Another problem is that pair programming takes a "peer" concept: it ties up one experienced programmer with a clueless sidekick.

That sentence contradicts itself, and unfortunately the rest of the argument follows from the incorrect half. As it says over on WikiWiki, pair programming is done by peers. He's arguing that pair programming is bad because of how undesirable a senior+junior pair is - a situation XP advocates specifically recommend avoiding.

There's also his complete misreading of refactoring (which you mentioned), and unit tests:

The basic premise is that the test class is written before the real class: thus, the end purpose of the real class is not to fulfill a requirement, but simply to pass all the tests that are in the test class. Then - and this is the ingenious part - you can make changes to your code, with the confidence that if you've introduced a random unexpected bug, you'll have anticipated it in at least one of your unit tests.

The primary benefit of unit tests is to catch regressions as soon as possible, not to catch unforeseen bugs. In fact according to XP you should add a new test each time an unforseen bug is discovered - which wouldn't make sense if XP made the claim he's trying to refute here.

He seems to think continuous integration involves throwing together random bits of source code from everyone's development tree, even if they're in the middle of writing a statement. This page on continuous integration talks about CruiseControl, a build system that watches the CVS repository for changes and triggers a build whenever new code has been checked in. But look at what he's saying:

What this rule really means is "integrate your code at least once a day, ideally more often".

This leads to artificially induced integration: imagine you're a quarter of the way through a complex code module. It's four PM. Your co-worker comes round and tells you your code must compile perfectly in five minutes, ready for integration.

Again what he's arguing against doesn't bear much relation to what XP says. This situation just doesn't occur, because the build comes from what's in source control, and you wouldn't check in code in the state he describes.

I'm not an XP advocate (I've worked with some of the practices it entails, but not the whole hog), and I'd certainly be interested in reading about real-world XP failures. But in this article, he admits he's never tried XP, doesn't have any concrete examples of XP being a failure (whereas XP's proponents do make the opposite claim), and worst of all he hasn't even listened to what XP advocates are saying, so he ends up agreeing with XP's conclusions as often as he refutes them.

"I have no idea if it is true or not, but given what you read on the Web, it seems to be a valid concern." -jjayson
[ Parent ]
92% (none / 0) (#97)
by Oblomov on Tue Jan 08, 2002 at 04:15:23 PM EST

Do you have any links to back that figure up with data?

[ Parent ]
Difficult, but I'll try. (none / 0) (#112)
by Sunir on Wed Jan 09, 2002 at 03:16:40 AM EST

First, you should realize that no one does a study in software methodology unless they are trying to sell you something. No facts and figures are valid. Also, due to the high degree of plagiarism in the field, it is difficult to cross-validate data against similar but different data. Finally, since the data is generated for a goal, very few people are interested in measuring the actual failure rate of Waterfall since it is so dismal that everyone would agree that it sucks. Thus you have interpolate it from existing facts. Consequently, given all that, you should immediately doubt any figure I'm going to cite. But I'll pretend I'm authoritative for a moment, if you're willing to suspend disbelief.

Now, given that Waterfall is predominant (and it is--I'm not looking those figures up for you), we have immediately the Standish CHAOS98 report that gives 91% failure. My memory failed me, sorry, but I was close. Others have built on this, commenting that "the waterfall was associated with the highest degrees of failure" (Google cache) and that "The traditional reasons for apparent failure of IT projects overrun schedules and budgets and failure to meet requirements stem from traditional development methods of the sequential, waterfall type.". The U.S. military also discovered a 90% failure rate for Waterfall specifically.

Additionally, we have even Rational beating up on it. Some J. Random Methodologist also chimed in.

Finally, here's a nice presentation on the Software Crisis you may be interested in.

"Look! You're free! Go, and be free!" and everyone hated it for that. --r
[ Parent ]

The lesson .. (none / 0) (#106)
by Highlander on Tue Jan 08, 2002 at 10:40:33 PM EST

.. is Do not confuse the product with the brand.
But there is more.


(sheep) (sheep)

Moderation in moderation is a good thing.
[ Parent ]
reporting in (none / 0) (#113)
by Highlander on Wed Jan 09, 2002 at 02:23:56 PM EST

begin reporting in calculations with the tokens of rudolf, paul, peter and the german shepherd
fighting the pitbull (for what they are worth).

Moderation in moderation is a good thing.
[ Parent ]
report payload (none / 0) (#114)
by Highlander on Wed Jan 09, 2002 at 02:52:38 PM EST

Fallacies I see are:
A human is composed of lots of different subagents, so no common single creator/superagent exists for all, making the entire argument chain brittle.

In other words: Contracts and a little hacking keep the world going.

Communications between agents drops packets, so there is no guarantee of returns and profits anyway, which means agent motivation drops (considering taking nested games into account).

Apart from that:
The distance of the infestation, if it exists, might be inferable from the arrival times.

Why the creator should set a time limit himself is beyond me.

Agent reports returning back to standard operation.

Good Game.

Moderation in moderation is a good thing.
[ Parent ]
Too true. (4.00 / 5) (#31)
by Masa on Mon Jan 07, 2002 at 04:34:22 AM EST

OK, that was funny. In some perverted way, anyway. After reading the "How it will actually happen" I almost bursted crying. I'm currently working at the project which is exactly like that one. Actually, I've been working at the similar project for past two years now. And it seems the hell and torture will never end.

At the beginning of the project, I estimated that the project will take over 200 working days while two men are working at it. Well, my own boss back-stabbed me and made a contract which estimated that the project will take less than 100 working days. Well, that was quite nasty but the best part was (and still is) that I'm working with the project ALONE. Yes, I'm all alone with the project. I'm the project team. I'm the only member of it and I'm the project manager. And I'm not allowed to allocate any recourses to the project.

I'm in deep shit. And the article above was so true.

In deep shit? (4.25 / 4) (#34)
by codemonkey_uk on Mon Jan 07, 2002 at 05:06:16 AM EST

No your not. You told the boss how long it would take. When it doesn't arrive on time, its his problem. And if he tries to make it your problem, either go to the level above with the facts - he fucked up - or get the hell out of dodge.
"The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
[ Parent ]
You're right about that. (4.00 / 1) (#36)
by Masa on Mon Jan 07, 2002 at 06:01:30 AM EST

Well, you're right about the responsibility. But I'm stuck with this project and quite desperate, because I can't just dump the project, I can't have any help and I'm too loyal to just to leave the company. Right now, I'm trying to do as much work as I can with zero motivation and trying to make usable product so I hopefully can some day start with a new project.

[ Parent ]
Personal Lost (4.00 / 3) (#37)
by pazu on Mon Jan 07, 2002 at 06:18:08 AM EST

Oh, I know this feeling very well. You can tell your boss he screwed everything up and you won't be able to complete the software. But then it will be a personal failure to you. _YOU_ weren't able to do your job. You've failed.

I'm in a very similar situation. I've made plans for an enterprise application, decided many things with my boss, started coding... and nothing's done yet. My boss(es) can't decide on what they want, they won't allow hiring anyone else to work with me, and they won't listen to a "it's impossible to do it alone".

Oh, I know this feeling.

[ Parent ]
well, almost (none / 0) (#121)
by ethereal on Thu Jan 10, 2002 at 09:10:21 AM EST

You can tell your boss he screwed everything up and you won't be able to complete the software. But then it will be a personal failure to you. _YOU_ weren't able to do your job. You've failed.

If you don't complete it at all, then it's your failure. If you don't complete it on your boss's wacked-out schedule, then it's his problem. If you don't complete it on your original schedule, then it's your problem.

And that's how we lay the blame :)


Stand up for your right to not believe: Americans United for Separation of Church and State
[ Parent ]

Doomed... (4.00 / 1) (#50)
by leifb on Mon Jan 07, 2002 at 10:11:36 AM EST

But I'm stuck with this project and quite desperate, because I can't just dump the project, I can't have any help and I'm too loyal to just to leave the company.

So instead, you put yourself in a position where one of two things happen:

1) the project is dropped, wasting all the time you spent on it

or 2) you get the resources you need. At last. And then you look at the work you did without motivation and realize that you could have done more, and better if you hadn't been nagged by doubt all along.

Either way, you've wasted your company's resources. (with loyalty like that, who needs corporate espionage...)

Do yourself, your manager and your company a favor: bulldog your way into the resources you need to not waste the project. Get more resources, get off the project, or get a different job. But make it clear to your supervisor and to his supervisor that what's happening isn't realistic, and will hurt your bottom line.

[ Parent ]

A business is not a sentient being (none / 0) (#120)
by inadeepsleep on Thu Jan 10, 2002 at 02:31:51 AM EST

It neither gives nor deserves to receive loyalty. Are there any people there who do? You make it sound like there aren't.

[ Parent ]
Theory and practice (4.00 / 2) (#47)
by ucblockhead on Mon Jan 07, 2002 at 09:46:58 AM EST

That's nice in theory, but in many companies I've worked at, it's the coder who gets made the scapegoat. This is especially true at non-software companies where management has no clue at all about software (because their company doesn't do that.)
This is k5. We're all tools - duxup
[ Parent ]
As I said (none / 0) (#49)
by codemonkey_uk on Mon Jan 07, 2002 at 10:05:24 AM EST

When not only does your boss not "get it", but *his* boss doesn't get it, then there is a problem, and its probably time to move on, as the company is doomed anyway.
"The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
[ Parent ]
Companies (5.00 / 2) (#52)
by ucblockhead on Mon Jan 07, 2002 at 10:40:59 AM EST

It depends a lot on the sort of company you work for. If you are working for a company that produces software, yeah, you are right, they are doomed. If you are working for a company that does something else entirely, then they are likely far more likely to fall in this pattern, and they are certainly not doomed. The company that inspired about half of this is still around, and their stock is rising though I did get the hell out of dodge, just in time. I'm sure I'd still be making great consulting fees if I'd stayed. The amusing thing about this is often these sorts of companies are goldmines for contractors because they get paid by the hour and everything takes five times as long.

Moving isn't always so easy, especially if you don't have much experience, or your skills are obsolete, or the economy sucks...the advice is still good, but it isn't always as easy to do as it is to say.
This is k5. We're all tools - duxup
[ Parent ]

You are not in deep shit. (5.00 / 9) (#38)
by localroger on Mon Jan 07, 2002 at 08:25:09 AM EST

I had this exact thing happen to me. Manager called me and asked how long X project, which we had already done the legwork to specify, would take to code. I said "three to six months, closer to six." End of phone call.

Two hours later, he calls back. "I had to tell X customer we'd have it in six weeks. What can you do for me?"

To which I replied, "Three to six months, closer to six, and are you insane?" The mangerial salesdroid whimpered and said we wouldn't have got the sale if he had said that. To which I said, then we shouldn't have gotten the sale.

Fortunately I knew the customer. I started work on the project. After about two months I got a call from the customer. "I'm calling you," he said, "because I figger you'll tell me the god-damned truth. When am I gonna get my program?"

"Well, truth is it will probably be another couple of months. It's really more complicated than the sales guys realized."

And the customer's answer? "All right, just keep me posted how it's going." It went in on schedule -- MY schedule, about five months after starting work -- and became one of the most successful projects my company ever did.

What you should do, as soon as possible, is open up a back channel to the customer which bypasses management -- preferably on both ends -- and float an accurate delivery date. Find out how the slippage will be received. It's likely that it will not actually be the end of the world, in which case you have no real problem. If it will be the end of the world, the time to take proactive measures is now -- not when the excrement hits the air-mover. This may have to include sending out resumes; if so, so be it.

Whatever you do, don't sit there like a deer in the road and wait to get hit by the truck, though.

I can haz blog!
[ Parent ]

Dangers of Back Channelling... (none / 0) (#93)
by Elkor on Tue Jan 08, 2002 at 12:58:45 PM EST

You are right on about opening a back channel to the customer to let them know what is "really going on," but it is also important to understand the risks.

If the managers is one of those people that ignored their underlings and makes up their own numbers distanced from reality, they may not appreciate the shattering of their dream world.

Specifically, we have a manager here who deliberately set himself up as a bottle neck in our design process so that he would always know what is/was going on. The designers weren't allowed to talk to the Engineers. Nor were they allowed to attend meetings. He felt that was his job. Never mind that he has no idea how long stuff actually takes using our CAD system...

I remember once overhearing this conversation:
Him: Why isn't this done yet?
Designer: Because it takes 2 weeks.
Him: It shouldn't take that long.
Designer: Well, how long should it take and how should I do it then?
Him: I don't know, but it shouldn't take that long.

And, if you do identify your boss as one of these types, float your resume out there anyway. Eventually you will either need it, or just want out badly enough.


"I won't tell you how to love God if you don't tell me how to love myself."
-Margo Eve
[ Parent ]
As a project manager... (none / 0) (#102)
by jayfoo2 on Tue Jan 08, 2002 at 07:07:34 PM EST

I'd ask you to please not do that. It makes me angry. I retaliate by revoking free donuts on thursdays.

Seriously though I'd say that the way you solved that problem was good for the situation (a client you had a very good relationship with) but isn't going to work too often.

1. Your client will not usually wan't to be hearing different things from different members of the team. That wierds them out. Wierded out clients fire their consultants.

2. Your project manager's job is to interface with the client and the salesfolks. If they are doing their job right they will not have put the team in an impossible situation becuase they will have reined in the salesperson. Even if the salesperson has managed to hand the team (and me as the PM) a pile of crap then I would suggest you let me work with the client. Telling the client things they don't want to hear is not fun, I get paid to do the not fun stuff. I'm also pretty good at explaining things like that to business people (you might be to, many/most programmers are not).

A situation like that is what the project manager is there for. If you don't have a good PM protecting you then you have a different issue.

[ Parent ]
Q: Background? (none / 0) (#110)
by Sunir on Tue Jan 08, 2002 at 11:48:07 PM EST

I have a semi-related question. What's your educational background? You can't be a programmer. Sane PMs are very rarely programmers.

"Look! You're free! Go, and be free!" and everyone hated it for that. --r
[ Parent ]

Unfortunatly true (none / 0) (#115)
by jayfoo2 on Wed Jan 09, 2002 at 04:41:08 PM EST

I have a business degree. I did however spend several years doing development before I started doing analyst and management stuff.

I mostly agree with you but I do know several excellent PM's who really were programmers. The key seems to be what you're interested in. The developers who become really good PM's tend to be people who eventually lose interest in coding. People who really like coding usually don't make good PM's because they would rather be coding.

[ Parent ]
Necessary vs. Wise (5.00 / 1) (#116)
by localroger on Wed Jan 09, 2002 at 08:27:51 PM EST

The reason I titled the comment "you are not in deep shit" is that it is the boss who floated the unrealistic delivery date who is in deep shit. It's true that there are deep corporate politics involved in doing this, and you need to have enough juice to make sure the blame wad goes where it belongs.

It sounds to me like in this case the poster is the entire project -- manager and all. If the guy who told the stupid lie (a stupid lie being one guaranteed to boomerang back to you) was the project manager, then he deserves to be upset because he created the problem.

I work in a small company where computers aren't the main focus, so I'm the entire department, and I've been the entire department since 8088's were state of the art. If I had not smoothed things over with the customer (who contacted me in this instance) it would have cost us about $100,000 on that sale and at least $300,000 in future business. I did what was necessary.

You can make a good case that this kind of thing isn't wise, particularly with regard to your own future, if you don't have the juice I've accumulated. But you have to look at a potentially bleak situation realistically. The situation as described must be defused. Consider:

  • The boss, whose job it is to handle the situation, has mis-handled it.
  • The customer is going to be disappointed.
  • The lie is likely to cost the company either the entire sale or significant grief in collection.
  • Someone will get blamed.
If you are the coder to whom this is done, your options are limited.

If you warn the customer, you may lose the sale; but you'll cut your company's losses because you would have lost the sale anyway, after spending God knows how much unrecoverable time on it.

If you warn the customer and negative consequences befall you, they would have befallen you anyway because you would undoubtably get blamed for not finishing the work "on time." If this is likely to happen float your resume; you'll end up doing it one day anyway.

In this case doing nothing just makes no sense. A manager who does this to you once will do it again. You will always get the blame, because shit runs downhill. You really have nothing to lose except a job that stinks by forcing your superiors to float sane delivery dates.

Before my customer called I also told the sales manager -- many times -- that if the customer called, I was going to tell him the truth, that there was no way the delivery would be made, etc. And sure enough, it was his failure to handle the situation (which I knew he couldn't handle anyway) that forced me to take action. I have a pretty good idea that the original commenter is in a very similar situation. He has probably asked the boss many times what will happen when the deadline approaches, and probably gotten answers like "work faster."

If you're the boss and you do stuff like that, you deserve to have your employees route around you, because you aren't doing your job. If you were, nobody would be considering things like this.

I can haz blog!
[ Parent ]

everything is situational (none / 0) (#118)
by jayfoo2 on Wed Jan 09, 2002 at 08:45:13 PM EST

I wasn't really commenting on your specific situation. In the case you present it sounds like you did exactly the right thing. Hopefully you followed rule #1 of corporate life and let people know you saved the day (rule #1 is look out for #1).

In general however, especially in project work, this kind of thing will kill you, once again unless you're the guy with the juice. The point I was trying to make is that most coders on project teams aren't that guy. The project manager hopefully is. Let him or her take the fire for you. It'll be better for you and better for the company/project in the long run.

[ Parent ]
hang the holy hell on (4.00 / 5) (#32)
by streetlawyer on Mon Jan 07, 2002 at 04:51:05 AM EST

I was with you until ...

You spend a week changing the colors

You're rumbled, my lad.

Just because things have been nonergodic so far, doesn't mean that they'll be nonergodic forever

A note to all K5 contributors (none / 0) (#90)
by ajf on Tue Jan 08, 2002 at 11:39:22 AM EST

When writing humorously, please try to avoid hyperbole.

Thank you.


"I have no idea if it is true or not, but given what you read on the Web, it seems to be a valid concern." -jjayson
[ Parent ]
Software analyst vs coder (3.50 / 2) (#43)
by wiredog on Mon Jan 07, 2002 at 09:07:44 AM EST

What you need is a software analyst/engineer to develop the specs. Or you can accept that you are the analyst yourself. By the way, you do realize that, given a sufficiently detailed spec, anyone who just knows the language syntax can write the code? The increase in skills, hopefully on the boss's nickel, only comes to the analysts. The actual coding can be left to interns and other such peons.

As an analyst I sit down with Management and the customer and decide what the system is supposed to do, how we want to do it, what components are involved in doing it, etc etc. This usually takes 100 hours, at least for an initial spec. If the problem domain is understood, that is, if I've done this, or something like it, before, I can determine how much work is required. Sometimes it's just changing the splash screen, and maybe a couple of menus.

Sometimes it isn't. A pure r&d project is (or can be) lots of fun, and very educational as you push your limits. But. One project we did, for a large disk drive manufacturer, got ugly. We took on a project that was beyond out level of competence, at least on the hardware front, and remained so. Eventually we told the customer that it wasn't do-able, at least by us, and that they should pull the plug. They did, and we were all, if not happy, at least satisfied with the result.

Peoples Front To Reunite Gondwanaland: "Stop the Laurasian Separatist Movement!"

Anal-ists vs. coders (none / 0) (#54)
by Salamander on Mon Jan 07, 2002 at 11:12:45 AM EST

What you need is a software analyst/engineer to develop the specs. Or you can accept that you are the analyst yourself. By the way, you do realize that, given a sufficiently detailed spec, anyone who just knows the language syntax can write the code?

Are you talking about requirements/functional specs, or design specs? Anybody who doesn't recognize a distinction between them isn't qualified to write either. If you're talking about the former, then your statement only reveals how little you know about how software actually gets built. Maybe for a GUI there's a fairly direct relationship between functionality and code, but not for many other kinds of code. Usually there are all sorts of details regarding algorithms and protocols and platform-specific details (e.g. which of several nearly-equivalent syncronization methods/primitives to use) that don't belong in a functional spec.

Analysts are supposed to be focused on the customer/user perspective, and nine out of ten aren't even qualified to make technical decisions (some people can wear multiple hats, but for the sake of clarity let's just assume that roles and people are equivalent). An analyst trying to do an architect's or coder's job by writing a spec down to the level where "interns and other peons" can do the rest is failing to do their own job, as your little story about botching a contract shows. Learn how to do your own job before you presume to sling insults at other professionals.

[ Parent ]
One mistake... (4.57 / 7) (#44)
by mcherm on Mon Jan 07, 2002 at 09:18:11 AM EST

Well, I'd say this was an extrordinarily accurate description of how it "really works". Except for one part. That last line "Thanks, though, here's your check!" is not the way I usually hear it. It's more like this:

Client: ...Thanks though, we've submitted your bill to accounts payable.

Three weeks pass.

You: Um... About my bill...
Client: ...what specification? I don't know what you're talking about. [CLICK] Oh hi. Sorry, I was on the other line. What were you saying?
You: I was asking about my bill.
Client: Oh yes. Sorry. I just submitted that to accounts payable.
You: I thought you'd submitted it three weeks ago!
Client: No... Just submitted it yesterday.
You: (Incredulously) Yesterday... are you SURE.
Client: Yes. Say... how much was that for, anyhow?
You: Well, it was a total of 1,800 hours at $80/hour so that comes to $144,000. Now, you're SURE you submitted this?
Client: What! That's crazy. It was only supposed to be $80,000. [sound of papers shuffling] I have the quote right here!
You: Yes, well that was the initial estimate, but the requirements changed significantly.
Client: I suppose they did, but I only had $80,000 budgeted.
You: and...?
Client: So I think I should just pay the $80,000. After all, an 80% cost overrun is WAY out of line.
You: [Screaming!] That $80,000 was for A PROGRAM THAT JUST ANALYSIZED *WIDGETS*!!! The FINAL program did *GISMOS*! And it wouldn't have COST so much if you had JUST TOLD US WHAT YOU WANTED FROM THE *BEGINNING*!!
Client: This is no way to maintain good relationships with your clients. [click]

Three weeks later.

You: [again] Yes, I'm vey sorry that I lost my temper. Now, can we discuss this bill again?
Client: Ok. How about if we split the difference? I'll pay $112,000 to settle the bill.
You: [despondently] All right. I guess that'll do.
Client: Great. I'm submitting it to accounts payable right now.

A month passes. You call accounts payable.

You: It's bill number 146738 from Software Analysizers dot com. The total should be for $112,000.
Accounts Payable: Ah yes, I have it right here. No, I'm sorry: we can't begin processing it until the manager submits us the paperwork.

I realize that this sounds a bit jaded, but it has all happened to me (and worse) except for the loss of temper. So fault me on attitude, but don't fault me on realism. And no... suing them is not an option.

-- Michael Chermside

don't do independent contracting ... (3.00 / 2) (#64)
by karb on Mon Jan 07, 2002 at 02:13:42 PM EST

Why isn't suing an option?
Who is the geek who would risk his neck for his brother geek?
[ Parent ]
Suing (none / 0) (#124)
by Fred_A on Wed Jan 23, 2002 at 02:27:11 PM EST

Why isn't suing an option?

Because you'd end up suing all of your clients ?

Fred in Paris
[ Parent ]

Embrace change, don't fight it. (3.33 / 3) (#45)
by svanegmond on Mon Jan 07, 2002 at 09:19:03 AM EST

A lot of the techniques that have been suggested - putting signature fields on every document, change-control boards, gigantic specifications - are all designed to fight the fact that people genuinely don't know what they want software to do.

People everywhere are much better at reacting to a system when it's presented to them, rather than when it's presented abstractly in a 3-ring, 200-page binder.

The "how they said it would be" is pure software-engineering fiction. I know it, I've taken the course in University. Based on experience, it only works this way at NASA and the military, and even then I'm not so sure.

I borrowed the subject line from one of the first books ever to come out about XP ("Extreme Programming Explained: Embrace Change"). XP is a recent technique that acknowledges entropy as a fact of life in software development, and retools the development process to take advantage of it.

I'll explain a few key practices. These are not complete. I'm going to leave out some of the more iffy ones such as pair programming:

No big design up front
This is the biggest one, and if you can't do this, possibly due to management paranoia, XP is probably sunk for you. The general idea is that you design stuff when you need it, and not before. This is because you know that the requirements are going to change, and that thing you were sure you were gonna need... you're not gonna need, wasting precious coding time.
Use unit tests, and write them first
Being able to run unit tests means a few things: 1) they should be easy to run - type the "run the unit tests" command, and off they go. 2) they should always be at 100% especially in the repository - otherwise someone has work to do.

"Write them first" means that before writing a feature or fixing a bug, write the tests first that reveal the bug or exercise the feature, then make the unit test pass.

Use refactoring
Refactoring means restructuring code so that it does the same thing, but is structured differently. There's a book out on refactoring that is to the field what Design Patterns is to design. There's a core catalogue of several dozen code transformations that happen during refactoring, and it's easy to get to the point where lots of them are (mentally) automatic instead of a challenge.
Refactoring + no big design up front + unit testing is what lets you move quickly in XP. It avoids legacy build-up, and it avoids you writing code that the customer won't ultimately use.

XP has a few other practices - such as 2-week iterations where you show the product to the customer every 2 weeks instead of right at the end. Scary idea, eh? "But they might change their mind!" They're going to change their mind anyway, so let them do it early when it costs less.

It sounds like a lot of people here would benefit from XP.
-- Steve van Egmond · http://svan.ca/

Close... (none / 0) (#60)
by Sunir on Mon Jan 07, 2002 at 12:35:47 PM EST

Actually, all the practices of XP combined, especially the iffy ones (like pair programming), allow you to go fast. I don't know how you think you can refactor quickly or write unit tests effectively without a pair partner, or how you avoid creating an information bottleneck when only one person knows how the widget analyzer works and he decided to move to another city to be closer with his girlfriend.

"Look! You're free! Go, and be free!" and everyone hated it for that. --r
[ Parent ]

No -- Without scoping the project you will fail (2.00 / 1) (#78)
by Shimmer on Mon Jan 07, 2002 at 11:55:24 PM EST

So what do you recommend, just sit down and start coding? I don't think so, pal.

The "wing it" approach might work great on a sleepy one or two-person project, but on a project where someone is making a real investment (e.g. in people, $$$, and time), no one in their right mind would do this.

For one thing, you have no way of knowing when you're done. You're just begging for scope creep, feature bloat, etc.

-- Brian

Wizard needs food badly.
[ Parent ]
Um, dude... (none / 0) (#80)
by Sunir on Tue Jan 08, 2002 at 01:43:45 AM EST

Did you read his comment? He referred to a specific book with specific practices with much text written already. If you're poor, start here.

Christ, I am turning into an XP lemming.

"Look! You're free! Go, and be free!" and everyone hated it for that. --r
[ Parent ]

Gawrsh! It must be true if I read it in a book. (none / 0) (#83)
by Shimmer on Tue Jan 08, 2002 at 09:23:08 AM EST

Nothing against the XP folks, but their "methodology" is a great example of solving the wrong problem.

-- Brian

Wizard needs food badly.
[ Parent ]
Books good (none / 0) (#86)
by silent communication on Tue Jan 08, 2002 at 10:21:41 AM EST

I can see slamming a very hyped methodology. But they're honest -- it's for small projects.

Íf you read the book "Fall and Decline of the American Programmer," you'd notice the XP pushers are playing an old game. But they're at least as honest as possible; and they likely wouldn't do any good to anyone if they didn't play the game.

[ Parent ]
How small? (none / 0) (#96)
by greenrd on Tue Jan 08, 2002 at 03:46:17 PM EST

How small is small? How many lines of code approx? Because even on this "small" project I'm working on here, I'm pretty sure that exhaustive unit testing would waste more time than it saves - and would involve unnecessarily large, redundant, and boring scaffolding (e.g. getting the system, or some kind of mock-up of the system [ugh!], to a state where a certain method call even makes sense).

Also, I'm told that good XP programmers learn what not to bother testing (e.g. one-line get or set methods). But surely a lot of bugs happen where you least expect them?

"Capitalism is the absurd belief that the worst of men, for the worst of reasons, will somehow work for the benefit of us all." -- John Maynard Keynes
[ Parent ]

Testing (none / 0) (#107)
by silent communication on Tue Jan 08, 2002 at 10:47:48 PM EST

Hmm, do you think that Design by Contract is bad?

It is always up to you to make intelligent decisions. But with even small programs, I test them. Often in main(), so I don't have to constantly type. I don't understand why people talk in terms of 'scaffolding'; unit tests are only a way to save time. Presumably that's more important than catching defects, since you'll test anyway. Unit tests are just a way to do that more efficiently.

So if you judge that it's not worth it, who will tell you otherwise?

[ Parent ]
Bounding (none / 0) (#108)
by Sunir on Tue Jan 08, 2002 at 10:49:17 PM EST

XP unit tests are meant to guarantee success. To do this, they insist you test every function point you can think of (by test-first programming). In this way, the system will have a high coverage of test automatically.

If you code first, then test, not nearly as many tests are written and the system has more defects. Worse, because coverage is low, refactoring is harder. You may break something inadvertently if there was no test to tell you it's broken. Indeed, since once you get into the rhythm of testing and refactoring, you just run the tests to verify your changes are correct, you can be screwed if the tests only partially cover the system. You may make a mistake under the illusion that the tests were enough. The alternative is the painstakingly slow process of reevaluating the codebase every time you want to change something.

On the other hand, those who know what they are doing (--or for those who think they know what they are doing--) can cheat with the unit tests by recognizing the system is an onion. Each layer verifies the layer beneath to some degree of proficiency. The optimal coverage is not likely to be XP's coverage, but some lesser amount that prevents enough bugs that will maximize profit given the expenditure of resources to detect, fix, and maintain the defects, blah, blah, blah. This is the same accounting that leads us to peg the total cost of lawsuits resulting from airplane crashes against the cost of jetfuel. Except you're likely to screw it up. Think of "extreme unit testing" (as they call it) as the worst case bound.

Unit testing saves money in the long term. In the short term, it may be more expensive. It's your call, but it's a very difficult one to prove correct.

"Look! You're free! Go, and be free!" and everyone hated it for that. --r
[ Parent ]

And the right problem is? (nt) (none / 0) (#109)
by Sunir on Tue Jan 08, 2002 at 10:53:51 PM EST

"Look! You're free! Go, and be free!" and everyone hated it for that. --r
[ Parent ]

Do you even know what you're talking about? (none / 0) (#98)
by svanegmond on Tue Jan 08, 2002 at 04:29:19 PM EST

I gave an overview of XP. If I wanted to be thorough, I'd paste in the text to k5. But I don't, so I referred to a decent book that explains it.

Of course you don't sit down and just start typing. XP has a detailed, specific, planning phase. The window of planning goes forward 2 weeks to a month, whereupon you

  1. Compare your estimates to reality and adjust your multipliers.
  2. Show your work - this demonstrates progress to the team and to the clients and is a huge morale booster.
  3. Adjust your course.
  4. Plan the next few weeks.
Repeat until you run out of money or the client says it's good enough.
-- Steve van Egmond · http://svan.ca/
[ Parent ]
Things like this . . . (3.00 / 2) (#46)
by hardburn on Mon Jan 07, 2002 at 09:40:26 AM EST

. . . are why I decided to go the system/network admin route instead of programming. OK, so maybe administration isn't that much better, but I don't think my kind of programming is well liked in the buisness world. I'm not one to jump on the latest buzzwords (I don't know much XML or C# or .NET or any of that). I have a lot of skills in the area, but I don't have a lot of skills that will get me a job. I like programming either at the extreme low level (ASM) or extreme high level (perl scripts, Java). So I'll probably end up doing networking and adminstration to keep food on the table and do programming as a hobby.

while($story = K5::Story->new()) { $story->vote(-1) if($story->section() == $POLITICS); }

Programming is better for one reason. (none / 0) (#72)
by theboz on Mon Jan 07, 2002 at 07:44:17 PM EST

In most serious organizations, once you get past the QA stage of development, you are no longer responsible for bugs in your software. Sure, you would have to fix it eventually if a bug is caught, but you are not on call to be paged to make a patch at 3am normally. With system administration, you can be on call 24/7 and because you deal with production issues, you have a lot more contact with irate users. Programmers just have to deal with stupid users who are occasionally irate.

The best goal for you is to end up the sysadmin of a different environment, like if the QA group has a computer lab, that way you get the best of both worlds.

[ Parent ]

Yup (none / 0) (#73)
by ucblockhead on Mon Jan 07, 2002 at 07:51:31 PM EST

This is very, very true. Programmers may sometimes have to pull long hours, but they are much less likely to carry pagers or be "on call".

The bad news is that when programmers talk to users, it is often because the first and second levels of support couldn't help them, so they are often very irate.

This is k5. We're all tools - duxup
[ Parent ]

When I was working... (none / 0) (#94)
by theboz on Tue Jan 08, 2002 at 01:13:34 PM EST

I would say that whenever a user called me with a problem, I would direct them towards my project manager. You have to find a way to make a process so the users have to follow it to get help, and not bother you when you are doing something else. The way things turned out for me is often either the user asked a coworker and figured it out, or it turned out to be a bug, upon which I was given a project to fix it and it had to go through the project manager anyway. Over time, users learned not to call me about that sort of thing, and everything became more efficient for all parties involved.

[ Parent ]

They exist (4.00 / 2) (#48)
by CaptainZapp on Mon Jan 07, 2002 at 09:57:02 AM EST

Actually I worked on 1 (one) project, that was specified very, very accurately and actually the final implementation lived up to the specs.

For the company (20 employees up to 40 contractors on the project) it was a make or break deal, since the contract precisely specified amount of transactions per day, maximum response times, etc.

What they did was setting up a specification infrastructure based on an OO tool, which they customized for their needs. The whole infrastructure was geared to the language of choice (ADA). This wasn't some "case tool" which just prodcued badly formatted, incomprehensible reports, but more like a framework which really (due to lack of a better word) kicked ass.

It's sad, that this is the only major database centric project I've ever worked on where they actually bothered to test each and every critical query. That means, they didn't only generate the data volume (but when we tested with 30 accounts performance was pretty good), but also made sure that critical elements where appropriately skewed.

Testing could have been better and more thorough, but in the end they got it in in time and in budget, thanks to the specs and to some very smart people working on that project.

Now for the real world: Your scenario is dead on, with exception of the clients e-mail, which seams a bit detailed for average specs :).

What tool? (none / 0) (#74)
by Bwah on Mon Jan 07, 2002 at 10:16:19 PM EST

Just curious ...

To redesign an infinite ensemble of universes: what terrible responsibility, what arrogance ... It sounds just like the type of thing your average Homo sap would do for a dare. -- Stephen Baxter
[ Parent ]

If they don't read it, read it to them (2.50 / 2) (#65)
by svampa on Mon Jan 07, 2002 at 03:17:00 PM EST

Tell your customer,
"Spec are finished, could we meet next wendsday at 16:00h to talk about it?"

Explain a sumary of spec to him, the most important, and the things are more interesting for him (good points or silly things).

Problably during the analisis the customer has pointed some stupid things, it's on you to try make him change his mind or accept them. But in this moment things must be like customer wants, there shouldn't be important objections, even if the customer don't read it.

"That's all, here is the detailed spec, if there is no objections we'll begin next week. Good afternoon"

Now you have a written spec to stand if customer asks you some silly changes during implementation. The project won't delay because of changes, and finally the customer will be satisfied, in despite he has complained during implementation

A Clue (5.00 / 7) (#67)
by Simon Kinahan on Mon Jan 07, 2002 at 04:31:35 PM EST

You don't make it clear what your working environment is. Are you an independent consultant, a contractor, a bespoke developer, or part of a company that does one of the above ?

Here's the clue: Users do not have the imaginative abilities, the conception of what is feasible, or the understanding of their own working habits and systems to be able to specify software in any detail by themselves. And here's the important part: it is not their job. Its part of the task they want you or your organisation to undertake, and *you* have failed to do a decent job for them. Its not even the users job to realise the above. That is *your* job too.

The position you are taking is like a doctor who asks the patient to describe their condition in precise technical terms, and when they are unable to do so, hands over some antibiotics, says "I hope those help", and feels hard done by when the patient stops taking them because they didn't.

As several other people have said, there are various ways to get to a more refined specification. One is up-front analysis: people with customer facing skills, some technical knowledge, and preferably and understanding of the client's industry go and interview *everybody* concerned with the new system. Users, their managers, the IT guys, everyone, and finds out what they want. You now have ammunition against the guy who wants it in magenta and cyan - noone else does. Your analysts also now understand the business well enough to write a reasonable spec. Depending on your brief, they will also make changes to the client's business processes to fit the new software in.

Another approach is iteration: you deliver a *very* minimal system and get them to use it to whatever extent is practical. You add functionality in small chunks and keep the client up-to-date. They role the system out gradually. When that guys asks for it in puce, you do it, then when everyone else yells, you take it out.

Here's a further clue: its not your fault. What you were taught at school ought to be a sacking offence for that teacher. Similarly, if you are independent, the fact anyone hires you or those like you - and there are plenty - is just another one of my ever growing list of damning inditements of our industry. Again, similarly, if you have an employer, *quit*. There are sane shops out there, and you *really* need to learn how to do things.


If you disagree, post, don't moderate
Humor (5.00 / 9) (#71)
by ucblockhead on Mon Jan 07, 2002 at 07:01:59 PM EST

This wasn't meant to be taken seriously. Neither was it meant to be a serious attempt at describing what "should be". Rather, it was a reaction to another story that implicitly assumed the first "case study" above as the state of things, and predicated a business model on it. It started as a comment there and grew of its own accord.

It was not a "true story" in any literal sense, and that is why the situation (employment, contractor, etc.) is deliberately left vague. Rather, it is an amalgam of all sorts of different things that have happened to me in my career. In other words, every bit is true, just not all together. (In fact, the biggest struggle I had was keeping the length down. I could have easily doubled the size with more anecdotes.) Some of these things happened to me as a contractor, some as a project manager, others as a peon employee. The "Client" was sometimes a client, sometimes my company's customer, sometimes my boss, etc, etc, etc.

In real world terms, the person who wanted cyan and magenta was a boss's boss's boss whose word was law. The fact that most target users of the software didn't care about the color meant squat, as they were $5/hr entry level employees. A pesky real world situation. And also one that gets missed. In many, if not most cases, the "user" is not the person who pays you and tells you what to do.

Best I could do was spend a week making the colors user configurable rather than a half day just changing the colors. Unfortunately, the stupid VP got her way and those hideous colors are likely still there to this day.

But anyway, yeah, I agree with you and all those who talk about analysis and changing specifications, etc. In the sense that this story has a serious side, it is a reducto ad absurdum argument for exactly that sort of thing.

Most of these bits had happy, or at least, marginally happy endings. The colors, I gritted my teeth and changed. I was a contractor then, and got paid regardless, so that color change lined my pocket. Still galling, of course, but hey... Other parts came explicitly out of badgering people for suggestions, signoffs on decisions I'd made, etc, etc.

But the thing I think a lot of people are missing is that analysis is not something that can be done independent of the client, be they the customer, the boss, whatever. You can do all the analysis you want, but if you are not the one with authority to make decisions, then you do not have control over the process. If the person that does have control is a micro-manager, or is impossible to reach, or is technologically clueless and determined not to show it, then you get the sorts of things I've described, regardless of how well you analyse the problem, and how much time you spend with the actual users. In other words, lots of people end up experiencing these things not because they don't know any better, but because life threw them into a crappy situation. And "find new employment" is an easy thing to say, but not always an easy thing to do, speaking as someone who did eventually quit those places, and found a more sane one.

This is k5. We're all tools - duxup
[ Parent ]

Meetinf, Meetings, Meetings (5.00 / 1) (#85)
by craigtubby on Tue Jan 08, 2002 at 09:44:58 AM EST

First Meeting
Me : What do you want
Them : We want This, That and the Other
Me: What about Those and Them
Them : No, we won't use them, and we will have to change our practices
Me: Ok

2nd Meeting
Me : Okay This, That and the Other is done
Them : We also want More
Me : Are you sure? Why don't you do Those instead, it would be easier on you.
Them : No, definately More

3rd Meeting
Me: Okay, More is completed and we should be ready to role.
Them : We don't like That and The Other, we want those changed.
Me: You realise thsi will cause a major slippage?
Them : Yes, but we want it done.

4th Meeting
Me : Morning, well we have finished now.
Them : Great, we bought a User along to test it
Me : Great a bit of training
User : Errr, Do I have to do anything
Me : Yes, do this, this and that
User : Whoa, I'm not doing that it means I have to do my work twice, once as normal and once in the new system.
Me : The new system produces the same as the old so you will only have to use the new system.
User : No, it won't work.
User tries system.
User : It would have been better if you had done Those and get rid of More, it useless for what we do.

Telephone 1
Them : Hi, are we supposed to get back to you, or were you getting back to us.
Me : You were supposed to contact me.
Them : Ah, okay - meeting next week at 10am. We have also decided to go with Them, so if you could get that sorted when we next meet.
Me : Won't you have to change working practices?
Them : Yes, but we changed them at the end of last year, so it should be okay now. Oh also remove This as we don't do it any more.
Me : Err, no that won't be done by next week.
Them : Never mind leave it in then for the moment. We have also been looking at Doing, which looks good, we will discuss it in the meeting.


try to make ends meet, you're a slave to money, then you die.

* Webpage *

A few uneducated comments. (none / 0) (#88)
by Alarmist on Tue Jan 08, 2002 at 11:17:34 AM EST

In my vastly limited experience, most problems in software production stem directly from poor scheduling. This comes from several directions, but a lot of it comes from unreasonable expectations on the client's part or overeagerness to sell the product on the sales team's part.

Two other major factors are feature creep and scope change. Feature creep is to be expected as the client develops more ideas about what might be possible. Scope change is the result mainly of organizational and operational changes on the client's side that obsolete parts (or all, in really bad cases) of the project.

We can't do a lot about unreasonable expectations, other than to make an effort at educating clients about how much effort things take. More on this in a moment. Overeager salespeople can be dealt with by using a fire hose or similar instrument.

The bigger problems - feature creep and scope change - can be dealt with by using a certain amount of firmness. Tell the client at the first meeting and every subsequent one that feature creep is expected but must be paid for. Use hard figures - x cash per developer-hour spent on a feature that was not in the original specification. Underline the fact that feature creep equals schedule slippage and make sure that the customer is aware of this. Get it in writing. Signed, in triplicate, if possible.

Honesty really is the best policy. If the scope has changed so radically that the original request bears almost no resemblance to the expected product and if the schedule has already slipped dramatically, tell the client that it might be time to consider specifying a different product based on the new scope. Hell, tell them before matters get out of hand. Don't be afraid to say no.

Bill them, bill them everything! (none / 0) (#125)
by Fred_A on Wed Jan 23, 2002 at 03:33:37 PM EST

Having the client pay for changes to the specification isn't the half of it.

In my case when I have a customer that doesn't provide me with a full specifivation (99.99999% of my customers), I start with billing the time to create the specification (which represents a *lot* of work in most cases, with endless meetings, numerous drafts, and so on).

After that, the specification is included into a new contract which the client signs. The contract mentions that the attached specification is final and that changes to it will imply a repetition of the entire above procedure (with associated billing).

This is the only way I've found to avoid the insane (but so realistic) situation described by the original poster.

This method has drawbacks though. I do loose business because some clients don't accept having to pay for the design of the original specification (even though it can take me over a week to get a decent draft). However I figure that I make up for this by loosing a lot less time.

Fred in Paris
[ Parent ]

I love the recent web versions of this story (4.33 / 3) (#92)
by easilyodd on Tue Jan 08, 2002 at 12:14:28 PM EST

Me: I'm the web developer, where is your content?
Them: Content? I thought that is what you did.
Me: I only make it work on the web, you need to give me what I put on the web.
Them: So what does that mean.
Me: You give me words and I make them work on the web.
Them: I thought MS Word does that? Well, we want you to create a new logo.
Me: I'm not the graphics guy, I just code pages.
Them: Don't worry about that, we'll use Word or this evaluation of front page that has been sitting around. I would like the logo to be cool and also make it move.
Me: *sigh* Can we stick to the content for now?

hmm so what about the spec? (none / 0) (#123)
by pnoeric on Thu Jan 17, 2002 at 03:00:44 PM EST

along this lines-- can someone point me to a good example of a great software spec, helping avoid "situations" like these?
-- ericmueller.org
Software specifications: Theory and Practice | 125 comments (117 topical, 8 editorial, 0 hidden)
Display: Sort:


All trademarks and copyrights on this page are owned by their respective companies. The Rest © 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!