I haven’t found a metaphor for programming that adequately describes its effect on business, maintenance, products, and developer sanity.
Manufacturing is probably the most used metaphor, and that tends to work for about as long as it takes to scream the words “mythical man month”, and with smarter people, that’s the end of that metaphor.
Then there’s gardening, or house building, or art, or carpentry, or some other activity that is superficially like programming. I use golf as a metaphor. It’s an activity that requires following an exact procedure in a constantly new situation, it is largely mental, and there’s a physical limit to how long you can do it. It’s expensive, requires lots of practice, and to someone who has never done it before, it looks easy. It is also a personal activity, and there’s little use comparing two programmers, even under the exact same conditions. People who aren’t doing it wonder what the trouble is, and people who do it can’t begin to explain how a leaf in the wrong spot can change everything.
Difficulty
Watching golf on TV is boring if you’ve never golfed, much like watching someone program. One aspect of golf that doesn’t translate to TV is just how hard they hit those golf balls. The ball itself makes sounds as it passes people. I’m not kidding. I can’t explain just how amazing watching a good golfer play is, and since you’re probably not likely to do it on your own, we will just have to take my word for it.
One area where golf really shines is that when someone is a good golfer, there are statistics to back them up. Greens hit in regulation, scores, fairways hit, up and downs, all of it. We really don’t have the same sort of stats for programmers, do we. Even as I think about it there’s no immediate statistics that come to mind that would be universally applicable. Bugs per 1kloc? Mean Time to feature completion? Revenue per 1kloc? Maintenance score? Story point average? Even if we could normalize these numbers across the industry there’s no authoritative source to say what’s valuable.
By and large golf is a solo activity. Others can (and do) help you decide on your strategy, but it’s up to you to execute it. Following someone else’s strategy blindly often results in a bogey, or worse. The effects of cargo-culting play out in real time as your ball goes sailing into the deep stuff. Bad decisions in golf can be cumulative, but after 4 and a half hours, you’ve made all the bad decisions.
All metaphors fail, and I suppose this is where the golf as programming metaphor fails. We should all be so lucky to see the effects of bad decisions after 4.5 hours in programming. Often the outcomes are small annoyances that add up, or a bad product direction that takes years to correct. There is no fast feedback in programming for bad technical decisions, and product decisions even less so. Everyone knows this, and everyone reacts to this reality differently. Project managers try risk registers, CTOs micromanagement, Architects enforce coding standards that have nothing to do with the problem at hand. Each party tries to control what it has dominion over. At least in golf, once the ball is in the air there is nothing you can do to retain control over your bad decision.
Course Management
In golf, there’s a phrase that is used to manage this phenomena, “course management”. At its heart, the strategy is to play to your strength and to the numbers. If you’re driving a 450 Yard par 5, you may as well hit 3 7-irons and make it on the green in 3. The 7-iron is one of the easier irons to hit, and your rational brain knows you aren’t making it in two anyway. It’s a lot safer to hit 150-150-150 than it is to try to drive 225-180-45. Most golfers can’t reliably hit woods and low irons (Golf clubs go from low numbers which can hit further to high numbers which can’t hit as far), and the flight of the ball is harder to control. Another side-effect of using the 7-iron is that if you need to readjust for your second and third shots, it’s easier to do so.
This is a well known strategy, carries little risk, and usually isn’t followed. Reasons vary, but distilled it comes back to ego, pride, and a foolish sense that this time it will be different. I know the strategy and even when nothing is at stake I have a hard time following it. I compare my skills to those next to me and so I try to play the same way they do, even though I’ve broken 100 a grand total of 1 time (I think. That’s 28 over par, in case you were wondering, or averaging 1.5 strokes over par per hole). I am over-confident in my abilities, all evidence to the contrary. I see myself through their eyes; and want to impress them with my ability, and so I pull the driver out of the bag and use it, even though my hit rate with the Driver is 15% (I’m shockingly bad with a Driver, to the point that I now typically “drive” with a 3-hybrid). Going for the big hit doesn’t work if you’ve not successfully executed big hits in the past on a regular basis.
Golf has the privilege of being a self-contained activity that’s at the mercy of external forces. It doesn’t matter how well you execute your shot if there’s a 40mph cross-wind, and yet the best you can do is adjust to changing factors and pray. It’s like business in that regard. Technical decisions aren’t made for technical reasons alone. Choosing microservices may be due to a business requirement that teams are operating in parallel; or it may be because a monolith wasn’t “nextgen” enough. Or both. Adding on business and product decisions to them and it’s impossible to be sure the decision is correct. At some point you have to swing the club to find out. Except the ball is your MVP, the wind is your business’s inertia, and the ball is heading into the woods.
Business decisions are critically important to the software we create, and yet I’d wager that for most developers you probably don’t realize what your most pressing business objective is right now. That’s ok, the code is hard enough. Strangely, the opposite is also true. Business people watch programmers in the same way tv viewers watch golf. It’s just typing, or it’s just a new menu, or it’s just restricting what a user can do after business hours. And just like golfers, we tell them it’s not that easy, but of course seeing is believing. The bad news is that it takes several people-months to show them how hard it is to fulfill their request. Software development has its own version of course management, called agile. Just like the green in three approach, it seeks to reduce risk by putting the effort and expected outcome in reach of everyone. Break the problem down into manageable and achievable chunks and work towards those. We may fail, but the cost of failure is smaller. It allows software development teams of all skill levels to succeed, even teams that are in an unknown problem space. It really is the safest way to ensure failure chances are minimized and success is maximized.
Just like course management, agile only works if everyone commits to it. The caddy, the golfer, the people on TV, and the announcers. The management, programmers, the industry, and executives. The consulting industry has sold business that ‘agile’ means ‘going faster’, or ‘doing more with less’. Neither is true, and a great amount of ink has been spilled disproving these myths. Software developers, disillusioned with the promises of agile development (notably the Scrum framework) combined with executives not truly buying in to the change, have decided to become “post-agile”. Executives revert to the tried-and-not-so-true method of asking for too much, Managers revert to command and control, and the industry apes what they see, because they think it’s successful.
Closing
The problems we encounter are at the seams of each discipline. We understand programming is hard and requires exacting specifications, and we understand that business people need to see a return on their investment. What we aren’t able to do is to align all of these forces cohesively. Post agile is great for developers. It’s great for remote work. It doesn’t solve the problem on measuring return on investment, because that’s not what it’s meant to do. It doesn’t solve the problem of establishing trust between business and development, because that’s not what it was meant to do. Agile development, for all its flaws, attempted to establish trust between developers and business, and to make development better for both the business and developers. The promise of agile has succeeded when it’s been adopted by everyone in the organization; when everyone puts aside their egos and recognizes that past performance is an indicator of future performance; when businesses ask for bite-sized pieces of functionality instead of features that take people months to accomplish. It has succeeded, and it can succeed.
What we’re missing is the metaphor that would convince business people and executives that software is hard, and to ship early and often, there is both vision reduction and tooling needed. That practice and training is vital to performance, and that practice must come on company time. That working longer hours will make things worse; and adding people to the problem won’t deliver features faster; or that not correcting bad technical decisions has disastrous effects. We don’t have that metaphor, and without a good metaphor, it’s hard to have a shared understanding. We’re stuck with the same tools we’ve had: Build trust, ship, and use personal relationships to convince individuals of what works. It’s not systemic, but it could work.