MountainWest RubyConf 2015

Summarized using AI

Humane Development

Ernie Miller • March 29, 2015 • Earth

The 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.

Humane Development
Ernie Miller • March 29, 2015 • Earth

by Ernie Miller
Agile. Scrum. Kanban. Waterfall. TDD. BDD. OOP. FP. AOP. WTH?
As a software developer, I can adopt methodologies so that I feel there’s a sense of order in the world.
There’s a problem with this story: We are humans, developing software with humans, to benefit humans. And humans are messy.
We wrap ourselves in process, trying to trade people for personas, points, planning poker, and the promise of predictability. Only people aren’t objects to be abstracted away. Let’s take some time to think through the tradeoffs we’re making together.

Help us caption & translate this video!

http://amara.org/v/GWId/

MountainWest RubyConf 2015

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
+13