There is no such thing as a good field programmer

There is probably some rule of blogging which says that once you start making war analogies you’ve jumped the shark. With that risk acknowledged, I’d like to present a quote:

The influence one man can have on thousands is a never-ending source of wonder to me. You are always on parade. Officers who through laziness or a foolish desire to be popular fail to enforce discipline and the proper wearing of uniforms and equipment not in the presence of the enemy will also fail in battle, and if they fail in battle they are potential murderers. There is no such thing as: “A good field soldier:” you are either a good soldier or a bad soldier.

(Emphasis mine) That’s General Patton in a letter to his son.  Patton was trying to impress upon the boy the importance of setting a good example.

I write a lot about code quality. Usually, I’m doing my best to exhort fellow developers in the trenches. This one’s not for them, though. This one’s for the CTOs, team leads, project managers, product managers, ScrumMasters, founders, CEOs, and future CEOs. So if you you know someone who matches that description print this out, fold it into a paper airplane, wing it into their office and then saunter away as nonchalantly as possible.

OK, ready software leadership types? Here we go.

Leading by example

I’m not going to insult your intelligence. You know your decisions affect the quality of the code your organization produces. What you may not realize is which choices make the biggest difference.

I don’t want to talk, here, about the big crunch where you asked everyone to put in 12-hour days for two weeks before the big unveiling at a major tech conference. We all know you’ll be paying off that debt for a while. Nothing new there.

I want to talk about how well your metaphorical boots are polished.

It doesn’t matter who you hire, or what classes and conferences you send your developers to, or how many beanbag chairs you buy them. If you set a slipshod example, your developers will give you a slipshod product.

Examples of what your developers might be seeing and hearing:

  • “God, the users are idiots. The other day one said…” I think it may be impossible to despise your client or users and still deliver a quality product.
  • The CTO is a Hero. When the work isn’t on schedule he spends all weekend ripping out the work everyone has done and replacing it with 1000 lines of untested code that works… barely.
  • “Man, if the client ever saw this code… good thing they never will.”
  • “It doesn’t have to work well, it just needs to demo well”
  • “Just put this rework under the ‘documentation’ budget, they don’t need to know”
  • The CEO takes no notice of the engineering team until the client has a problem. Then he wants daily status updates.
  • Key stakeholders are consistently late or missing from the daily standup.
  • “I just read about $TECHNOLOGY in CTO Weekly. Let’s switch the whole system over to it.”
  • Every single member of the team hates the project management tool. But they have to use it anyway. Message “it’s OK for a product to suck as long as you can trick someone into committing to it”
  • The VP has a pet programmer. She gets assigned to a team like everyone else, but then the VP calls her away to work on his own special projects.
  • “I know we spent a week doing estimations but I halved the estimate to make the client happy. We’ll just have to work hard on this one, I know you can do it!”
  • “Ignore the task board, all that really matters is that we make client X happy”
  • Half way through every iteration: “we need to switch gears and work on…”
  • The company has a Process. Everyone knows only lip service is paid to The Process. Management absolutely insists on pretending that The Process is actually Serious Business that is taken Very Seriously.
  • “Our exit strategy is to be acquired by Facebook. After that who the hell cares?”
  • A small company throws frequent, lavish parties. Clearly, waste is acceptable.
  • “All of our technology issues are because of That One Guy who messed everything up before he left” (guess who’s going to be That Guy after you leave…)
  • Every ticket is a reaction to something the users hate–never a forward-looking feature giving the users something they didn’t even know they wanted.

Show me an organization with one or more of these patterns, and I’ll show you an organization that’s turning out lousy, unsustainable code. You can’t lay all the blame on the developers. In fact, you can’t even lay most of it on them. If your culture says “we don’t give a shit”, then they could be 5-star primo rockstar ninjas but they too won’t give a shit.

Getting a gold star in quality

One of the advantages of being a consultant is that I get to see a lot of different companies and codebases from the inside. And I have some good news: it truly doesn’t have to be this way. There are companies out there that set a great example internally… and consistently turn out high quality, maintainable code.

One of my recent clients was a company in LA called Goldstar. Goldstar, if you haven’t heard of them, sells half-price tickets to live events. If you like to go out you should check them out.

Goldstar may be the most customer-oriented company I’ve ever seen. They have a large customer service group which takes fierce pride in having a real human reply to every customer service ticket in a matter of minutes. They have forged deep bonds with the venues which provide tickets to sell.

As part of standard orientation, every employee, even the developers, has to do a stint in customer service. The person in charge of quality assurance acts more as a user advocate than as a tester. When he communicates bugs to the development team he communicates it to them in terms of what the user experiences, not in just in technical ‘make this button bigger” terms.

Is Goldstar’s code perfect? No.  It has it’s warts. But it is orders of magnitude better than the worst codebases I’ve seen. It’s in no danger of needing to be thrown out and rewritten just to make forward progress. More importantly, when I saw it it was in the process of getting better, not worse.

You are always on parade

I don’t believe this is a coincidence. Great software leadership sets an example in every aspect of the business, both in crunch times and in down time. Conversely, you cannot expect quality when you you show by your actions that you, yourself, don’t care that much about quality or about delighting the customer.

So how about it? Are your boots polished? Medals shined? Uniform starched & pressed, and salute crisp?

What does your language, your priorities, and your habits say about your commitment to quality?

11 comments

  1. “More importantly, when I saw it it was in the process of getting better, not worse.”

    A crucial attribute. One of my major concerns with the (in-house IT-implemented) system I’m saddled with interfacing to is that it hasn’t got better at changing after four years of continuous change. Hasn’t got (much) worse, which is a sort of plus, but by now it should have got really good at changing and it hasn’t.

    How often do developers hear users saying

    “God, the developers are idiots. The other day one said…” ?

    Not as often as it happens, I’ll bet. And these days I’m on the users’ side (but then these days I’m one of ’em)

  2. I really like this post, and I see a lot of relevance to the companies I’ve worked for in the past, and companies my friends work at. I’m a new Ruby on Rails developer and I am so happy I came across this blog! I am trying to read and absorb everything I can and your blog is full of great stuff and easy to digest. Keep it up!

  3. I really like this post, and I see a lot of relevance to the companies I’ve worked for in the past, and companies my friends work at. I’m a new Ruby on Rails developer and I am so happy I came across this blog! I am trying to read and absorb everything I can and your blog is full of great stuff and easy to digest. Keep it up!

        1. Ah. It’s true my bottom line would probably benefit if I didn’t have this compulsion to write. That said, a post like this represents an hour or less of effort. It’s the code-heavy ones that usually take more time.

          1. We’re all glad you do take the time. I’m sure there are ancillary benefits – wider fame, which leads to a broader choice of gigs. And beer.

  4. I’d like to shake my head with a smile and say “Boy, ain’t that the truth!” But the fact is that I wouldn’t work for any company like that. Life’s too short, and I’m lucky enough that my skills are in too much demand.

    I really am amazed by all these horror stories and WTFs. Get up and get out! Move to the Bay Area! Move to Sweden! Retrain yourself! Don’t just sit there and put up with it. To repeat what I quoted a couple of days ago: If you can’t change your company, change your company!

Comments are closed.