Skip to content

Software development DSL

Dear Reader,

[Author’s Note: Fridays should be fun. If you are a manager, try taking one Friday a month and let your developers do whatever they want. Trust them to do something but don’t give them any parameters at all. See what they dream up.]

When I venture out into the real world, the one not populated with developers, I get a lot of strange looks and odd stares when I talk. Apparently there are a lot of people out there who don’t grok grep, have never been slashdotted, and can’t tell a brown number from a WAG. I saw r0ml give a talk one year about domain specific languages and how they are important. I apologize to r0ml for bastardizing his idea but today I am going to share five of our more colorful terms from the software development DSL.

Yak Shaving

The objective of all dedicated product support employees should be to thoroughly analyze all situations, anticipate all problems prior to their occurrence, have answers for these problems, and move swiftly to solve these problems when called upon. However, when you are up to your ass in alligators, it is difficult to remind yourself that your initial objective was to drain the swamp.

We have all seen the quote above, usually in a font reminiscent of something that has been copied four or five times and then faxed a few times before being tacked up on the break room cork board. Anytime someone mentions yak shaving, I always think of it. Seth Godin has the best blog post explaining Yak Shaving I have ever seen. Let me quote a little of “Don’t Shave That Yak” but make sure you go read the entire thing for yourself.

Yak Shaving is the last step of a series of steps that occurs when you find something you need to do. “I want to wax the car today.”

“Oops, the hose is still broken from the winter. I’ll need to buy a new one at Home Depot.”

…and he goes on.

We all face Yak Shaving situations, now you at least know what to call them.

Used in a sentence:
“How is your day so far?”
“Shavin’s Yaks my man, shavin’ Yaks.”

My good friend Travis Swicegood introduced me to this one a year or so ago. Honestly, I thought he was pulling my leg but sure enough, Wikipedia has a page defining this term. (and c’mon, if it’s on Wikipedia, it has to be real, right?)
Bikeshedding – aka Parkinson’s Law of Triviality – is an art form in the right hands. We have all been in meetings where the discussion devolves from making a decision about the functionality of a screen the color or shape of a button. We have all seen The Stop Sign Video, that is a great example of bikeshedding.

Parkinson dramatizes his Law of Triviality with a committee’s deliberations on a nuclear power plant, contrasting it to deliberation on a bicycle shed. A nuclear reactor is used because it is so vastly expensive and complicated that an average person cannot understand it, so they assume that those working on it understand it. Even those with strong opinions often withhold them for fear of being shown to be insufficiently informed. On the other hand, everyone understands a bicycle shed (or thinks he or she does), so building one can result in endless discussions because everyone involved wants to add his or her touch and show that they have contributed. While discussing the bikeshed, debate emerges over whether the best choice of roofing is aluminium, asbestos, or galvanized iron, rather than whether the shed is a good idea or not.

The gist of it is you get bogged down is stupid details. I know that no developer has even been in a meeting with a client who, while they cannot grok the entire application, they read a marketing blog that discusse the relative merits of green buttons vs. blue bottons. Feeling they need to contribute to the conversation in order to feel they are relevant, they hijack the entire meeting until the color debate is resolved for all mankind.

Used in a sentence:
“How is your day so far?”
“Well, we almost had signoff on the order screen but then the client started bikeshedding over the size of the button. It went downhill from there.”

Dogfooding is not a difficult concept to understand. (Which is why I am surprised that there is a 2 page post on it over at wikipedia.)

Eating your own dog food, also called dogfooding, is when a company uses the products that it makes.
  – Wikipedia page on dogfooding

If you make a product, use it. Why would I use it if you don’t? Does the President of Gillette shave with a Bic razor? (Gees I hope not, those things suck) You get the idea though. Even though it is a very easy concept to grok, I am constantly amazed at the number of C-Level’s that can’t seem to get it.

Used in a sentence:
“How is your day so far?”
“Well, the idiots upstairs have decided that we are going with Drupal for the main site instead of dogfooding our CMS.”

When developing computer software, the biggest hurdle most of the time is understanding exactly what needs to be developed. On a good day, a programmer gets very detailed and possibly overly complex specs from which to work. On a bad day he gets a post-it note with 4 bullet points and a deadline of yesterday. To help a programmer figure out what needs to be done, or to just work through a particularly difficult problem, we often need to simply talk through it. Rubberducking is the act of doing just that. Here is the description from “RubberDucking

Place a rubber duck on your monitor and describe your problems to it. There’s something magical about stating your problems aloud that makes the solution more clear.

Talking through the problem to no one in particular forces you to actually state the problem. Because the duck can’t talk back to you, you don’t get sidetracked with their bikeshedding on the problem. As an aside, I have also found that spouses can be substituted for the rubber duck.

Used in a sentence:
“How is your day so far?”
“I hit a wall earlier on this one problem but rubber ducked it out. Had the code written before lunch.”

Being Rasmussed
This last one is PHP specific and I know it but it is a common term around conference time and especially among speakers. Rasmus Lerdorf wrote the first version of PHP and has remained a central figure in the PHP community. He limits the conferences he speaks at these days. When he is at a conference, especially a multi-track conference where he is one of several speakers vieing for attendees, Rasmus will almost always draw the vast majority of the audience into his session. If the conference has 100 attendees and 3 sessions, Rasmus will end up with 90 people in a room made for 50. The other two sessions will split the remaining 10 only because they couldn’t get into Rasmus’ talk. These other two speakers are said to have been “Rasmussed”.

These days at PHP conferences the term can be heard bandied about amongst the speakers and the veteran attendees, even when Rasmus is not speaking.

Used in a sentence:
“How is your day so far?”
“My session went great and I totally nailed it but I only had 3 people because Liz Naramore Rasmussed me with her “Technical Debt” talk.”

That’s it for my “It’s Friday and I want to do something fun.” post. I hope you enjoyed it. I hope you smiled. I doubt seriously you learned anything useful though. :)

Until next time,
I <3 |<

5 thoughts on “Software development DSL

  1. Another one I’m particularly fond of is “Salmon Day” … as in, you spend all day swimming upstream only to get f*cked in the end (alternative ending, swim upstream all day only to die in the end). The great irony is that I am an IT Manager and PHP developer for a fisheries consulting firm.

  2. Fun piece! no idea what this has to do with DSLs (aren’t you confusing DSL with Jargon?), but I recognized all 5 from real life conversations so it’s nice to read them with a ‘formal’ definition. There are so many, you could turn this into a recurring topic, or better, write a dictionary :)

  3. I reckon there are tons of people like me, who come across varied strong blogs or sites by fortune. Your web log appears to have a great community and a great blogosphere presence. Its good to have absorbing and contrary perspectives on issues.

Comments are closed.