Jones’ Law

While working on my Daycamp for Developers presentation, I’ve been going through some of the “laws” related to project management and estimation: Brooks’ Law, Hofstadter’s Law, and others. As part of this, I’ve decided to coin my own; it’s something I’ve been saying for at least a decade:

Jones’ Law: “If you plan for the worst, then all surprises are good surprises.”

Attend Daycamp for Developers and you can hear more about estimating software projects and setting client expectations, as well as lots of other “soft” topics that developers can benefit from.

On War, and Development

… It is not, in the modern world, enough to be a lone visionary.  Under modern conditions, strategic genius must necessarily be linked with bureaucracy.  The greatest genius needs a military machine and a state structure.  More, as Henry Kissinger discovered to his frustration, a hostile bureaucracy can frustrate and sabotage a brilliant leader’s initiatives in many ways.  Commands given by a great general or initiatives envisioned by a great diplomat must under modern conditions be executed by great throngs of non-genius employees and functionaries.  There is no other way.

Remember this: your idea has to be executed by people who do not necessarily share the entire scope of your vision. Via Clausewitz: Master of War | Via Meadia.

Crockford on Quality and Style

Some of the best few paragraphs on codebase quality and style I have read in a long time:

Computer programs are the most complex things that humans make. Programs are made up of a huge number of parts, expressed as functions, statements, and expressions that are arranged in sequences that must be virtually free of error. The runtime behavior has little resemblance to the program that implements it. Software is usually expected to be modified over the course of its productive life. The process of converting one correct program into a different correct program is extremely challenging.

Good programs have a structure that anticipates — but is not overly burdened by — the possible modifications that will be required in the future. Good programs also have a clear presentation. If a program is expressed well, then we have the best chance of being able to understand it so that it can be successfully modified or repaired.

The long-term value of software to an organization is in direct proportion to the quality of the codebase. Over its lifetime, a program will be handled by many pairs of hands and eyes. If a program is able to clearly communicate its structure and characteristics, it is less likely to break when it is modified in the never-too-distant future.

From JavaScript: The Good Parts (chapter 9, “Style”) by Douglas Crockford.

Blogger outage makes case against cloud-only

Earlier this week, Google rolled out a maintenance release for its Blogger service. Something went terribly wrong, and its Blogger customers have been locked out of their accounts for more than a day. Google’s engineers have been frantically working to restore service ever since, although they haven’t shared any details about the problem.

That’s nearly 48 hours of downtime, and counting. Overnight updates promise “We’re making progress” and “We expect everything to be back to normal soon.”

Google has owned and operated Blogger since 2003. It’s not like they’re still trying to figure out how to integrate the service into their operation. If it can happen at Blogger, why can’t it happen with another Google service?

This, to me, is the strongest possible argument against putting everything you own in the cloud. If your data matters, you need a hybrid strategy, with local storage and local content creation and editing tools. If your local storage fails, you can grab what you need from the cloud. If your cloud service fails, you’ve still got it locally. But if you rely just on the cloud, you’re vulnerable to exactly this sort of failure.

via Google’s Blogger outage makes the case against a cloud-only strategy | ZDNet.

I Like My IT Budget Tight and My Developers Stupid

If you don’t give staff time to recharge their batteries, they burn out. It’s one reason why Goerlich requires his staff to put aside 20% of their time for skills development. He hit on that number back when he ran a consultancy. In those days, he’d have a certain type of consultant out billing “rock-solid” hours, flat-out, wall-to-wall.

They tended to be the young ones.

They’d last six months.

Goerlich noticed that his consultants who weren’t maxing out on hours were hitting the mark at about 60% billable hours. Those people spent about 20% of their time recharging. “Those are people that, year after year, they didn’t have high peaks, but they maintained billables in the high level—say, the top 10%—while the others were going gangbusters for six months and burning out.”

Goerlich wants his current team to match that: Put the majority of yourself into your projects, then put at least 20% aside to get training and to just plain catch your breath.

“There’s a lot of work to get done,” Goerlich said. “It’s almost like a Chinese finger puzzle: You pull too hard, and you can’t get out. You put in too many hours, you get diminishing returns.”

He hasn’t lost a key member in a tenure of five years. He credits the training regime as one of the reasons the financial services firm has a high level of IT staff retention. “I tend to have a very motivated team,” he said. “It astonishes me how much they put into the environment, into their jobs. But then, it’s very stressful to try to do work when you don’t know what you’re doing. If you don’t have the confidence that you know what you’re doing, you can’t be creative.”

via I Like My IT Budget Tight and My Developers Stupid. Hat tip to Cal Evans.

Different Definitions of Quality

Recently, I was pondering why it is that programmers and employers have different attitudes toward the quality of the projects they collaborate on. I formulated it like this:

  • The people who do the work are usually the ones who care more about quality. Why?

    • They have a reputation to maintain. Low quality for their kind of work is bad for reputation among their peers. Note that their peers are not necessarily their employers.

    • They understand they may be working on the same project later; higher quality means easier work later, although at the expense of (harder? more?) work now.

  • The people who are paying for the work care much less about quality. Why?

    • The reputation of the payer is not dependent on how the work is done, only that the work is done, and in a way that can be presented to customers. Note that the customers are mostly not the programmer’s peers.

    • They have a desire to pay as little as possible in return for as much as possible. “Quality” generally is more costly (both in time and in finances) in earlier stages, when resources are generally lowest or least certain to be forthcoming.

    • As a corollary, since the people paying for the work are not doing the work, it is easier to dismiss concerns about “quality”. Resources conserved earlier (both in time and money) means greater resources available later.

Dismissing quality concerns early may cause breaks and stoppage when the product is more visible or closer to deadline, thus leading to greater stress and strain to get work done under increasing public scrutiny. The programmer blames the lack of quality for the troubles, and the employer laments the programmer’s inability to work as quickly as he did earlier in the project.

Two Different Definitions

While the above analysis may be true, I realized later that I was approaching the problem from the wrong angle. It’s not that one cares more about quality than the other. Instead, it is that they have two different definitions regarding project quality.

  • The programmer’s “quality” relates to the what he sees and works with regularly and is responsible for over time (the code itself).

  • The payer’s “quality” relates to the what he and the customers see and work with regularly and are responsible for over time (what is produced by running the code; i.e., the product, not the program).

That’s the source of the disconnect. When approached in this way, “quality” as judged in one view is now obviously not the same thing as when judged in the other view; code quality and product quality are distinct from each other (although still related).

One interesting point is that the developer has some idea about the product quality (he has to use the product in some fashion while building it), but the manager/employer/payer has almost no idea about the code quality (they are probably not writing any code).

The solution to the disconnect in software development may be to involve someone who understands both sets of concerns, and who has the authority to push back against both sides as needed. Then the business as a whole can address the concerns of both sets of people.


1. Thanks to Brandon Savage for reading and commenting on an earlier version of this article.

2. Incidentally, I think the “quality” definition disconnect also applies to various non-software crafts and trades. You hear about carpenters, plumbers, painters, etc. complaining that they get undercut on prices by low-cost labor who don’t have the same level of quality. And yet the customers who choose the lower-cost option are satisfied with the quality level, given their resource constraints. The developer-craftsman laments the low quality of the work, but the payer-customer just wants something fixed quickly at a low cost.