“Software is Easy, People are Hard”

It’s (maybe not so?) surprising how contentious the above statement can get. Bring it up with most people, and expect responses responses on a spectrum, with one end consisting of Libertarian-types who hate the very concept of Management, and the other end consisting of Dictatorial ass-hats who are convinced that things would be just fine if only people did exactly what they were supposed to in the project plan!!!

The thing though, is that there is an element of truth in the above statement, depending on how exactly Software and People are defined. As with all things, semantics matter 🙄.

So, let’s break “Software” into two categories

• Engineering: The process of finding the appropriate solution to the problem at hand. Frequently, this also involves figuring out what the problem is in the first place!
• Coding: Implementing the solution that was identified in the Engineering step above.

When broken out like this, Coding is “hard” in the sense that there is skill involved. It may take years — or 10,000 hours — to become great at this, but it is still largely a factor of time. Engineering, on the other hand, is just plain hard! A huge chunk of becoming a good engineer consists of solving multiple problems in this and other fields, in learning formal methods to approach problems, in rigorous discipline, in categorizing and identifying solution spaces, in avoiding rabbit-holes, and, frankly, by screwing up a lot (we do learn better from our mistakes!).Whereas Coding is mastered through depth, engineering is mastered in breadth.

But (and a mighty huge “But” it is!), the vast majority of the Engineering problems that we deal with are really straight-forward. Oh, we’d like to think that we spend our time implementing formal verifiers for payment protocols, but the reality is that most of us are just trying to figure out how to get the stupid CSS element to shift a wee bit to the left 😨.So yeah, Software is easy. Mind you Software being easy also means that it is easy to do really stupid things, and end up in a world where maintaining that CSS is a nightmare beyond all mortal comprehension, but hey, them’s the breaks.

All that said, consider what it takes to get a bunch of Engineers and Coders to work together towards a common goal. In a perfectly rational world, this would be quite straightforward, but hey, this is not that world! To get anything accomplished, you nee dto

• _Motivate each of them individuall_y. Some of them respond to one or more of the Cardinal Sins (Lust, Greed, Envy, etc.) while others prefer Virtues (Kindness, Patience, Diligence, etc.). And gods forbid you mix up the motivational patterns!
• Motivate them as a group. Ensure that the ones that need interactions get them, the ones that don’t are closeted away, that the over-bearing ones don’t impose their wills on everybody else, etc. All these interactions result in their own feedback loops, which can affect what motivates the individuals (“Why does Bob get to lead that component? Alice is better suited! Now I’m depressed and am going to sulk”)

Unfortunately, unlike herding cats, this is an exercise that never ends. Whats more, the thing to remember is that these are humans that we are talking about. Humans, whose wants, needs, desires, etc. change constantly. Regardless of the management methodology you espouse — dictatorial vs nurturing — you still need to know and deal with these motivations to be able to succeed. (_Unless, of course, people are cannon-fodder to you, in which case please go away, I have no time for you_😡)

So yeah, given the above semantics, Software is Easy, People are Hard.

(This article also appears on my blog)