Let’s try a little Bizarro¹ 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.

¹

Credit goes to Superman and Bizarro World.