Anti-Pattern: Design by Metaphor

I missed one earlier
today
, one of my “favorites”:

Design by Metaphor

When discussing a design or requirement, instead of using
concrete examples, people use metaphors. The discussion goes on for
quite sometime, and the metaphor takes over. People begin arguing
about aspects of the design in terms of the metaphor instead of the
actual system, often forgetting about the real code.

This anti-pattern seems to emerge when people know what they want
(or don’t know), but they don’t know how to express it technically, or
meta-technically with use-cases,
stories,
etc.

For example:

Jasper: “The Flojam Integration Component is a system that gets the
user entered data and associated meta-data from the front-end to
all the persistence servers. What should we do?”

McTaters: “Well, you see, the Flojam Integration Component is like a
bullet train. We confine it to tracks, and it stops at stations along
the way picking up passengers.”

Bobby-Lynn: “Ah, indeed, but the passengers are going to want to
bring on baggage, right? So, we racks to put their suit-cases on!”

Stumpy: “Verily it is true, my good friend. Additionally, if the
passengers pay more, a baggage-handler will take care of their baggage
for them.”

Bobby-Lynn: “Excellent point. The client-code could choose between
handling it’s won ‘baggage,’ or having the ‘handlers’ do it.”

McTaters: “Perhaps the customers shouldn’t have to know if they’re
on a bullet train, or an aero-plane.”

Stumpy: “Lovely!”

Jasper: “What are we talking about here? Can we just scp over a zip file?”

McTaters: “I guess…if you don’t want a bullet train!”

Anti-Patterns: Design and Requirements

Here’re two patterns of doing design that I’ve noticed recently:

Design by Exhaustion

Two or more people debate furiously about the best
way to design something. One of them gets tired of discussing the design
and simply gives up. The one who can hold out the longest wins!

Requirements by Siege

At higher levels in an organization, when
deciding on requirements or whole systems to implement, “Design by
Exhaustion” takes on a slightly different form: which ever sub-group
in the organization can hold out longest, waiting for the other to
give up (either go away or starve) gets their way. In the mean time,
the customer takes their money to your competition. Have fun storming
the castle!

Requirements/Design by Anecdote

Someone has heard a story about
a customer who wanted some feature in their product. They don’t really
remember who it was (who takes notes on these kinds of things?), but
they remember it was really important. After some period of time, the
story is transformed into an either:

  • An Anecdote – an extremely narrow use cases, aka, “Edge Cases”,
    that’s been widened to all customers. E.g., “a customer wanted to
    get emails for all purple whiz-boggles created that are only
    85% taste-effective as measured by the International Tasting
    Standards Body
    . This is very important to our customers! Pull
    all the stops!”, or,

  • A “myth”/”legend” – a requirement that has been so generalized
    as to be meaningless, and yet demanded by “all our customers.” For
    example, “our customers demand that the product scale,” or, “our
    customers demand that the product be usable!”

Dealing

As is the case with all anti-patterns, these are actually patterns
used day-to-day developing software in the large. Avoiding them
completely is impossible. Containing their damage is the more realistic
route.

Distributed Development == Shitty Results

From “Who Benefits from Outsourcing? Not the Line of Business“:

The Deloitte study also debunked several other oft-claimed benefits of outsourcing. For example, proponents frequently claim that outsourcing can free up internal company staff to focus on projects that deliver more business bang-for-the-buck; for a majority of respondents (57 percent), this wasn’t the case. In fact, because of the increased management overhead associated with the outsourcing model, many companies said this was impossible.

This is far from surprising to most IT pros, of course.

“This project [I’m now on] has been joked about for staying mainframe, but the cost savings over implementing this in ‘newer technology’ will be in the tens of millions of dollars,” says Cave. “If it were the outsourcers alone, they would probably just do as desired by upper management and build a whole new subsystem. But once [management] was presented [with the cost estimates], they realized that the numbers don’t lie.”

I haven’t posted about offshoring/outsourcing in awhile. Whether your outsourcing to another campus in your own company or to a different company across the globe, we’ve known for years that distributed development and IT-work makes things more difficult, slow, and costly.

If your people aren’t in the same room, or barring that, the same floor in the same building, you won’t be as productive as possible, nor make as much money as possible. (Granted, if you have a bunch of those Hero-monk types, they might need their own office and 7 months on a steady diet of flat-foods.) You’ll end up with some horribly distributed monstrosity, whose parts will barely be able to talk or work with each other. Just like your people, all spread out across the world.

This is a fact of programming and IT. End of story.

(If you can figure out how to get around this fact, there’s vaults of gold waiting for you.)

I Have No Attention Span, Shrinking Info Packet Size

I’m reviewing a large (90+ pages) document for work, and man, I have almost no attention span. Almost at the paragraph level I have to fight myself to not start doing something else, like go print something out, IM a question, or go pick up that print out, or update a wiki page somewhere, or compile some code. I’m like a frickin’ ferret over here surrounded by shiny objects.

It’s not that the document is boring — it’s actually quite illuminating about what I’m working on in a very positive way — it’s just that I’m overly trained to get derailed with purpose. It’s little wonder I can’t rarely finish a book or read less than 4 at a time, not include all those half-read magazines.

In a recent ITConversations (this one, I think), Tim O’Reilly talks about the notion of figuring out the ideal “packet” size for information today (for his customers at least). In the past, it was a book or a magazine. Now, it seems to be shifting towards a more essay, even aphoristic, size a la weblogs. He cited the hacks and cookbook series as good examples of an implementation of this theory of shrinking info-packet size.

I think my packet size might be a paragraph, and 3-5 of those if they’re really short and well connected. I’m a big fan of bullet lists as well. I saw a document the other day that was pretty much a 5 page bullet list and I loved it.

Yeah…enough navel gazing for the day. I’m getting the urge to do something else real-bad-like.

Grease Monkey is to Web Services as REST is to SOAP

Granted, REST and SOAP are web services. What I mean is something more along the lines of “the secret sauce/magic powder that takes all our integration woes away.” The point is the same as in Steve’s recent post: if the “do the shit that works, not that’s elegant” crowd can figure it out, Greasemonkey can be made to fix a lot of the integration and terminal-waiting-for-features problems IT has.

What are these integration and terminal-waiting-for-features” problems? Well, as I understand it, there’s quite a lot of web application both behind and outside the firewall. They work marginally well, and they certainly were nifty back in ’99 when they were last really reved. If you work in a huge company, with a zillion web apps for doing everything from filing for reimbursements to go to The Swamp, to entering the time you spent programming and getting coffee, you know exactly what I mean.

Now, no one likes a bunch of separate UI’s for their daily life. Everyone wants one page, the hallowed “single pane of glass” that pops up and says:

Greetings. This is master control. Here are the things you must to today:

  • Tell me how you spent you time yesterday.
  • Update your status on these 5 items.
  • Click this button to agree that you've read this new policy.
  • Would you like to be reimbursed for driving to and fro The Swamp?

(Well, no one wants to be faced with a list like that, but I’d certainly prefer it to keeping track of all those PostIt’s with different whacky URLs I have to go to, logins, clickity-click-click-clicks and typing with bizarre UIs to just to get my shit done.)

Now, you’re certainly not going to get all those vendors to work together to give you an integrated view. You could ask someone(s) to code you up a nice web app that made all that into a sort of dashboard…that’d cost you a pretty penny, and you probably wouldn’t like what you got afterwards. Such is enterprise software. But, we all know this.

On the other hand, if you got one of those zaney, Firefox using doofuses (‘tip o’ the hat to James for the word of the day) to whip up a cart-full of Greasemonkey scripts that pulled all that crap together with a pile of HTML, JavaScript-duct-tape, maybe a PHP/Python/Ruby REST service or two…well, my spend-thrift C*O friends, you might have yourself something that was actually worth the nothing you spent on it.

Good Lord, and if you had your own people do it, you could change and update it whenever you wanted without piles of CMM level 3-5 documentation to fill out.

That said, I’m just a programmer: I don’t understand your “initiatives,” “business consultants,” “vendor sports,” or “enterprise systems.” I was thawed out of a high school by your Business Men to code up some crazy web application. Your world frightens and confuses me! But I do know one thing: keep it simple, stupid.

Cleaning Robots Rule!

Holy Crap!
this sounds like all my chore-dreams come true
:

In all, the cleaning process takes five stages. First, an airjet blows foreign objects to a “cereal port,” or vacuum. “It is powerful enough to sweep up Cheerios or dried pasta,” Angle said. Second, two fluid jets squirt out cleaning fluid and water. Next, a mustache broom spreads the fluids evenly to help absorb dirt.

Scrubbing brushes then try to eliminate particles. In the fifth stage, the dirty water is sucked up into a separate liquid chamber with the help of a squeegee.

The idea to develop a device for hard floors came from customer feedback. After they’d buy the Roomba, customers would tell the company that “what I really, really need help on is scrubbing my floors,” Angle said.

More domestic robots may follow. “What I want is something that will fold my laundry,” said Angle.

Hopefully iRobot won’t turn into a pumpkin come midnight…

"Disclaimer: This post was written under the influence of Gin and Tonic and air travel."

Our man James “monkchips” Governor gives a hefty dose of G&T induced thinking to episode 04:

But Coté is funny when writing so i figured i should check out Cote and Charles: He’s Burger, Web Apps Suck. Of course i didn’t listen to the first three episodes so who knows if they were any good. But episode 4 is spot on. Scatalogical humour always gets me right in the funny bone. Good work guys.

And, aparantly, we have a cliff-hanger to reveal what the ideal web app framework would be like. Jesus, the presure is killing me; you might spot me next in South Africa.

We always enjoy in-coming links here at DrunkAndRetired.com. They simply can’t be gin-ore’ed. So thanks to James. We’ll have to send you a shirt or something ;>