The Bizarro Manifesto

Let’s try a little Bizarro1 test (if you agree to these, I’ll poke you with a hot krypton stick):

We are uncovering better ways to provide the illusion of developing software by listening to others talk about watching people try. Through this (dare I call it?) work, we have come to value:

  • Dogmatic process and CASE-tool-like automation over inspiring quality individuals to interact with the team and the clients
  • Sufficient up-front comprehensive design specifications over seeing frequent, tangible, working results.
  • 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.
    • We start with complete requirements specifications (often 400 pages), that follow our company standard template.
    • 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.

Feel free to sign the manifesto below. It’s free to be certified.


1

    Credit goes to Superman and Bizarro World.

MongoDB Honey Badger

In case you don’t know about the Honey Badger—you have to watch this video. Then you will see why MongoDB is a close cousin to this feared and fearless animal!

Developing a new project where your domain classes/tables are changing rapidly?

MongoDB don’t care!

Tired of running rake db:migrate?

MongoDB don’t care!

Need to add a new “column” to your “table?”

MongoDB don’t care!

Want to query your “table” on “columns” that don’t exist?

MongoDB don’t care!

Need to add a new index on the fly?

MongoDB don’t care!

Welcome the Nastyass MongoDB into your development lair, you won’t give a shit about your database growing and changing!

MongoDB don’t care!

Find out more about Honey Badgers here — though Randall already taught us most of the salient points!

 

Good humor

This was in an email after I purchased something…

This is an automated message from the Yahoo! payments robot to let you know we got your money. Flickr will send you a more entertaining email shortly.

I like this sense of humor from an application 🙂

Don’t Code the Fluffy Mackerel!

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:

   Scary 1974 Weight Watchers Recipes.

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!

Management By Magazine

Agile Project Management forum got this post:

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.”

Clear Specs

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.

Thank you for attention Redd Cross of Slovenia!

My Favorites

  • Good time of day.
  • You are disturbed by the charitable company…
  • your salary…at an incomplete working day.
  • The more and forces you will give time…[the bigger your salary]

Makes me want to sign right up!

The Distributed Demo

A letter to the extended team/business/qa mailing list:

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

[DB and App running on servers in the middle of PA]

12:46 <markhanson> i am about to faint [Mark is in CA]

tick, tick, tick

nothing

crap

12:56 <mmatrix>T-4 [mike is in CA]

(mike is viewing the demo via netmeeting and reporting to us.)

i flip caching back on

hell with the test, trust in the force

12:59 <mmatrix> uhoh; faultString (String): java.lang.StackOverflowError

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.

Doofus Darts

Ever want to hand out “Doofus Darts” to your team?

Anyone who accumulates more than 5 darts in an iteration gets hit with a rubber mallet and has to buy a round — of whatever.

Up and down the team, from developer all the way down to the execs.