The most fun you can have in 140 characters

Twitter is a neat little tool. I like it. I use it as a micro-blogging service, and it gives me a chance to get an up-to-the-minute fix on technology and programming. For instance, in the last week these are some of the items I’ve found on Twitter:


I’ve also read countless blog posts by people I’ve follow, posted pictures on twitpic, and complained about bad User experiences.
Each week is normally chock full of interesting items and fun items. If you want to learn more about twitter, I recommend reading Brent Ozar‘s book on Twitter: The Simple Twitter Book.  He explains twitter much more clearly than I can (just not in 140 characters).


The Paradox of Safety

I grew up in a transition period. A period that children didn’t wear bicycle helmets, we played in creeks, woods, and other ‘unsafe’ areas, and apart from bumps and bruises, we ended up just fine. Then something happened. Parents stopped letting children play outside, children wore more padding than a football player to ‘play dates’, and everyone suddenly got more paranoid about safety.  Not surprisingly, people still get hurt, maybe even moreso. So it’s a surprise to learn that there is an experiment in place to go in the other direction:

For a number of years now, a number of cities in Europe have been experimenting with the removal of all traffic signs – including traffic lights, stop signs, speed limit directives – and with surprising results. Various towns in the Netherlands, Germany, Belgium, Sweden, New Zealand – even the UK! – have joined in the experiment. Contrary to the expectations of those who might expect multi-car pileups throughout the cities, traffic accidents have been dramatically reduced (in one town, dropping from about eight per year to fewer than two).

The architect of this experiment, the late Hans Monderman, is quoted to have said, “it is dangerous, which is exactly what we want”:

“Unsafe is safe” was the title of a conference held on this practice. Monderman added that this effort “shifts the emphasis away from the Government taking the risk, to the driver being responsible for his or her own risk.” Equally significant, drivers now focus more of their attention on other motorists – taking visual cues from one another, informally negotiating for space, turning into an intersection, etc. – instead of mechanistically responding to signs and electronic machines.

Monderman stated: “When you don’t know exactly who has right of way, you tend to seek eye contact with other road users. You automatically reduce your speed, you have contact with other people and you take greater care.” He added: “The many rules strip us of the most important thing: the ability to be considerate. We’re losing our capacity for socially responsible behavior.” In words so applicable to the rest of our politically-structured lives, he declared: “The greater the number of prescriptions, the more people’s sense of personal responsibility dwindles.” Monderman expressed the matter more succinctly in saying: “When you treat people like idiots, they’ll behave like idiots.” (emphasis mine)

It boils down to this: If you want people to act in a safe manner, remove the safety factor.

For software developers, we’ve heard it in the religious wars between managed languages and unmanaged languages, and in the erroneous assumption that managed languages do not have memory leaks. I don’t have any solutions, although I believe the answer leans towards ‘Unsafe is safe’. Take away the illusion of a safety net and programmers (and people in general) will start paying more attention to their work. You won’t have any C# ‘Slap this together’ apps, but is that really a bad thing?

Bonus: has an article out today on 6 Scientific Reasons People Drive Like A-Holes. Check out reason #4.

Captains Log, Supplemental

Captain’s log, Stardate 43539.1. We have moved into orbit around Bre’el IV. With the assistance of the planet’s emergency control center, we are investigating a catastrophic threat to the population from a descending asteroidal moon.”
“Captain’s log, supplemental. We are no closer to finding a solution to the deteriorating orbit of the Bre’el moon, but with the arrival of Q we now have a good idea of the cause.”
“Captain’s log, supplemental. We have sustained light damage from an attack by an alien species known as the Calamarain. They apparently have a grievance with Q – no doubt one of many lifeforms that do.” (TNG: “Deja Q“)

The Captain’s Log takes you through the high notes, letting you know three things:

  1. What happened
  2. What’s happening now
More importantly, it tells you this when it’s happening. Let’s say, God forbid, that Wesley Crusher destroys the ship in a fit of teenage angst and all we find of the ship is the jettisoned Captain’s Logs. Would you rather the last few entries say:
Captain’s log, Stardate 51734.1 “Wesley Crusher has rejoined the ship after an extended stay with the Traveler. In the intervening time, he has grown angrier. Dr. Crusher is relieved to see her son, but concerns about his mental stability remain. I’m asking Dr. Pulaski to run a full scan on him to be certain.”
Captain’s Log, supplemental. “Dr. Pulaski has run the scan, and determined that there is a creature of unknown origin inhabiting Wesley Crusher. In his more lucid moments, Wesley believes he received the parasite during a visit to Risa’s notorious South Pole.”
Captain’s Log, supplemental. “The parasite has taken over Wesley crusher completely, and has used the knowledge of the Enterprise to jettison the Warp core and shut down life support. There is currently no way to get off the ship. This will be my final log as captain of the Enterprise. Her ship and crew have served well, and are in keeping with the finest traditions of Starfleet. I am transmitting this log on subspace Starfleet Command, Priority One.”


Or this:

Captains Log, Stardate 51734.1 “Wesley crusher came onto the ship today and proceeded to shut down life support and jettison the warp core. There’s no way to leave the ship.”

The first one, of course. It sounds better. it’s more complete, and in case your ship is found adrift with all crew dead, at least someone has an inkling of what happened to you.

Just like in code.

You fix a problem, you go on vacation or win the lottery, or quit.  As soon as you step off the plane in Tahiti, there will be a bug with what you fixed.  The programmer tasked to fix this bug is going to want to know what you did. He has source control for that; but he’s also going to need to know *why* you did what you did. What alternatives did you consider? 

I’ve written about this before.  

The bug report is your chance to concisely list the relevant issues with a bug, how you are going about fixing it, and most importantly, what didn’t work.  Maybe I’m senile, but I can’t remember what I fixed 6 days ago, let alone 6 weeks ago. The bug report helps me keep a running log of what I’ve tried and what I haven’t.  In instances where it doesn’t make sense to put it into a defect tracking system, I keep a personal notebook. It goes with me everywhere, and it contains details on any solution I’ve ever tried. It’s my own personal Captain’s Log, and privately I call it that.

If you’re just publishing Changeset numbers and the word fixed in bug reports, you’re doing your teammates a disservice. Programming is hard enough as it is, don’t make it any harder by not ‘showing your work’.

Caring for Your Recently Acquired Programmer

Congratulations! You were just given a new Programmer!

Pop Quiz:

Do you…


  1. outfit your programmer with the standard office equipment?
  2. order custom equipment specialized for software developers? 
  3. ask your programmer what he needs to get his job done? 


 If you answered (2) or (3), you’re on the right track. otherwise, you get a nice little tombstone when your developers leave, a la Oregon Trail:


Software developers do three things:


  1. Concentrate really hard. 
  2. Type a lot. 
  3. Sit on their fourth point of contact for extended periods of time. 


How does the standard office equipment fare against these requirements?

Poorly. At best.

The monitor is a 15 inch LCD as one screen, and a laptop screen as the second. With any luck it’s a desktop with two monitors, but sadly they’re both 15 inches.

In some unspeakable instances developers have *one* monitor.  Prolific developers and bloggers have already beat this subject to death. To save you time, here’s the right answer: High Quality monitors. At least two of them. Really big ones. Like 24″-30″. 

Back to my flattened rear end. Office Chairs are expensive, no doubt.  Office chairs that meet our needs? Even more so. I bought a Herman Miller Mirra chair a while back based on recommendations from people I trust, and it’s the best decision I ever made. Believe me when I say that I’m halfway tempted to take it with me to work:

The final piece of the puzzle is a really fast computer.  Really fast. Not “Oh, I bought this from Dell” fast, but “We needed to custom order these” fast. 

I could spend and entire blog post on that alone (and probably will), but here’s a good rule of thumb: If you can buy it without having to customize it, it’s wrong. Your action word to the Sales rep should be ‘More‘.

Overall, this will cost about $4000 a developer. Another 2-3 grand for the PC.  In return, you get a developer who is happier, more productive, and is less likely to jump ship when one of your competitors wises up and starts offering these perks.

Don’t think about it as a cost, think about it as a savings: For any developer you lose, you’re going to lose a lot more than $4000 to replace them.

A tale of two companies

There are two kinds of companies in this world: The kind that sell you software, and the kind that use software to sell you something else.

There’s also the PGA. Someone forgot to inform them about the technology revolution.

The companies that sell software are easy to spot. You see their products in stores that sell… software. The companies that use software to sell you something are everywhere else. The golfers are on the links, chasing balls and cursing the gods.

Both kinds of companies have a bottom line in mind, they just think there are different ways to get there: Software companies know that good software (or a cornered market) is the key to making lots of money. Those other companies figure that software has something to do with making more money, but aren’t quite sure how that works. They aren’t even sure how to handle software teams.

And you have software developers caught in the middle. 

We love what we do. In the majority of instances, we started programming or tinkering with computers when we were young, and it made us happy. We kept doing it. Lawyers can’t file a brief at age 5, but kids can program at age 5. When we grew up, we figured that everyone would see how much we like software and just leave us alone to make it. They had other plans. Meetings, diagrams, excel spreadsheets, quarterly reports, and cost/benefit analyses.

You show them great software, and they want you to make one of those things I just talked about, and try to fit the software in it somewhere, as if it were a line-item on a spreadsheet, or a font of magic in a diagram. In a meeting, it’s just a lot of buzzwords: We’re going to synergize our multiple offerings across the blogosphere with social media while using diverse delivery platforms to ensure a higher conversion rate. Or something. 

Then, they pat you on the back, and tell you to go make their dream a reality. Then they leave for the golf-course. You sit down, read through piles of reports, looking at snazzy diagrams, and staring at numbers some accountant told you you’d have to meet.  

It’s just about at this point where it hits you: They have no idea what it takes to bring pure thought stuff into something that ships and doesn’t suck. They have the gold, they make the rules, or so the conventional wisdom goes. You start banging out functional requirements, technical specs, and if you’re lucky enough to have a UI guy, he does the user interface stuff, and you two collaborate. If you have a team, you divvy out the work, collaborate on the design if needed, send the questions back to the customer. He’s probably on the golf-course with your boss, or he is your boss.