Writing detailed Statements of Work and negotiating changes over collaborating to do our collective best with the time and money at hand

Driving toward the original project plan over accommodating the client changing their mind, or a path turning into a dead end

To elaborate:

We prefer to focus on building software with lock-step process and tools — and reduce our need to worry about quality individuals and having conversations amongst developers or with the client.

that way we don’t need to worry about people issues and effective communication.

That way we can hire any individual regardless of skill, and forgo all verbal/personal interactions in favor of solely written words. Even better if those written words are automatically transformed into code. Maybe we can get non-coder tools! After all, people are merely fungible assets/resources, and software is factory-work — with processes and tools, and a horde of low-paid serfs, we can crank it out!

We prefer to spend a lot of time up-front ensuring we have the requirements and design specs fully determined — rather than have tangible, working results early on.

Even our Use Cases follow a mandatory 3-level deep path, with proper exception and alternate paths worked out.

We link the requirements items into detailed design documents — which include system design diagrams, interface specifications, and detailed object models.

If we don’t write it all down now, we’re likely to forget what we wanted. And if we don’t do it to the n-th degree, the developers might screw it up.

Writing it all down up front allows us to go on vacation while the process and tools “write” the code from the detailed specs/diagrams. Sweet.

In addition, we love to be rewarded by reaching meaningless intermediate deadlines that we place on our 1500-node Gantt chart.

When we combine all of the upfront work with important deadlines, many of the senior managers can get promoted due to their great commitment to generating reams of cool-looking documents. By the time the sh!t hits the fan when folks realize the “ship it” deadline is missed, the senior managers are no longer involved.

Besides, if we actually built software instead of writing all sorts of documents thinking about building software, our little ruse would be exposed!

We prefer to work under rigid Statements of Work — rather than actually work towards a “best-fit” solution given changing conditions of understanding and needs.

The agreement is based on the 400-page, fully-specified requirements document, and we pad the cost estimate with a 400% profit margin.

We then hire dozens of people to argue during the Change Control Review Board monthly meetings about re-writing code to deliver what you wanted versus what you asked for when you thought you knew what you wanted (and wrote it down in that 400-page doc that was signed off by 6 execs).

Contract negotiation pissing matches are such great uses of our collective resources and always result in perfect software! We love our fine print 🙂

With a 400% padding, the projects are too big to fail.

Once we are in it for 1 or 2 million and 50% done and 2x schedule overrun, who would ever say “No” to a contract extension? Who better to get you to the goal line than the same folks who squandered away your treasure, pissed away the calendar, and delivered no working software yet?

We like to appear like we’re just about done… Asymptote? Never heard of one.

We prefer to be driven by our initial plan — rather than dealing with change and having to re-print the Gantt.

Especially a Gantt chart that has been built with tender loving care to include resource allocations, inter-project dependencies, and partial resource allocation assignments for matrix-style organizations.

We love hiring a small army to ensure that we drive the entire team to meet every micro-task deadline even when they no longer make any sense.

The real fun is collecting the “actuals” data from the developers assigned to each task so we can compare it to their estimated hours.

And nothing sweeter than seeing 90% of our tasks being started, and 75% of those being 67% resolved; and 25% of the resolved actually being complete — the roll-up summary to management is such a compelling story of success.

Changing such a beautiful plan that took 4 man-years to develop, that incorporates all of the comprehensive non-code documents, and is an appendix in the contract, is no small feat!

Better to produce the software according to plan even if nobody wants it that way. That’s our motto, and we’re not going to change!

We love the illusion of activity over the truth of delivered features.

In 2009 I like to think I can cook pretty well when I put my mind to it — I began cooking in the late 70s under a chef’s tutelage… Cooking has some parallels to software development. (I think… I just made this up and it sounded good, so I am going to run with it for a bit.)

You can be very prescriptive and follow recipes to the “T” — like waterfall. Not a bad approach when you are learning (and in cooking — unlike in software — it can’t last more than a couple of days). However, always following the recipe yields no creativity.

So, as you master your craft (cooking or software) by following some prescriptive processes to get a taste of quick success, you are hopefully gleaning the underlying aspects of the trade. You can also work alongside a master chef to learn tricks and tips and sage advice. If you do a good job of learning the art and science of cooking, if you begin to understand the basics, you can then start to follow a more agile approach to cooking. The more you practice, the more you understand the inter-dependencies between food elements (or code). Doing a little sampling along the way (frequent builds, testing) helps ensure you are on the right track. If you decide to get fancy, sometimes you have to make throw-away (edible) prototypes so that your final presentation is the one you present to your guests.

I hope I never cooked (or coded) anything like what follows in the URL below. This link is a real hoot (and the real reason for this post). I almost wet my pants:

I think this is a reminder to be certain you never, ever, code when you are on “date expired” acid from the late 60’s. You might code the “Frankfurter Spectacular” or the “Fluffy Mackerel” and expect admiring glances from your peers at the next scrum.

How could Weight Watchers have possibly published these recipes and photos thinking they were remotely “good” at helping you watch your weight? I guess the same way some lousy code gets written — because it seemed good at the time!

Oh, wait, it just dawned on me! After seeing these dishes appear at your place at the table, who would ever want to eat again? Even the celery log looks like a piece of compost. So this served as a great appetite suppressant I bet!

Oh, as I was wracking my brain trying to comprehend how someone — even in the 70s — could consider these recipes worthy of publishing and photographing, I recall my own childhood. At some point in the late 60s, early 70s, my Mom decided to make Cod Fish Balls. I kid you not. Breaded I think. And deep fat fried I think. Probably in Crisco. Too bad I don’t have an old photo of them to add to the Fluffy Mackerel Flickr collection!

While on a business trip overseas last week I had an in-promptu meeting with a potential customer during which I explained to them the benefits of Agile. As result the excutives[sic] asked me to send them more info and a proposal. Upon my return to the USA I did so and got a reply from them this morning indicating that they are currently using the “Fast Track” approach to software development. That term is entirely new to me in the context of sw dev.

Before I reply to them with the big question mark, and potentially sounding stupid, I wanted to check if any of you know about it and if so I will highly appreciate a pointer to more information.

Hi,

I think it is some project management software…

So… might be a bad sign.

You: “We specialize in agile development and find it really helps meet business needs… What type of s/w development processes do you use?”

Potential Client: “Oh, we use The Microsoft Project SDLC Process.”

You: “Oh, I feel my phone buzzing, I gotta take this call. It might be my ‘Management By Magazine’ book editor.”

A recent email underscores why written specs are never sufficient to communicate complete details. (Now, throw in that both parties are not communicating in their native languages…)

Fair work, help for people

Good time of day. You are disturbed by the charitable company Redd Cross of Slovenia. We have the business offer for you. We can offer to you of earnings, thus your salary will make from 1000$ to 2000$ per one month, at an incomplete working day. Your earnings can be and higher. The more and forces you will give time, the there will be your salary more. If it is interesting to you, you write on the address of e-mail of our agent: agentcristilman@gmail.com he will contact you within 24 hours and will throw off to you all details, and will answer you on all your questions.

There we were… 20 minutes to a 1pm demo. All was set the night before… some “safe” last-minute changes requested by the business analyst (Marc — in NJ).

scrambling to figure out why we suddenly couldn’t get [insurance thingy] RQAs to open, or to rate when they worked an hour ago. i (in PA) make some DB changes, cross fingers, try to open an RQA to test

and much else followed that i can’t print (*I* only said ‘crap’ on IRC!)

13:00 marc and harry start demo presentation in New Jersey…

at 13:03 I realized smth was up with Questionnairre #3’s meta data

i point some of the sql scripts that mark wrote long ago to help ensure qstnrs were properly formed…

bang, an errant condition for one of the rules! darn!

13:11 somehow, the choice that the condition was looking for lost its question!

mark: how did that happen?

jon: [shrugs in PA] probably me

I make a quick change to the DB to fix

13:15 <mmatrix> they are demoing right now 🙁

13:15 <mmatrix> (it’s like watching a train wreck in slow motion.)

jon: editng the RQA… waiting… it worked! Questionnairre is healed.

jon: okay, cache back on. do we need to bounce the server?

mark: no, just re-open RQA two more times and it will be cached

jon: cool, i am editing the RQA a 2nd time now

13:16 <jonkern> i am still waiting for a response [the RQA to return]…

13:16 <jonkern> app is transferring data now

13:17 <mmatrix> waiting for what? Do they [marc & harry] know about the problems?

13:17 <jonkern> got it! [The RQA]

13:17 <mmatrix> He [Marc] just did a create new

13:17 <mmatrix>

mark: hurry jon! hurry before Marc hits CONTINUE button

13:17 <jonkern> trying it [editing RQA] again now for 3rd time

jon: someone slow marc down for a few seconds! (I joke)

13:17 <jonkern> FAST, SWEEET!!

13:17 <markhanson> and marc hasn’t hit continue yet!!!!

13:17 <jonkern> and all without the usual demo rodeo clowns

13:17 <mmatrix> will it be too late?

13:17 <jonkern> nope. it [RQA] comes back fast now (<10 seconds)
13:18 <mmatrix> JK, if this works it will be the closest I have EVER seen a demo be cut

13:18 <mmatrix> he is creating new

13:18 <jonkern> ignore the men (and lady) behind the curtains

13:18 <mmatrix> hasn’t continued yet

13:19 <markhanson> i am lol and pinching myself to not lose consciousness

13:19 <mmatrix> here he goes

13:19 <mmatrix> doing BOP [a type of insurance line of business] it looks like

13:19 <markhanson> he hit continue

13:19 <mmatrix> … looks for a place to hide

13:19 <jonkern> did it come back fast???

13:19 <mmatrix> no

13:20 <mmatrix> still nothing

13:20 <markhanson> came back

13:20 <mmatrix> it is BACK!

13:20 <mmatrix> son of a GUN

Major applause and cheering from us!

And much more merriment was had when marc did rate the sample insurance applications and premiums were returned, and he made changes to the quote and re-rated and got different premiums. Sweet, the core concepts of the application were just proven. Yes, we can put a modern RIA front-end on a Phoenix back-end and get penny-to-penny match on the premiums!

Reflecting back… Mike was giving play by play description in the phone of the demo and what marc was doing. Mark was also talking to me on the speaker phone (and eventually other developers joined in). All the while, it struck me as listening to the Apollo lunar landing as someone was watching it, or being in mission control with different folks checking in, but I myself not being able to see.

What a rush!

Harry’s words sum it up:

The company is confident that we can deliver the tool to the agents to deliver small commercial insurance.

The company has given us a good report card in terms of what they were looking for.

Andy [President] is supporting us to the nth degree

[Team,] on tuesday afternoon you told me we could make thursday COB for friday QA build. We actually hit the goal on Wednesday afternoon (especially once Andrew discovered missing LOBs on TEST), and left Thursday morning for cardio exercises:

Ken innocently twiddled the main application file,

Jon and Mike added something to the qstnr for Marc only to realize it didn’t work and had to back it out, and

Jon missed one choice’s assigned question and broke the qstnr!!

Who needs espresso?

Savor the moment… there will be more, but this was a good one. Be proud! I am — of you.