[Update: This post (and the philosophy it described) was formerly titled Human-Driven Development, but I’ve since realized that Humane Development is a better term to describe its goals, so it’s been updated accordingly]

Since taking on my role at nVisium, I’ve been given wide latitude to influence company culture in ways I haven’t experienced before. This is a great thing, but it means that if I’m unhappy with how things are going from a culture standpoint, there’s a pretty good chance that I’m directly to blame.

That’s a lot of pressure, so I’ve been doing a lot of thinking. The bulk of my thoughts keep relating back to something I’m calling “Humane Development.” I’d like to share those thoughts with you, since you are (most likely) a human.

What’s in a name?

As we all know, naming things is hard. It feels like all the good names are taken. The term “Humane Development” is no different, and a quick search yielded a handful of different uses for the term.

I don’t care if it’s taken. I can’t think of a name that better embodies what I’m trying to say.

Humane Development, to me, means the acknowledgement that we are humans working with humans to develop software for the benefit of humans.

It sounds trite, doesn’t it? It may be easier to explain why I think it’s important with a counterexample from the worst job I’ve ever had.

I was once put in a leadership position with responsibilities that ended up depriving me of most of my direct development time. I expressed this frustration to my CEO. His response?

“You’re thinking of this all wrong. Think of it like another development task. Your team members are objects in the system and you’re doing engineering just like you would with software.”

Suddenly it all made sense to me, though probably not in the way he was intending. I was miserable here because the philosophy from the very top fundamentally deprived my coworkers of their humanity. This resulted in a culture that valued, in part:

• speed over sustainability
• appearances over accuracy
• metrics over mental health
• process over people
• controlling over caring

More concerningly, it was contagious. I watched as people worked themselves to within an inch of their sanity, as though no other path could lead to success. As someone who’s been a volunteer counselor for around 6 years now, and an unintentional counselor for much of my high school career, maybe I’m just more sensitive to this stuff than others. Whatever the case, watching it was painful, and encouraging it was something I was unwilling to do.

The startup world has a term for this. They call it “hustle.”

The notion of hustle-as-a-virtue is one of the most damaging memes afflicting software developers today. It seeks to trade unsustainable tactics and pace for outsize payoffs, racking up debt, both relational and restful, in the process.

Humane Development, on the other hand, says that the ends don’t justify the means.

It’s Not a Sprint, It’s a Marathon

The agile world loves to sprint. You probably work (or have worked) somewhere that plans their development in terms of sprints. In practice, this is how it works: your team bites off a small chunk of work. That chunk comes from the top of a backlog that has been prioritized by someone else or according to the needs of The Business. “The Business” is code for “my boss’s boss’s boss” or “Bob in marketing”.

This sounds good on the surface. Like a real sprint, the finish line is visible. The problem is that in a real sprint, you’re going as fast as you can to reach that finish line, and after that, you get to rest. Software development is nothing like a sprint. It’s not even a relay race – unless you’re handing the baton off to an even more exhausted you at each checkpoint. Software development is a marathon.

Marathons and sprints are very different things. In the middle of a marathon, I’ve been told, the finish line is as much an abstract concept as it is a tangible object. Your job is to put one foot in front of the other, heading in the right direction, knowing that consistently doing so ensures the finish line’s inevitable arrival.

In a marathon, an unsustainable pace is less than worthless. Likewise in software development. The human beings we want to be, and want to work with, are mature enough to be allowed in on the big picture reasoning behind decisions because they find that knowledge motivating. They’ll make better decisions as a result, learn to pace themselves accordingly, and need less management, overall.

No Arbitrary Deadlines

From the time we were little, we learned to ask, “why?”

The impulse doesn’t go away. Humans want to know the reasons for the things we do.

Out of respect for each other, we should give reasons for any deadlines we set. If we can’t articulate the reason for the deadline, then we should ask, “why?” ourselves. “We need to do X by this date so we can do Y by this later date” is not a reason why. Avoid cascading “reasons” that require a reason all their own. “Because I said so!” is an insufficient answer for a grown-up.

We should recognize that circumstances surrounding our reasons often change, and that may require an adjustment to deadlines. There are really very few “hard” deadlines, so when they exist, they should stand out as exceptional. For instance, in a previous job, some software I was writing was required in order for us to send out a holiday-themed series of e-mails expected to bring in significant revenue. Since my company lacked the power to change the date of Christmas, this was a hard deadline, and I treated it accordingly.

Stop Crying Wolf

“When everything is urgent,” they say, “nothing is urgent.”

While along the lines of the deadline topic above, it’s worth drawing special attention to the importance of reserving the term “urgent” for truly time-sensitive issues. If it can wait, let it wait. People will be much more likely to respect an urgent request if you don’t have them constantly on high alert.

Honesty Really is the Best Policy

Just as we should be honest about deadlines and what really is urgent, a more general statement about honesty is worthwhile. Developers should be encouraged to be honest about their estimates, capabilities, concerns, and so on. So long as opinions are being expressed constructively, they’re valuable. And if someone simply can’t find a constructive way to frame something they need to be honest about, that’s worth examining, as well. How did things get to that point?

Don’t “deliver” features via smoke-and-mirrors implementations designed solely to illustrate forward progress in a way The Business can understand. Explain the nature of the work that needs to be done, and set expectations regarding availability of user-facing features appropriately. Nobody should ever be shamed for being honest, and the end product definitely shouldn’t suffer because someone “needs to see proof of progress.” If there’s a trust issue, address the trust issue head on.

Remember that we’re serving the humans using our software, too. If reasonable steps can be taken to get a feature in front of users sooner rather than later, in phases, then do so. It’s the right thing to do for them.

Crunch Mode is a Production Error

It’s better to have an environment in which heroes are not needed than a team full of heroes. As such, when crunch mode becomes necessary, a Humane Development shop considers it a production error. Whether a failure of systems, processes, or communication, a post-mortem analysis should be conducted to find out how it came to crunch mode, and what can be done to prevent the problem from happening again, as it would for any other error affecting production.

Be Skeptical of Named Development Processes

I realize the irony of a heading encouraging skepticism toward named development processes in a post titled “Humane Development.” I’m okay with it. You should be skeptical of Humane Development, too.

My friend Chad Fowler recently wrote an article that touched on this topic. He discussed the problem with giving names to ideas, concluding with:

I can “do BDD” in the same way that I can sign up for a membership at a gym. I feel the sense of accomplishment without the need to actually get healthy.

— Chad Fowler

Once given a name, development methodologies seem to rapidly devolve. Adherents begin wrapping rigid processes around the more general framework of values initially adopted. Adherence to a process so a box can be checked off starts to trump sustainability and, more importantly, sensibility, for the humans involved.

Inevitably, development teams, being writers of software, start building software around the process. Which brings me to my next point…

Be Skeptical of Tooling

The problems with tooling around development processes are manifold.

Let’s consider a case where the dev team has decided to develop “ScrumBan AgileTracker”, a custom tool to aid in planning and tracking project work. This kind of software goes through 3 distinct phases:

1. Reflect the process: The tool codifies the process that’s already being followed in practice.
2. Become the process: The tool becomes synonymous with the process. “In ScrumBan AgileTracker, go to the ‘Agile’ tab…”
3. Define the process: The process is defined by the capabilities of the tool. The path toward changing the process becomes changing the tool.

As it moves through these phases, the software stops serving the humans, and the humans start serving the software. Circumstances change all the time, but we know from experience that no matter how hard we try, we tend to suck at writing software that’s easy to change.

Even if we’re great at writing software that’s easy to change, we still get invested in the decisions we make and the code we write. These traits eventually transform a process that started out as human-focused into a yoke around our necks. It’s easy to shift blame to the tooling as opposed to the choices being made every day by the people, or to delay necessary changes while waiting on time to update the tool.

It should follow, then, that if software that’s been custom-written to serve the needs of your company eventually gets in the way, software that was written by a third party to support a specific workflow would be even more problematic.

That doesn’t mean there aren’t good tools out there. Just look for (or develop) tools that do less. And don’t get suckered in by tools that claim to do everything, but be configurable to perfectly suit your organization’s needs. Any tool claiming to be that configurable is a de facto programming language. It just hides its “source code” in configuration files or configuration screens. That way lies madness.

Also, consider whether the requirement for specialized tooling just to coordinate your development process might be an indicator that your development process is too complicated to begin with.

Encourage Autonomy

Have you heard the term “learned helplessness” before? The studies are pretty heartwrenching to read about. In them, animals are placed in situations where they repeatedly encounter an “aversive stimulus” (where “aversive” is a euphemism for “painful”) with no opportunity to escape it. After time, even when given an opportunity to escape the pain, the animals won’t do so. They literally learn that they are helpless to change their situation, and needlessly suffer as a result.

Like I said, heartwrenching stuff.

Later experiments showed that these findings carried over to humans, and that a key differentiator in how humans respond to adverse situations is the perception that they have the ability to change the situation.

You may think “well, sure, they can always quit if they don’t like their job,” but that’s a pretty poor option. Software development is an amazing job that naturally offers a ton of flexibility. Humane Development encourages developers to work:

• when they want to
• where they want to
• how they want to
• on what they want to
• with whom they want to

All of these within reason, of course. I’m not advocating anarchy, but wide latitude on things that have some flexibility. If you’re being honest about deadlines, urgency, and so on, it should be obvious which things are flexible.

Productivity can vary widely from day to day, even hour to hour. Sometimes entire days can go by with little to show, and then a light bulb goes off and a nearly complete solution is written in the course of several hours. It’s hard to predict that sort of thing, but one thing is certain: sitting a butt in a chair does not magically produce work. Focus on results, not time spent. If a developer doesn’t feel she can go off and do a bit of needed research because she won’t have enough commits for the day, you’re doing it wrong.

It’s no secret that I think requiring developers to work on site is a joke. Let developers work where they’re happiest. They’ll do better work that way. If you can’t trust them to do the work without being on-site then you shouldn’t have hired them to begin with. Establish a remote-friendly culture and don’t allow remote employees to be left out.

• Communicate asynchronously and using public channels like chat rooms when possible
• Have face time via FaceTime (or Google Hangouts, or Sqwiggle, or whatever works for you)
• Pick up a (gasp!) phone
• When all else fails, or you just want to do some teambuilding activities, put your team in some of those amazing metal tubes that hurtle through the air

A side-effect of building this kind of culture is that you “accidentally” build a team of excellent communicators. Since programming is written communication, you want your team to be excellent at communicating. This builds trust that when people need to know something, they’ll know it. That makes it a lot easier to follow this next principle…

Availability over Omnipresence

Every company has this person. Maybe you’re this person.

They’re always around. You see e-mails from them at 3AM, they’re posting in team chat at 11PM, and committing code at noon. Are they participating in some kind of sleep deprivation study? You don’t know, but they make you feel the concept of “work/life balance” is for lazy people.

They’re omnipresent. Maybe they think the organization can’t survive without them. Maybe they’re right – that’s a problem in itself. The worst kind of omnipresent person seems to be proud of playing the hero. They make sure they have the timestamps that prove their dedication to the cause.

Never mind that this person has probably stopped being genuinely productive after, say, hour 7 of their 20-hour workday. They’re always online. Clearly the rest of the team isn’t pulling its weight. Collectively, this kind of behavior raises the stress level of conscientious team members.

The thing about “thought work,” as it’s come to be called, is just that: you’re working when you’re thinking. This makes it exceptionally difficult to unplug. In fact, many of my best ideas come while processing the problem passively. There’s even research to prove it:

In creativity research, we refer to the three Bs—for the bathtub, the bed and the bus—places where ideas have famously and suddenly emerged. When we take time off from working on a problem, we change what we’re doing and our context, and that can activate different areas of our brain. If the answer wasn’t in the part of the brain we were using, it might be in another. If we’re lucky, in the next context we may hear or see something that relates—distantly—to the problem that we had temporarily put aside.

— R. Keith Sawyer

Because of this, we’re all pretty much always working. In Humane Development, we should recognize that. Instead of striving to be constantly visible, we should focus on being available. If there’s an emergency, team members should know who to contact, and how (hint: it’s not e-mail). Protect one another from burning out by watching for signs of omnipresence and encouraging them to sign off. Remind them that when they sign off for the night, they’re not being lazy. They’re letting other parts of their brain do some of the work. The results should speak for themselves.

None of this has even a remote chance of working unless the organization, from the top down, embraces this principle. If you’re in a leadership position, lead by example. Consider delaying or scheduling the sending of an e-mail or the timing of a commit, even if you performed the work after hours or on the weekend during a burst of productivity, at least until you’re sure the team has caught on that just because you had a burst of inspiration at 2AM doesn’t mean they should have.

Summary

Humane Development values:

• sustainability over speed
• communication over colocation
• helpers over heroes
• comprehensibility over comprehensiveness
• accuracy over appearances
• mental health over metrics
• people over process
• caring over controlling

Thanks for reading.