Take the Long View

I was at the bank this afternoon depositing much needed money into my very dry bank account.  At about 3:50pm, all of the computers in the bank suddenly slowed to a crawl. We stood there at our respective tellers, glancing around for 5 minutes while all of the tellers asked each otehr if they were able to ‘get in’.  They apologized, customers sighed and generally no one got anything done until the ‘computers’ came back up.

Being a software guy, my first instinct is to blame the programmers.  The tired, overworked developers who were tasked with developing and deploying Version 2 Of The Bank Software; these developers (if they’re anything like any other programmer out there) probably had a budget that was overrun, a deadline that was missed, and a manager breathing down their neck.  They probably developed the application in some easy to use language for rapid development, and if they’re anything like me (and every other programmer out there) they aren’t great programmers. In fact, if you want to get statistical, there might be 1/3 of them that are ‘above average’, 1/3 ‘average’, and 1/3 that downright suck.

They probably work in a cubicle farm as part of a consulting firm, and they’re probably the lowest bidder for the project.

Now, barely any of the decisions made are the developer’s fault. And the business people at the bank probably thought they were getting the best bang for their buck — and they did.  The consulting firm probably guarantees top-notch quality and superior customer service; and the developers probably read The Pragmatic Programmer religiously.

With all of the business decisions that were made, the bank probably didn’t put an emphasis on ‘fast’. They probably didn’t say, “We need it in one year, for this cost, and we need it to be ‘fast’.” They probably assumed (much like you and I would if we weren’t programmers) that it would be lightning fast. Or maybe they’re so used to substandard application speed (I’m looking at you, Outlook) that they don’t even bat an eyelash when the system goes ‘down’ for five minutes on a busy Friday afternoon. 

The question is, Why.  Why does the system slow to a crawl on Friday afternoons?

Because business people made decisions based on the near-term; based on contractual obligations, based on cost; and based on maximizing profit.

No one probably even thought about the customer that has to wait in line.

But what’s the effect? So a customer has to wait for five minutes — no big deal, right?

Well, if that customer is his own business person, then that’s five minutes less they have to do any work. That’s five minutes of their life that isn’t spent doing whatever their business is.

Then there’s the multiplier effect of that. Someone who was waiting for that person now waits 5 extra minutes, and someone else waits five extra minutes because that person was waiting on person #1, and so on.

How do you quantify that?

Quantify it as lost business.  That three weeks you could spend delaying deployment and load testing your application could save you money when that business decides to use you for its next version.

As a developer, you’ve got to do your learning outside of work. No longer is yours a nine-to-five job.  It is a font of continual learning.  Spend an hour a night just catching up on the intracies of your programming language. Premature Optimization is the root of all evil, to be sure; but skipping optimization for time saved by your banks’ customers is a recipe for never getting that bank as a customer again.

Get out of your cubicle farm, and see your software in action. Spend five minutes on a friday afternoon with your customer and see whether or not their software slows down inexplicibly. If it does, fix it. If it doesn’t, congratulations; you’re the minority.

Bad Acting

During my time in the Army, I used to get rankled when I’d see Television or Movies portray soldiers.  Generally, they’d get something wrong; and usually, it wasn’t just something minor.  It didn’t usually bug me when it was clear they weren’t trying to get it right. It bothered the hell out of me when it looked like they tried to get it right, but failed in some way that could have been prevented if they would have spent $1000 and hired a military consultant for a day.

The same thing bothers me about naming in source code.  Well, not the military part, but the ‘bad acting’ part.  Here are a few bad names I’ve seen in source code recently, and they are all from commercial applications.

timeout  – Describes how old a file should be before it’s deleted

narrative – Refers to the ‘help’ field for a form or page.

nounset – where noun can be anything, like ‘bird’ or ‘category’ or ’email’ or ‘password’. The suffix ‘set’ is added to it to denote a ‘set’ of that noun. In some cases, it refers to a ‘template’.

That’s just a few; and there are more out there, probably in the application you work on.

What’s so wrong with bad naming?

Let’s say you have a new developer come onto your team. it doesn’t matter if this developer is just out of college or if he’s a 10 year veteran. He now has to learn what those words mean.  He then has to apply those names to the intent behind them, and daily has to remind himself of what they mean.

timeout  – fileage

narrative – instructions

nounset – nouns, or nounTemplate (This can also rely on the fact that in databases, a table is considered a collection of things; adding ‘set’ is redundant).






Teach Programmers to Fish

Last week, Jeff Atwood and Joel Spolsky discussed open-sourcing Stack Overflow. This week, Micah Martin (of Coding Context) asked a Stack Overflow question about releasing his site, Wikipedia Maze, as Open Source. 

Both had the fundamental question:

Should I release my code to the open-source community?

Short answer: Just releasing a project as Open Source is a mistake, for the same reason that handing a hungry man a fish is a mistake.

I’ve trolled SourceForge for years, but my interest in the myriad of projects op there is precisely zero. Why? Because handing me code doesn’t tell me why it’s useful to me. It’s like putting me in a library with no card catalogue. 

I’m not saying that you should never release a project as open-source, but that if you’re going to do so, it’s your job to make it worth something to other programmers, because the best code in the world isn’t worth anything if no one knows it’s there.

Going Fishing

Consider this gem from Quake:

float InvSqrt (float x){
    float xhalf = 0.5f*x;
    int i = *(int*)&x;
    i = 0x5f3759df – (i>>1);
    x = *(float*)&i;
    x = x*(1.5f – xhalf*x*x);
    return x;

If you were a smart programmer who got things done, you’d probably instantly recognize this for what it is: Awesomeness wrapped in bacon.

For the rest of us, it’s a clever piece of code that’s discussed in detail here:

The magic of the code, even if you can’t follow it, stands out as the i = 0x5f3759df – (i>>1); line. Simplified, Newton-Raphson is an approximation that starts off with a guess and refines it with iteration. Taking advantage of the nature of 32-bit x86 processors, i, an integer, is initially set to the value of the floating point number you want to take the inverse square of, using an integer cast. i is then set to 0x5f3759df, minus itself shifted one bit to the right. The right shift drops the least significant bit of i, essentially halving it.

Using the integer cast of the seeded value, i is reused and the initial guess for Newton is calculated using the magic seed value minus a free divide by 2 courtesy of the CPU.

If you were like most programmers and you scrolled across this function, you’d probably wonder what the heck it did. In fact, unless someone took the time to tell you, you might even skip over it.


But, what if you saw the article on Slashdot? Even if you had no idea about it before hand, seeing more than just the code immediately helps you as a programmer.

The end result?

You are now a better programmer because someone took the time to explain the code, instead of just releasing it into the wild.

Teach Me to Fish

If you’re going to release your site as open-source, then go the extra steps and take the users through the problems you had. Make it into an n-part blog post that details the neat parts. Write a book. Record a Podcast. Do something other than just releasing the code.

There are plenty of lessons we could learn from Stack Overflow and WikipediaMaze, but seeing the end result isn’t as useful to other programmers as taking them through your code, and showing them why you made the decisions you did. You get recognition and Google traffic, and the programming community learns how to fish.

Build your Company’s online Brand, before someone else does

By now, you may have heard about Adam Savage’s skirmish with AT&T over a very familiar story: Man gets overcharged for internet access, takes case to internet, and wins.

His Tweet (a message on Twitter) simply read: “AT&T is attempting to charge me 11k for a few hours of web surfing in Canada.”

His message spread amazingly quickly on Twitter. Within three hours, AT&T was the second most discussed topic on Twitter, second only to Michael Jackson.

By the end of the day, the carrier was “very gracious about taking care of it all,” Savage said, deciding to free him of those costs.

So holds the power of the internet.  This sort of thing has happened before and it will happen again. It’s even happened to me.

The funny thing is, the age old adage “There’s no such thing as bad press” isn’t true anymore, and companies like AT&T and Verizon know just how easy it is to lose customers. Why do you think they require service contracts?

I’ve been known to jump from one service provider to the other if they start treating me badly, and with this newest text messaging problem, I probably won’t jump back to AT&T any time soon. I’ll just wait for the iPhone to become a non-exclusive item.

The complainers, the people the people that bad mouth your service, now have a voice. A very loud, very obnoxious, and very addictive voice. You used to be able to dismiss them out of hand; but now one bad service call with one customer can provide years of online enjoyment.

So, what do you do?

You can’t make everyone happy; that’s obvious. But you can take those singular “We messed up” moments, and turn them into something good. In Soccer, we call those pivotal moments in games the Moment of Truth. It is the occasion when the referee has to make a decision that will forever shape players’ perception of him throughout the match (and possibly his career). It happens in almost every match, and getting that singular moment right can do a lot to repair or extend credibility where you might otherwise have little.

In software, that means openess. Not the Government 2.0 kind that really isn’t, but the kind where you address complaints and complainers head on. You can no longer pretend that they don’t exist. Steve Krug wrote in Don’t Make Me Think  about how company FAQ pages never really tell you anything you really want to know, and he’s right: they ought to.  Businesses now must hire  ‘Social Media’ experts or ‘Community Managers’ to address customer service issues in this new age of the internet. As Jeff Atwood writes:

To have a personal brand, you must do something remarkable:


  • lead a user group
  • create a popular open-source project
  • write a blog
  • publish a book
  • publish articles
  • speak at conferences

Do whatever you like. Pick one, pick them all, or pick something that’s not on this list.* As long as it’s public, and it advances your skills, you’re creating a personal brand. And that will help your career far more than technical chops ever will.

His advice is as salient for businesses as it is for individuals (and software companies doubly so!). What can businesses do to build their online brand?

  • participate in social media (not just press releases, please)
  • encourage your employees to participate in social media
  • only censor the business proprietary stuff
  • let the warts shine through
  • become personable

Having a ‘blessed’ social media account is not the same thing as 5,000 employees having blogs and twitter accounts. 1 voice is meaningless, but a sea of employees generally talking about their day/life/work makes me interested about those things. I never gave Dell a second thought until I saw that they have a lot of employees with Twitter accounts. Now their brand is more personal to me.  Microsoft was an early adopter of this with encouraging blogs being written by their employees. The question is, why isn’t your company building its online brand through employee crowd-sourcing?

If you don’t build your company’s online brand and keep it polished, someone will tarnish it, and you’ll only have yourself to blame.