Talks
Humane Development
Summarized using AI

Humane Development

by Ernie Miller

In the talk "Humane Development" at Ruby on Ales 2015, Ernie Miller discusses the importance of recognizing the human element in software development amidst prevalent methodologies like Agile, Scrum, and Kanban. He emphasizes that while processes and frameworks provide structure, they often reduce individuals to mere objects or resources, which can harm organizational culture and employee satisfaction.

Key Points Discussed are:
- Human-Centric Development: Miller introduces the concept of "humane development," advocating for a focus on the human aspects of software development rather than treating employees as mere resources. This approach prioritizes compassion and empathy in workplace relationships.
- Challenges with Traditional Methodologies: He shares his experience in a previous role where the implementation of a Kanban board led to overwhelming stress among employees, as they were treated like components in a production system rather than valued individuals.
- Value of Individual Experience: Miller reflects on how he previously could leave jobs without feeling responsible if things weren't working, contrasting this with his current position where he feels a direct responsibility for creating a healthy work environment.
- The Misuse of Agile Concepts: He critiques how Agile methodologies have been misinterpreted in organizations, often prioritizing speed and control over human-centered values. This is reflected in the shift from Agile principles towards a focus on certifications and rigid processes.

- The Importance of Asking Why: Miller stresses the significance of questioning tasks and deadlines—"Why do we need to complete this?"—to avoid unnecessary work on problems that may not exist, thus encouraging more thoughtful and effective development practices.
- Sustainable Work Practices: He argues against the glorification of "hustle culture" and emphasizes the need for sustainable work rhythms, comparing effective workflow to a marathon rather than a sprint.

In conclusion, Miller urges attendees to consciously integrate humane values into their development practices, advocating for a balance between process and the unpredictable yet beautiful nature of human beings. The main takeaway is that to foster a successful and thriving development culture, one must prioritize human connections and question the underlying motives of work demands.

00:00:29.720 I am going to introduce Ernie, since that’s why he’s here. Thank you so much for coming. Some of you may not know Ernie.
00:00:36.239 He was a childhood television star with his best friend, Bert. Some people got the reference. I’m surprised by how many of you have never seen Sesame Street. Ernie also wrote Active Record and MySQL, if you’ve ever used those.
00:00:44.719 He invented the SELECT statement, which is pretty useful, I don’t know if you know that. Ernie is one of the best database people I know.
00:00:51.000 So, you should come up and say hello to Ernie and follow him on Twitter. Just remember, first try tweeting him your database questions, and then Google for the answer. Alright, this is Ernie Miller; can we get a round of applause?
00:01:23.400 Good morning! You all look bright-eyed and bushy-tailed. I have some important business to take care of first. Terrence made a request yesterday, and I want to honor that.
00:01:30.079 I have 154 slides in 35 minutes and got a late start because someone had to change into their space suit.
00:01:36.720 So, I just want to make sure everyone remembers that as I go over my slides. I’m trying to get a sense of whether or not I can frame you all without doing a panorama, and I think I actually can.
00:01:44.719 Can we all stand up for a moment for a Friday hug? Alright, you all look beautiful, you’re awake, blood is flowing, your arms are extended.
00:02:01.840 On the count of three... one, two, three... ha! You’re beautiful. Alright, we’ll post that later; I suppose I don't really have time to post it at the moment. Silly me.
00:02:08.239 Okay, with that out of the way, I work for a company called Inviseum. I started there back in October. We are an application security consultancy, which basically means we do security audits on applications for people that I would love to tell you about, except they would probably kill me.
00:02:30.200 So, they hired me as a director of engineering. As it turns out, neither a fancy chair nor a megaphone comes with that job. What does come with that job, however, is an astounding amount of pressure.
00:02:44.719 You see, in every job I’ve ever held up to this point, I could look at myself and say, if I was unhappy with a position, it wasn’t really my fault. I could leave and feel like I didn’t make things rough. I’m not proud of that. I’m actually a bit ashamed.
00:03:07.879 But I also don’t think I’m necessarily alone. As I understand it, it’s not very common for us to stay in a position for very long, right? How many of you have been in your job for less than a year? Wow! Okay, less than two years? Yeah, okay, so I don’t even need to keep going with that.
00:03:29.400 Basically, nobody here has worked the same place for more than about two years. When you left your previous job, you took yourself with you, right? So you probably didn’t think you were the problem, either.
00:03:58.920 You probably felt it was impossible to fix, and it was just easier to move on. Here at Inviseum, the problem is they wanted me to build software, to build the team, and to build the culture, which means it absolutely is totally my fault if I’m not happy there.
00:04:13.760 So, that put a lot of pressure on me. I started to think about what makes me stay at a company, or, looking at it the other way, what makes me leave. I want to share a story with you about a former employer.
00:04:40.160 I want to make it very clear: it’s not important who this employer is. For one, I’m sure they’re not running things this way anymore, and if they are, they probably won’t be around for much longer anyway.
00:05:03.320 I was brought on to lead a team of technical folks, and I was going to report to the CEO. When I talked to the CEO about coming over to work there, I was concerned that I would end up just managing.
00:05:22.280 I really wanted to write code; I wanted to remain technical. I was assured that wasn’t going to happen, and he made it worth my while to take the risk. So, I decided to make the jump.
00:05:42.920 Fast forward about half a year, and I wasn’t spending much time writing code—imagine that! Instead, I was spending a lot of time wrangling a Kanban board or some variation thereof.
00:06:05.360 Nobody's Kanban board is actually that simple. I was triaging a Kanban board full of more urgent tasks than we had time to do. I was checking on overworked, stressed-out employees and doing my best to shield them from the wrath of that jovial CEO.
00:06:28.480 I went to the CEO and told him, 'This is a little bit messed up; this is not what I signed on for.' He told me something I kid you not: 'You're thinking of this all wrong. Think of it as another development task; your team members are objects in the system. You're just doing engineering, just like you would with software.'
00:06:48.800 And he sent me on my way. It was then that everything became crystal clear to me. Though it probably wasn’t how he’d hoped it to be, this guy had no idea what he was doing. He was a former engineer, and he really wanted to treat the company like software.
00:07:06.840 He was comfortable with software, but there may be a world where the result of this statement is true; however, it is not the world we live in. People aren't objects—that’s really messed up, right?
00:07:20.760 It should come as no surprise that I was really miserable there. I was working at a company whose leader had actually told me he was trying to dehumanize the employees, and the employees were pretty much overwhelmed.
00:07:36.840 We were putting too much load on them; they felt like they didn’t have the time. They felt that if they weren’t spending time documenting everything they were working on, it really wasn’t happening, and therefore they wouldn’t get credit for it. Surprisingly enough, we had a hard time hiring in this environment.
00:08:18.840 It was like my CEO had his own reality distortion field; the polarity was inverted, and it only affected him. I don’t know if part of it might be that for about six years now, I've been a volunteer counselor. I talk to people a lot, and even before that, I’ve always been kind of a sensitive guy.
00:08:46.240 So, I was miserable. I made multiple attempts to counsel my CEO on the issues I perceived, but eventually, I walked away. You might say this situation was kind of extreme, but I don’t think it’s terribly abnormal.
00:09:04.960 I’ve seen this pattern in most jobs where I’ve been really unhappy. The business has different values than I do. They value things like predictability, and I understand why; they value things like measurability and control because they believe that having control over situations gives them those other two things.
00:09:35.440 Understandably, the business wants things to be neat and organized. I get it; it makes sense. But businesses are made of people, and people are messy, no less beautiful for it. We need to remember that people aren't always going to fit neatly into the molds that companies want.
00:09:53.920 So, how does a company cope with messy reality? They cope the same way that we developers do: they use abstractions. They try to make us fit whatever mold they want and reduce humans to resources to be mined.
00:10:07.000 Think about this: companies actually reduce and try to abstract away humans as resources when the only corporeal thing about a corporation is the humans. So, I decided that, first and foremost, any company I wanted to work for would have to recognize that we are humans working with humans to develop software for the benefit of humans.
00:10:20.480 You’re probably thinking, 'Well, that’s great—that’s a real insight. Thanks for that.' But just stick with me; I swear I'm going somewhere with this. Other things arise from that realization. First, I decided to call it 'humane development,' because it literally puts the human back in development.
00:10:48.920 More importantly, 'humane' conveys the kind of values that I want to hold. Here's a definition of humane: it’s compassion and benevolence, and inflicting the minimum of pain. Aren’t these things you'd like to have where you work? You don’t want pain.
00:11:07.400 How many of you do Agile in some way, shape, or form? Most of you, right? Now, I don’t pretend that that term means much these days, but there was a great talk by Uncle Bob a few years back called 'The Land That Scrum Forgot.' I stumbled upon it while researching for this talk and want to share some insights. This is a history lesson about where Agile came from.
00:11:54.720 Uncle Bob got together with Martin Fowler and wanted to create some kind of an organization. They sent a bunch of invites to what they ended up calling the 'Lightweight Process Summit,' where they coined the term Agile. Nobody was terribly happy with the name, but since everyone disliked it, they went with it.
00:12:23.840 Anyway, Bob said that Cunningham had stated they needed a manifesto, something that would say what they valued more than other things without discounting the previous things. So, we ended up with the Agile Manifesto. You might be familiar with it; if not, you can go to agilemanifesto.org to read it.
00:12:50.240 It states some things that seem patently obvious: the things on the left are more valuable, but it also wanted not to alienate the corporations they were essentially trying to sell this idea into. Therefore, they continued to say that those other things were also valuable—just not as valuable.
00:13:09.840 Bob went on to say that Kent Beck had reiterated that it really should be about healing the divide between business and development, and everybody agreed. A little later, Ken Schwaber came up with the idea to start offering a certified Scrum Master course.
00:13:40.639 Uncle Bob thought that was stupid, and every developer he talked to also thought it was stupid. Yet, project managers didn’t think it was stupid, and they sold tons of these courses and certifications, which ended up being what put Agile on the map for corporations.
00:14:11.679 The problem was that it made its way into organizations by certifying project managers as Scrum Masters, but a Scrum Master was not supposed to be a manager. The role was supposed to rotate between people and eventually fade away.
00:14:41.920 But the project managers who took the certified Scrum Master course did not like that interpretation, and we gradually see the transformation from the things on the left shifting back to the right. Now, most of us use some kind of special process or tools to manage our so-called Agile.
00:15:22.600 We’re not focusing on the things on the left as much as we’d like to. One of the aspects of the Agile term is speed; it sounds speedy, it sounds fast. In fact, you can go fast with Scrum or any Agile methodology, and that plays nicely with another core business value these days—hustle.
00:15:50.160 This is a Google image search for hustle. It looks like some kind of messed up wall of motivational posters. The only place greatness comes before hustle is in the dictionary. I absolutely hate this word, except for this image right here; it’s the only allowed image to use the word hustle.
00:16:37.080 Now, look at the dictionary definition of hustle. Does anything in that list look remotely laudable? Is it something we should virtue consider a virtue? You might argue that the definitions of words change all the time, but I think we’re fooling ourselves.
00:17:03.440 Hustle still means what it meant before. Our values have changed, and we’ve tried to treat hustle as a virtue. We’ve adopted this in startup culture, especially this wonderful motto: 'Move fast and break things.' First made popular by a tornado.
00:17:33.880 This is a horrible motto; it’s so stupid—move fast and break things. That’s a real problem. The notion that moving fast is somehow virtuous is damaging. You need to be moving in the right direction, and we forget about that sometimes.
00:18:04.240 We get obsessed and play games like planning poker so we can assign points to measure velocity because we’re always sprinting. It's a great analogy: sprinting, because we do a sprint, and then take a recovery period. We even have weekends!
00:18:35.440 I asked people on Twitter if they do recovery after they sprint, and they said, 'Isn’t that what weekends are for?' Well, you see, I am not really that familiar with most sprint interval training.
00:19:03.760 Most of what I found indicated it typically has more rest than work, however, I am familiar with the Tabata protocol by Dr. Izumi Tabata, which involves a two-to-one work-to-rest ratio. You can see in this little chart, each block is 10 seconds, resulting in a sprint.
00:19:31.480 With Tabata, you have this work followed by a long active recovery period, but with Tabata, you’re doing two-to-one work recovery, meaning you’re doing less—and we may be tooting if we count the weekend, but we're definitely not getting the recovery we need.
00:20:02.800 It’s the wrong analogy anyway because none of these are about sustainability. You're not meant to sustain these paces for any long period. A better analogy, if we're going to stick with one, is a marathon.
00:20:22.640 The finish line is an abstract idea for a long time; you know it's coming but don’t focus specifically on it. You concentrate on maintaining a sustainable pace and following markers, knowing that your training will pay off.
00:20:49.600 In a marathon, an unsustainable pace isn’t just worthless—it’s less than worthless. It will cause you not to finish the race and probably hinder your performance in the next one.
00:21:18.480 So, it’s important to realize that the big picture can’t be a need-to-know basis. If you don't know where you're going, how can you possibly plan a sustainable pace?
00:21:36.520 Whenever companies try to feed you one sprint at a time without letting you focus on the bigger picture, it eliminates your flexibility to help plot the course. All of this is geared towards measurability.
00:22:05.640 Estimations are critical, and I want to discuss them. Just a few weeks ago, I had a big snowstorm which, for Louisville, means anything over three inches, and we had about seven inches of snow. I was relying on the weather estimate for when the snow would stop.
00:22:31.560 When I went out to shovel the drive, the snow was still coming down, and it was harder than I thought, requiring multiple passes to clear it. While I was out there, I was already tired and projected that it would take around an hour to shovel.
00:22:52.040 In reality, it took me two and a half hours. I’ve shoveled my drive before; there is nothing really different about this case. So then, if I can’t estimate a simple task that I’ve done many times, what makes me think I can estimate something abstract and creative?
00:23:22.680 That’s why I think estimates are lies. Thankfully, we’re buffered from the consequences of those lies because most deadlines are also lies. We let them slide, and oh, we just adjust the deadline.
00:23:52.600 Was it really a deadline? Most urgent things aren’t really urgent, and so it usually works out, and we don’t realize how much we’re lying. I think it's really important that we ask why.
00:24:16.000 We need to question every requirement, every deadline, and every task. What exactly are we trying to accomplish? That's what helps you transition from a requirement to the underlying reason. It’s something people want to skip, but it’s vital to dig deeper.
00:24:50.720 We might think it's crazy to question why, but it’s worthwhile. We all have stories of applications we’ve developed to solve problems that never existed because no one asked why. For example, if the site is down, that is urgent, but it’s still important to ask why.
00:25:25.160 The bad answer is, 'Because it’s down,' but the good answer involves figuring out what’s lost while it’s down, which helps to understand urgency differently. Also, this approach can prevent hasty decisions that may lead to even more significant issues.
00:25:55.800 When I first started working as a sysadmin for an ISP, a customer contacted us because their mail spool had corrupted. In my urgency to fix things quickly, I executed a command one directory higher than intended. I created a substantial problem that took all afternoon to resolve.
00:26:38.800 Misplaced urgency causes similar situations, especially with deadlines. They create a cycle where people give non-answers—someone says they need a feature by a date, and upon asking why, you get—'So we can meet another date.'
Explore all talks recorded at Ruby on Ales 2015
+5