Fashion’s never finished

It won’t be finished. It’s like fashion; fashion’s never finished.

The scene above is from the Social Network, one of my favorite movies. It’s an easy pick: Sorkin (writer) & Fincher (director) are card-carrying veterans of Hollywood’s A-Team, and they didn’t disappoint: the dialog is great, scoring outstanding, and storytelling, compelling. But what makes it a personal favorite was its sheer accuracy. No other film about technology, has managed to capture, with such accuracy, the feel of early-stage tech. Who hasn’t wanted to “break out the emacs and modify that perl script”, or felt the need for a “dedicated Linux box running Apache with a mySQL backend”?

But it’s not just the technical details; it’s the character work, and the conflicts. The scene above is great: Eduardo, portrayed as a traditional buttoned-up business guy (literally), wants to go out and sell ads, and wants commitment — a when — for customers. Zuckerberg pushes back: there is no “when” because there is no “done”. You can understand a lot of what goes wrong with software development, especially in big companies, if you take time to understand this conflict.

They key is to stop thinking in terms of “projects”. It’s a simple idea, yet, incredibly hard to pull off, because “projects” are so ingrained in traditional business culture.

How we got here: buildings, planes, and bridges

The “software industry” is pretty new. People were writing code in the ’50s or ’60s; things were in pretty full swing by the time Microsoft got started, in 1975. So we’ve been doing this 50, maybe 60 years. We’re getting through it, but we’re still pretty clueless.

Cluelessness exhibit A: job titles. Are people who make software “developers” (my preferred term) or “engineers”? I think software is “designed” or “written”, but not “engineered”. Many people think I’m wrong, probably because “spending a ton of money, to build a big thing that does lots of stuff, over many years” sounds suspiciously like “engineering project” to people who write checks. It looks like an engineering project, they say, so it should be handled like one.

And oh man, is this can-of-worms territory. The fundamental problem: software isn’t a homogeneous category. On one end, stuff like operating system development, stuff like Windows, with nine-figure budgets, thousands of people, and years of work, I might call “engineering”. But that’s not the reality for 90, maybe 95% of the industry, the part that develops order entry software, e-commerce websites, and registration systems. The work there is something else, more like (building) architecture, or maybe graphic design.

The tell-tale signs of a true “engineering project”:

• Upfront commitment of huge amounts of money: millions/billions of dollars
• When successful, they “finish”, “open”, or are “placed into service”
• They deliver no value while under construction (nobody drives on a half-completed bridge)
• They have “phases”, which, once completed, aren’t restarted. (Example: in construction, “design”, “permitting”, “build”)
• They’re expected to last years, perhaps decades
• They’re physical, tangible things

Sounds like waterfall, doesn’t it? It’s because that’s how most of the engineering world operates: things are designed, then constructed, then tested, in a process where change is expensive, people work specialized jobs that don’t cross phases (i.e. construction people don’t participate in design), and lots of upfront commitment is required.

It’s not surprising people try to shove software into this framework. Some of the time it even works, which makes it hard to oppose. But as tools get better, cycle times get faster, and managing essential complexity becomes job #1 for every developer, the game is less “engineering project” than…something else.

This is where we need to take stock of modern software development, and realize we aren’t engineering, but designing.

If not engineering, then what?

Take a minute to consider web-delivered software like facebook. In comparison to the bullets above:

• No upfront commitment is necessary. The process is: build something small, test, measure, and learn. Meaningful feedback can be had for thousands of dollars.
• Delivery, or even deployment, is a continuous process
• Features are sequenced to delivery value early, and fast
• There are no phases
• Code must be continuously revised for new platforms, devices, operating environments, security issues, etc. Bugs must be fixed as discovered. Things “erode”.

You don’t need heavyweight project planning when shipping this kind of software. You just sort of start, collect feedback, and keep going. You win by making more of what customers want, and getting it in their hands more quickly than the competition.

But, again: simple, not easy. The trick is sequencing; as I’ve said before, pretend you’re building a city: start with a solid, small core of functionality, add on to it over time, and avoid rework.

A couple of tips to make this easier follow.

Takeaway #1: Planting flowers vs. pouring concrete?

I find this metaphor (flowers vs. concrete) helpful.

Most software I write is like gardening. You have to guide its growth, but beyond that, change isn’t too difficult. Development doesn’t require days of planning.

Things get harder when change is more costly. Examples of costly change: buying hardware in a datacenter, changing an SDK, API, or library used by thousands of partners with a multi-year support cycle, most things involving hardware, anything involving other companies, contracts, or large amounts of money.

Match the weight of your process to the cost of change. I’m reminded of Mastercard: “For some things, there’s heavyweight project management (e.g. waterfall); for everything else, don’t bother”. It’s worth bothering if you’ll have to live with it for years, or there’s a risk a change could break a bunch of dependencies.

Takeaway #2: Break into teams that run at the same speed

As a software effort matures, some parts of it (likely those higher up in the stack, closer to the end-user) will adopt a faster iteration cadence. Lower down, closer to the datacenters, databases, and tech ops, things might be closer to “engineering”.

The solution: have multiple teams. At facebook, “product” runs faster and closer to the user, and “infrastructure” is lower down. Moving at different speeds lets the pixel-pushers change color and style with characteristic abandon, without upsetting the neckbeards responsible for multi-TB database deploys/maintenance; that stuff takes time, dammit.

Takeaway #3: Change how you budget

Acquired software might be budgeted as capital expense, but in-house development is operating expense. Period. Treating software as capital expense is perhaps the original sin of this entire problem; the minute something is labeled capital expense, it’s a “project”, and naturally, that means “project management”: completion dates, timelines, the expectation that spending will stop after delivery.

Software is operating expense because it’s never done. There are always new features to add as things change. It has to be operated. And every day it isn’t maintained, the world shifts, new operating systems are released, programming languages change, and new deployment tools become popular. If you don’t stay on top of this stuff, the code will fossilize and you’ll end up paying some graybeard consultant obscene sums of money to work on a high-stakes Jenga tower that’s entangled in some critical piece of your business (otherwise, why would you care?). Nobody will know how it works, touching it will become scary, and changes that might take a few days under ideal conditions will start to take months or years.

Imagine an entire company full of this, and it’s not hard to see how speed and agility suffer. It’s the default state in mature companies, where cost reduction is the goal because there’s no top-line growth. These tradeoffs render innovation and change all but impossible.

Takeaway #4: Beware “project culture”

When things go off the rails in software — and I’ve seen them go off the rails — it’s tempting to say, “we need better project management”.

More control, more meetings, more planning. More like a traditional engineering project.

Be careful; the problem might not be a lack of control, but rather, the wrong approach. Thoughtworks calls the problem “products, not projects”, indicting wholesale the entire project-based approach common outside of technology companies. Martin Fowler wrote the best essay I’ve seen on the topic: “products over projects”.

One last thing. Craftsmanship counts. The very essence of craft is expensive, fussy specialist labor, and business hates this. To a typical line manager, the idea that success depends more on the whims of a bunch of expensive prima donnas, than following the right project management methodology, is a hard pill to swallow. Unfortunately, that’s reality, and if you want to win, you’d better know how to get the best people.