Ernie Miller
Humane Development
#agile
#software-development
#engineering-culture
#team-dynamics
#emotional-intelligence
#human-centered-design
Summarized using AI
Humane Development
by Ernie MillerThe video "Humane Development" presented by Ernie Miller discusses the importance of acknowledging the human aspect of software development amidst various methodologies like Agile, Scrum, and Kanban. Miller argues that while these processes aim to streamline development, they often dehumanize individuals involved, reducing them to mere resources or objects, which adversely affects team dynamics and productivity.
Key points discussed include:
- Personal Experience: Miller shares his transition to the role of Director of Engineering at Invisium, highlighting the pressure and the realization that if things went wrong, it was ultimately his responsibility.
- Cultural Considerations: He reflects on the type of work culture he values, emphasizing the significance of human interaction and empathy in software development.
- Dehumanization Through Processes: Miller recounts an experience with a CEO who viewed team members as objects within a process, leading to an oppressive environment.
- The Concept of "Humane Development": He introduces the term to stress the importance of retaining the human aspect in development methodologies, arguing that software development should ultimately serve people, not just processes.
- Issues with Current Methodologies: The discussion touches on how Agile practices have been misinterpreted over time, with a focus on measurement, predictability, and control, overshadowing the underlying values of collaboration and flexibility.
- The Importance of Empathy and Communication: Miller advocates for empathy, honesty, trust, and autonomy as foundational values in a healthy work culture, asserting that effective communication can bridge gaps between business needs and development.
- Sustainability vs. Hustle: He critiques startup culture’s glorification of hustle, emphasizing that sustainable work approaches are more beneficial than simply moving fast and breaking things.
- The Question of "Why": Emphasizing the importance of understanding the underlying reasons for tasks, Miller encourages developers and managers to always seek the rationale behind tasks to ensure meaningful productivity.
Miller concludes that software development is fundamentally about humans working with humans for humans, which requires a shift away from mere process adherence to a more humane approach. His key takeaway is the need for a cultural transformation within organizations to prioritize human values over rigid processes, fostering environments where innovation and empathy can flourish.
00:00:08.960
Um.
00:00:23.199
Hey, how's it going, guys? I work for Invisium, where we do application security stuff, and it's great.
00:00:28.720
They hired me as director of engineering, which is fantastic, except that it turns out there is no chair and no megaphone in the picture. Instead, what I got was crushing pressure.
00:00:36.320
What it turns out happens if you're the director of engineering is that you don't have this common fallback I've always had in the past.
00:00:41.520
When I've been unhappy in previous jobs, I've always been able to fall back on one simple truth: it’s not my fault.
00:00:46.960
It's not my fault that things are terrible somewhere; it’s someone else's fault. It might be the CTO’s, or the director of engineering’s, or, you know, often it's Mike's fault when things are horrible.
00:01:05.920
I'm not particularly proud of that — it’s not a proud moment to say I fall back on it not being my fault — but I don't necessarily think I'm alone in the room. If you're honest with yourself, most of us do this.
00:01:22.080
In fact, I would say, as engineers, how many of you — and keep your hands up — how many of you in this room have been at your job for less than one year? Less than two years?
00:01:27.600
Keep your hands up. Yeah, most of the people in the room have their hands up; most of them actually raised them for one year.
00:01:36.320
So it's really easy to walk away and say, ‘Well, I tried, it’s just not working out.’ I would be willing to wager that one hundred percent of the people who raised their hand took themselves with them when they left their job.
00:01:51.360
It’s a pretty safe bet that they didn't think they were the problem. But at Invisium, I was hired to help build the software, the team, and the culture.
00:02:03.520
So what this really adds up to is that it’s totally my fault if I end up leaving.
00:02:10.000
I wanted to think through what that means for me: what kind of culture do I really want to work in? What makes me stay at a place, and looking at it from another angle, what makes me leave?
00:02:32.480
I want to share a story with you, and it’s really important to preface this story with the fact that yes, it is true; don’t worry about the company it's about.
00:02:43.680
I can almost guarantee you this company doesn’t do things this way anymore, and if they do, they won’t be around long enough for it to matter. So don’t worry about that.
00:02:54.480
I was hired to lead a small team of technical folks and reported to a CEO.
00:03:00.319
At the time I took on this job, I was concerned that I was going to end up not getting to code and that I would constantly be managing. I didn’t want to be just a manager.
00:03:11.840
I was assured that wouldn’t happen; every question I had was addressed very well. I was given good answers and pleased with the situation, which is why I took the job.
00:03:28.720
Fast forward about six months, and strangely enough, I wasn’t spending much time writing code.
00:03:34.879
Who would have thought? In fact, I was spending a lot of time managing Kanban boards.
00:03:40.239
I was managing a Kanban board full of more urgent tasks than we had time in days, and I was managing people who were super stressed out, trying to shield them from the wrath of our friendly CEO.
00:03:53.840
He could only be described as mercurial in his temperament at times. So naturally, I approached the CEO about this, and he said to me — and I kid you not, this is what he actually said: ‘You’re thinking of this all wrong.’
00:04:12.799
He told me to think of it like another development task: the team members are just objects in the system, and I'm doing engineering just like I would with software.
00:04:30.400
That was right about when it, really, all became clear to me. I had been struggling with this, and just those words alone made it clear that I understood now what was wrong.
00:04:43.919
It turned out that my CEO had no idea what he was doing. You see, he was an engineer, and he was trying to run the company like he was still an engineer. He wanted to treat the company like software.
00:05:00.160
And we all do that. There may be a world where the answer to this question is true, but that is not the world we live in.
00:05:11.600
There is no way people are not objects; no matter how you try to slice it, they’re not objects. I can’t imagine why I was miserable there.
00:05:23.280
I was working at a company where the leader was actively telling me, ‘Yes, I’m dehumanizing my employees; they’re totally objects to me.’
00:05:29.360
No wonder the employees were overwhelmed.
00:05:34.400
We were hiring people, but strangely enough, we were unable to keep them around for very long because apparently they had boundaries against this manipulative exploitative stuff.
00:05:46.720
It was frustrating for me because as much as I would talk to my CEO, it felt like he had a reality distortion field whose polarity was inverted.
00:05:52.400
The problem was that it was only affecting him, and I was really sensitive to this stuff because for about six years, I had been a volunteer counselor, working with people and trying to help them through various problems.
00:06:07.520
Even before this, I was kind of a sensitive guy.
00:06:13.120
I made repeated attempts to counsel my CEO on the problems we faced, reminding him that people are indeed people.
00:06:18.400
However, it didn’t really work out, and I eventually walked away. Now, you might think, ‘Well, this is a really extreme case,’ and I’ll grant you that it is pretty extreme.
00:06:27.760
But the values that he had are very similar to the values that most businesses have. They value predictability, measurement, and control.
00:06:43.840
They see control as the way toward those things.
00:06:48.880
I understand, they want things neat and organized; who doesn’t?
00:06:54.400
It would be nice if everything was neat, but one thing I've learned is that people are really messy, and they aren't any less beautiful for it.
00:07:07.680
How does a company cope with messy reality? They cope with messy reality the same way we cope with it in our code: they use abstractions.
00:07:19.360
They try to reduce humans to another resource to be mined, measured out, and applied to the problem.
00:07:26.160
They put us in a box and stack us up, figuring they need three humans for one problem and four for another.
00:07:31.280
Did you ever stop to think that corporations actually reduce and abstract humans into resources when the only corporeal aspect of a corporation is the humans? That’s a little weird and not sustainable.
00:07:44.800
So I decided that the first aspect of any culture I wanted to be a part of would recognize that we are humans working with humans to develop software for the benefit of humans.
00:07:54.560
You might be thinking, ‘Thanks, that’s great wisdom,’ but if you stick with me, I believe valuable things arise from that simple statement.
00:08:04.639
I landed on the term ‘humane development,’ and not just because it puts the human back into my development methodology.
00:08:17.360
It’s also because of what ‘humane’ connotes. The dictionary definition of humane is very interesting: it relates to inflicting the minimum of pain.
00:08:28.560
I think that's what we all want. We don’t like painful development tasks and painful jobs.
00:08:34.800
How many of you do Agile? How many of you really do Agile? Yeah, my hands are going down too.
00:08:53.440
I think we do it less than we think. There was a really good talk titled 'The Land That Scrum Forgot' that Uncle Bob gave.
00:09:05.279
I want to briefly discuss that talk because I think it’s valuable.
00:09:10.800
Bob said that he and Martin Fowler were sitting around one day, deciding they needed to have an organization of some sort.
00:09:22.000
So they called a meeting and sent out invitations, naming it the 'Lightweight Process Summit.' It was here that the term 'Agile' came about.
00:09:35.120
Nobody was particularly thrilled with it, but usually that’s how consensus is reached; nobody likes it.
00:09:40.800
Uncle Bob believes it was Ward Cunningham who suggested that they should create a statement showing how they value one way of working over another.
00:09:54.320
This resulted in the Agile Manifesto, which outlines values like individuals and interactions, working software, customer collaboration, and responding to change on the left.
00:10:05.839
These are things we should value more than the items on the right.
00:10:11.440
It was at this meeting that he believes Kent Beck suggested that this Agile idea should help heal the divide between business and development.
00:10:30.560
Around this time, Ken Schwaber came up with the idea of running a Certified Scrum Master course, which Uncle Bob thought was odd.
00:10:39.680
But many project managers were not against it; they signed up in droves to get certified because it was something to add to their LinkedIn profiles.
00:10:54.000
Scrum Masters were supposed to be coaches, not managers — explicitly not managers — and their role wasn't supposed to be long-term.
00:11:02.000
The role should rotate among team members and eventually become unnecessary; Uncle Bob noted that project managers didn’t like that idea.
00:11:15.760
Like business often does, it embraced and extinguished Agile. We gradually shifted the values from the left back over to the right.
00:11:24.480
This happens almost transparently. We now rely on certain tools and processes to ensure we’re Agile, and we define it in those terms.
00:11:38.240
Agile sounds great; it implies speed. And if there’s one thing businesses value, it’s hustle. Business loves hustle.
00:11:54.000
This is a Google image search of the word hustle; it's a messed-up wall of motivational posters. I absolutely hate this word.
00:12:06.720
I like the one that says, ‘The only place greatness comes before hustle is in the dictionary.’ Really?
00:12:10.800
I hate hustle, but I make one exception for this poster. It’s the only hustle poster I’d ever put up on my wall.
00:12:22.800
Think about what hustle means. It can be argued that all definitions of words change over time.
00:12:32.320
But find me one definition up there that is remotely praiseworthy. You might argue, ‘Busy is just a movement and activity.’
00:12:41.440
But being busy is not a virtue; just because you’re busy doesn’t mean you’re busy with the right things.
00:12:51.360
This leads me to think our values have shifted, and we’ve decided to turn hustle into a virtue of some sort. We've accepted it in our startup culture.
00:13:01.679
You all know this popular motto: 'Move fast and break things,' first made popular by Facebook, now used by tornadoes.
00:13:14.160
It is a stupid motto. Who aspires to break things?
00:13:22.320
I think the notion of hustle as a virtue is one of the most damaging memes we face today. We accept it because we need to quantify things.
00:13:39.600
As developers, we do planning poker to assign points so we can track velocity because we’re sprinting.
00:13:51.680
It’s a perfect analogy, really. Just like any sprint, you have a work to rest ratio: you sprint for a little while, and then you take three times that amount of time to recover.
00:14:01.920
Some people told me when I asked, ‘Well, don’t we have the weekend for recovery from our sprint?’ I don’t know a lot about sprinting, but I have done Tabata protocol workouts before.
00:14:17.839
The idea is that you work at your maximum output for a certain time, then rest for half that time.
00:14:34.240
You might sprint for 20 seconds and then rest for 60 seconds. With Tabata, it’s 20 seconds of work and 10 seconds of rest.
00:14:50.880
At best, we might be doing Tabatas, but we aren’t doing sprints. These aren't designed for sustainability.
00:15:05.440
If we really must stick with some running analogy, we may as well go with a marathon.
00:15:18.080
Now, I have neither of these stickers on the back of my vehicle nor do I intend to ever have either sticker on the back of my vehicle.
00:15:25.040
However, I do know that some people who’ve earned the right to put these stickers up told me that marathons are nothing like sprints.
00:15:34.080
Marathons are about finding a sustainable pace, where for long portions, the finish line is an abstract concept rather than a real thing.
00:15:49.440
In a marathon, an unsustainable pace is less than worthless; you won’t finish the race, or worse, you may blow out your knee or injure yourself.
00:16:02.160
This is why I believe a marathon is a better analogy. You need to understand the big picture to figure out what sustainability looks like.
00:16:15.280
I don’t think the big picture is on a need-to-know basis. Too many companies approach things by saying, ‘This is the next sprint; don’t think too far ahead.’
00:16:34.160
They tell developers, ‘You don’t need to think about that. We’ll organize the backlog for you, Mr. Developer.’
00:16:46.000
Ultimately, all this comes down to wanting to measure progress. So it all comes back to estimation.
00:16:53.040
Let me share a brief story about estimation. This is my driveway about three weeks ago when we had a decent-sized storm.
00:17:03.040
For Louisville, that means more than two inches. In this case, we had about a seven-inch snowstorm.
00:17:15.000
I've shoveled this driveway before, so I thought to myself that it would take about an hour.
00:17:22.760
This seemed accurate based on my previous experiences. But the snow kept coming down.
00:17:30.760
I went through one pass and realized the snow had blanketed what I had shoveled, so I needed to do another pass.
00:17:39.600
After scraping my wife's car, I went back inside and discovered my one-hour estimate turned into two-and-a-half hours.
00:17:51.760
If I can’t estimate a job I’ve done a million times in a place I know well because things change, what makes me think I can estimate an abstract concept?
00:18:05.200
That's why I think estimates are lies. And it works out okay because even though estimates are lies, deadlines are generally lies as well.
00:18:18.400
If you miss your deadline, you just move the deadline. Great, I'm glad we had that deadline.
00:18:30.080
Most things aren't really urgent either. The most important question a developer can ask anyone who comes with a task is ‘Why?’ Why are you doing it?
00:18:44.320
This takes you from a requirement to a reason. You need to know why you’re doing things to do them correctly.
00:18:56.800
The answer you’re usually going to get from the business is that they’re in a hurry and don’t have time to discuss why.
00:19:03.440
But we all have stories of software we’ve written to solve problems that turned out not to exist, and that frustration can be avoided with one simple question: why?
00:19:14.080
You might say, ‘Well, there are obvious problems,’ but do I really need to ask why if the site’s down? It’s obviously urgent.
00:19:27.360
There’s still a reason to ask why because there are two answers you can get in that situation. The first is just, ‘Because it’s down!’ That’s a useless answer.
00:19:43.679
But a better answer is that the site being down is urgent because it means we're losing credibility, exposure, and a certain amount of money.
00:19:56.000
A misplaced sense of urgency can be more damaging than having no urgency at all.
00:20:07.120
I learned this lesson early on; how many of you have stories about doing something urgently and making the situation worse? Here’s mine.
00:20:25.840
When I first started, I was a sys admin for an ISP, and we had a customer whose mail spool got corrupted.
00:20:39.280
This was back when POP3 was a thing, and I had to go into the directory and run RM-RF on it.
00:20:50.880
However, I was a directory higher than I thought, and the whole process took a while. I ended up spending the entire afternoon restoring from backup.
00:21:04.240
So I urgently solved this customer’s issue and every customer's issue.
00:21:15.120
Now, with deadlines, that can happen with a kind of recursive non-answer. You ask, ‘Why do they need this by a particular date?’
00:21:27.680
And you get the answer: ‘So we can get this other thing by another date.’ You see where this is going.
00:21:41.360
Eventually, recursion runs away with you, and you get offended at the 200th why without having a real answer. We need to recognize that the divide we’re supposed to heal is a lie.
00:22:02.560
There’s nothing there — it’s a construct we created. We are humans working with humans to develop software for humans’ benefit.
00:22:15.600
This means there’s no us and them; we need to understand the business rationale, and they need to appreciate the trade-offs they ask us to make.
00:22:27.680
This sharing of purpose requires empathy. We need to build empathy in our organizations and ourselves.
00:22:40.640
Empathy eventually leads to another value: honesty. Nobody wants to hear, ‘Because I said so!’ as the answer to their why questions.
00:22:51.280
Empathy helps you give honest answers and take time to explain what's going on. When we attach ourselves to arbitrary deadlines, it’s no wonder our work reeks of feigned ignorance or malicious compliance.
00:23:07.920
How many of you have said, ‘Well, I got what was in the spec done, but that wasn’t in the specs, so I didn’t build it’?
00:23:14.960
That’s really malicious compliance when the feature is something the customer needs.
00:23:25.840
So dishonest deadlines encourage smoke and mirrors implementations. They reinforce the idea that it's more important to adhere to a timeline than to build the right thing in the right way.
00:23:40.160
Eventually, the business looks back and wonders why it’s going under when it hit all its milestones.
00:23:53.440
Some businesses don’t allow this to happen; they handle the problem another way by cramming all the work into the timeline they arbitrarily decided.
00:24:07.040
Crunch mode is and should be an exceptional situation. It should be treated as such.
00:24:21.040
How we build applications is if we run out of time, we engage in crunch mode, sacrificing our time, sanity, and loved ones for the business goal.
00:24:38.159
This looks an awful lot like using exceptions as flow control, swallowing an exception just to return the same result.
00:24:50.800
You need to know that something is wrong; allow that exception to raise. You must track it, meaning you should handle issues as they come.
00:25:06.240
Assuming the deadline isn’t a lie, conduct a post-mortem just like you would for any other production failure.
00:25:20.160
It’s great to have heroes, but I’d rather live in a world without needing them.
00:25:30.480
To do this, refine your process to avoid constantly needing heroes to rescue you.
00:25:40.480
With that in mind, I want to show you my best code ever. I need to get this into a slide somewhere because I’m so proud of it.
00:25:55.040
Here it is — the best code I’ve ever written. I’m most proud of this code; it has 100% test coverage, zero maintenance, and does exactly what you think.
00:26:07.040
There’s value in that. We’re quick to assume the axiom that no code is the best code — we all say that and mean it.
00:26:24.720
We’d rather not maintain code, so we do not write it, even if coding is fun. However, formalized processes are code for your company and require maintenance.
00:26:40.480
Sometimes they have bugs, and depending on the person they go through, they can result in strange outcomes.
00:26:54.880
Formalized processes are code for your company. If you're skeptical of your own processes, you should be doubly skeptical of assuming others' processes.
00:27:09.280
This excludes humane development, which is awesome; you should definitely pursue it.
00:27:20.720
I think adopting processes is like doing software integration; some are lightweight, easy to understand gems.
00:27:34.080
You get a basic idea, add it to your gem file, and you're happy. Others are heavyweight frameworks that require a lot from you.
00:27:51.440
Adopting processes this way leads to trade-offs. You can adopt a process in name only, similar to adding mini tests to your gem file but never writing or running them.
00:28:10.080
Processes are a problem statement, often indicating a lack of trust. Sometimes that's warranted; we may not trust ourselves to write the code we think we will.
00:28:21.600
Sometimes it’s about not trusting others to do things correctly.
00:28:29.040
That is not something that needs a process; you should address the source of the problem by going back to that person.
00:28:43.120
You should work with them on what’s necessary — use processes as a last resort to avoid creating legacy within your processes.
00:29:01.200
You get legacy in code as well. You probably opened a source file you hadn't seen in years and saw a huge nested set of conditionals.
00:29:12.960
You know every piece is there for a reason, but you can't point to why anymore. If they aren’t tested, you often write some throwaway test to understand how everything works.
00:29:24.800
In organizations, it’s similar. The process becomes defined by itself while we lose the rationale behind it.
00:29:39.840
This is why I like to promote what I call process meta programming. I’ll explain that through an illustration — this is an illustration of a cat.
00:29:51.680
I think it’s a nice illustration because I drew it myself. I was told that it’s apparently not a good enough illustration.
00:30:10.000
My friend Glenn Vanderburgh shared a story from his life when he was learning to drive.
00:30:21.440
His father sat him down with a driver's handbook, overwhelmed with rules, and worried how he'd learn those rules.
00:30:34.480
But what he told Glenn was wise: just drive so that everyone around you knows what you’re going to do before you do it. That’s the logic behind almost all rules.
00:30:50.560
This is a great process because if you explain the why, it allows him to derive solutions for problems you haven’t thought of yet.
00:31:04.960
Without proper communication, we end up with tools to manage processes. Tools are compiled object code; we give a team a set of arbitrary processes.
00:31:21.200
They build a tool, suddenly the tool becomes the process, and changing it means changing the tool since it defines the process.
00:31:37.840
We start serving machines instead of asking them to serve us. We end up doing extra busy work to remain productive.
00:31:52.800
I encourage you to build small tools — small tools are honest. Look at the CP command; it does one thing: copying files — and does it well.
00:32:12.080
This buys us flexibility; flexibility matters for processes and people.
00:32:25.920
Dr. Martin Seligman, father of positive psychology, participated in experiments to understand learned helplessness.
00:32:35.520
He found that dogs learned to accept the pain of shock when they believed there was no escape. After a repeated process, they simply laid down and accepted the pain.
00:32:53.520
This translates to humans; similar studies have shown that when people are deprived of choice, they thrive when given options.
00:33:09.440
If you're a manager, consider that if your people resort to the choice of ‘If you don’t like it, leave,’ you are likely abusive.
00:33:25.840
If leaving is their only recourse, then rein in your power. I felt like I was abandoning coworkers when I left a toxic job.
00:33:38.080
I had tried to change the culture several times; eventually, I left, facing predictable guilt from my CEO.
00:33:51.680
It’s all very depressing, right? However, you may know PHP CEO, the avatar from my favorite Twitter account.
00:34:02.320
The sad part is that as developers, we sometimes feel helpless to change things, like the dogs in Seligman's study.
00:34:15.520
Yet, as developers, we possess significant freedom. We can work anytime and anywhere to achieve productive output.
00:34:30.080
If you’re a manager, you might feel uneasy about giving your team that autonomy, but once you trust them, you can relinquish some control and give them autonomy.
00:34:48.000
Let’s say for a moment that everything in your organization is encoded in messages. The point of processes should be to serve as reusable messages.
00:35:01.600
Think of it as a compression scheme, where messages get reduced, so you create a process — referring to it saves time.
00:35:16.080
It should be about increasing the signal-to-noise ratio of communication, allowing vital messages to rise.
00:35:30.720
That’s why requiring developers to be onsite is a joke. We have numerous avenues for communication.
00:35:46.720
People often say that face-to-face communication is the best, but we need to stop confusing throughput with efficiency. Programming is written communication.
00:36:01.680
If we can’t communicate, we end up with people who feel they need to be present all the time.
00:36:15.680
They commit code at 3 a.m. after working 13-hour days because they fear missing something.
00:36:27.840
This omnipresence creates heroes who mask the pain the company should feel. Heroes can be great, but dependency on them is unhealthy.
00:36:42.160
Sometimes, it’s necessary to let a company fail at a task to ensure they understand a process isn't sustainable.
00:36:52.960
As Tony Robbins says, 'Change happens when the pain of staying the same is greater than the pain of change.'
00:37:10.400
We are thought workers, but how do you measure thought? We all have moments when we suddenly realize something in the shower.
00:37:23.680
We are almost always working, so remind each other that it’s okay to step away from the computer.
00:37:36.800
Work doesn’t happen just because your butt’s in a chair; that's not how it works.
00:37:43.040
As a leader, lead by example. In my specific situation, I try not to communicate with my team outside business hours.
00:37:55.840
If someone asks for vacation time and my CTO says it’s okay, I’ll let him know the next morning, not at 8 p.m.
00:38:09.920
Ultimately, it comes down to four key values: empathy, honesty, trust, and autonomy.
00:38:22.720
These values aren’t just engineering-specific; they’re qualities I want in any human being.
00:38:35.680
When hiring, stop looking for people to control. If you’ve learned one thing today, it should be this: always ask ‘why?’
00:38:47.360
And the reason is simple: that’s not how relationships work. That’s all I’ve got. Thanks.
00:38:54.640
Hmm.
Explore all talks recorded at MountainWest RubyConf 2015
+10