So I was reviewing a design earlier for a reporting project for something that really boils down to glorified turnaround time tracking.  Currently we don't capture all the time points needed, so the project entails capturing additional data and then summarizing it.  Straightforward enough, really, it's just capturing some time points, taking the differences, and calculating a handful of statistics.  I was reviewing the design:

 * Known Problems: This design cannot account for [condition X].  In this case they can use [workaround Y].

In calling a few customers and chatting, I confirmed my suspicions:

A) [Condition X] occurs about 95% of the time.

B) [Workaround Y] adds significant extra work to record the data.

C) Use of [workaround Y] screws up the initial time point, which makes most statistics (including both of the metrics that were the raison d'etre for this project) completely meaningless.

Who wouldn't love this feature?  19 times out of 20, they get to do extra work, and they generate useless metrics to boot. On the plus side, their meaningless data is presented in a very attractive report.

Hey, at least you caught it at the review stage. TRWTF will occur when the design is implemented as-is, regardless of your review.

flabdablet:

Hey, at least you caught it at the review stage.

 

+1 ... that's the purpose of a review, to catch this stuff out, before it goes into prod--

flabdablet:

TRWTF will occur when the design is implemented as-is, regardless of your review.

-- I really, really hope this isn't the case... but pessamistically I feel the response to your review is "but we've already built it now".

I'm guessing a minor WTF is that these conditions weren't considered during the initial design.  Most design theory I've taught focusses upon clarifying the "happy path" (intended default flow) then examining all potential deviations from this path.

Ignoring path forks at the design stage means untrapped expections, poor error-handling, exploitable systems - or worse still, the coder deciding to include inappropriate checks.

Cat:

A) [Condition X] occurs about 95% of the time.

How the minified fuck could design miss this? Did BAs carefully select clients from the remaining 5% to capture requirements?

 

Cassidy:

flabdablet:

TRWTF will occur when the design is implemented as-is, regardless of your review.

-- I really, really hope this isn't the case... but pessamistically I feel the response to your review is "but we've already built it now".

As a new embedded systems software development hire, I was once tasked with doing a design review on a microcontroller-based piece of test gear that one of the old hardware guys had designed. This was well before it went into production, and I found several important ways in which it failed to comply with the customer spec.

I then got the job of redesigning it. My design was elegant and tidy and complied much better with the written spec, but it relied on a custom component that was damn near unmanufacturable, and its test results once eventually built and field-deployed were so different from those obtained using older equipment (most of whose designs strongly resembled the one that my review had found non-compliant) as to make it almost useless to the technicians using it.

Needless to say, I learned a lot.

Cassidy:

How the minified fuck could design miss this? Did BAs carefully select clients from the remaining 5% to capture requirements?

Clients? You want to talk to clients? No, the Marketing department knows everything about our clients. You only need to talk to Marketing and they will give you the entire specification verbally. *tag

It was Marketing that came up with the beautiful idea of the splash page on the website. The know that every one of our clients wants to see our CEO tell them how great the company is every single time they visit our website.

Qwerty:

Clients? You want to talk to clients?

 

I do on a regular basis. Some are wonderful - they sit back and allow themselves to be guides through the process. Others are complete twunts that ought to pick up my dental bills when I keep clenching my jaw tightly enough to prevent anything undiplomatic escaping my lips[1]. Occasionally if someone else does the job, I'm not too put out.

Qwerty:

You only need to talk to Marketing and they will give you the entire specification verbally. *tag

They can try, but I expect Marketing will write up and deliver the specification so I have traceability between requirements and deliverables. Even if Marketing won't write them up, I'll waste their time capturing all the specs from them and making them review then sign off on what I have (and when I ask plenty of questions for which they have no answers then they'll need to go back to the client for clarification).

I don't work to chinese whispers: I work to cold, hard facts. It's documented, reviewed, agreed and signed. None of this "thought they said" shit.

Qwerty:

It was Marketing that came up with the beautiful idea of the splash page on the website.

Who came up with the idea ain't important; whether or not it's in the requirements is. If you expend effort on something decided by Marketing and the client refuses to pay extra for something unrequested, you have a document detailing it as part of the specifications. Let Marketing explain to the client how the specs became tainted between capture and implementation.

[1] yeah, I know I'm setting myself up for comedy value here. Start your engines.

Cassidy:

clenching my jaw tightly enough to prevent anything undiplomatic escaping my lips[1].

 

Cassidy:

[1] yeah, I know I'm setting myself up for comedy value here. Start your engines.

Hehehe-- engines. You perv.

 

Lorne Kates:

Hehehe-- engines. You perv.

 

I prefer the term "auto-erotica". 

Cassidy:

Lorne Kates:

Hehehe-- engines. You perv.

 

I prefer the term "auto-erotica". 

 

Your post is better than my post.