Communication
Livable Code
Summarized using AI
Livable Code
by Sarah MeiIn her talk titled "Livable Code" at the Rocky Mountain Ruby 2017 conference, Sarah Mei explores the intricate relationship between software teams and their codebases, emphasizing the importance of trust and communication. She revisits her earlier ideas on software development, clarifying that while software is not a physical product, it can be better understood through models of living spaces.
Key points in her presentation include:
- Background and Trust: Mei shares her background in software and community work, highlighting the significance of trust among team members in successful software development.
- Conway's Law: She discusses Conway's Law, which suggests that a team’s communication structure influences, and is reflected in, their code structure. Problems in the codebase may mirror communication issues within the team.
- Architectural Metaphor: Mei argues that likening software to architecture or construction is outdated, as software is always a work in progress, contrasting with the fixed nature of physical buildings. She describes software development as more akin to creating livable spaces where ongoing adjustments are necessary.
- Livable Code: The concept revolves around making codebases sustainable and adaptable for the teams using them, akin to maintaining a livable home that meets the needs of its residents.
- Incremental Improvements: Mei emphasizes that livability can be achieved through small, consistent improvements rather than large, sweeping changes, a process akin to maintaining a tidy home rather than depending on dramatic cleanouts.
- Community and Collaboration: The necessity for team communication is stressed throughout her talk, arguing that a group's success comes from collaborative practices, resources, and a communal approach to maintenance.
Significant examples include reflections on her experience running workshops with RailsBridge and insights from software industry norms that make achieving a livable working environment challenging. Mei concludes that the vital connection lies in recognizing software as an interconnected system of people and code, promoting a culture of continuous improvement and trust within teams.
00:00:14
How's the sound? Good? Okay, feels a little weird to have that microphone right there, but I'm going to go with it. Good morning, and thank you.
00:00:30
This is my third Rocky Mountain Ruby, and my first one in Denver. Is this the first one that's been in Denver? Second one? This is my first one in Denver.
00:00:42
I do have a soft spot for Denver, actually, because it was here that I did my first-ever keynote at RubyConf in 2012. That talk kicked off the speaking part of my career.
00:00:55
For the past few years, as Jeff mentioned, I have helped run RubyConf, but that was way before that. I had just submitted a talk through the CFP via the normal channels.
00:01:07
They were like, 'Hey, you should come be a plenary session.' I had to look up what that meant. It was oh, a keynote. The other two keynotes at that conference were significant figures; there was Matt, the creator of the Ruby programming language, and Jim Wyrick, an old-school American Rubyist.
00:01:24
If you've ever typed rake or gem install, you've used some of his work. So, I was pretty intimidated to be included in that lineup.
00:01:42
I gave a talk that was in some ways kind of a precursor to this one, but I gave it a much more pretentious name: 'The Insufficiency of Good Design.'
00:01:59
If you ever want a reason to cringe, I highly recommend watching a conference talk you gave five years ago—it’s like looking at code you wrote five years ago and thinking, 'Really? I thought that was a good idea?'
00:02:11
This was the first talk I did that really explored the relationship between teams and the codebases that they produce, and that has been a significant part of my thinking in software since then.
00:02:30
So, I'm excited to come back to Denver and give you the five-years-later hot take, hopefully, one a bit more thought-out than the one from 2012.
00:02:44
The theme of this conference is trust, and when I heard that, I initially thought, 'Hmm, I might need to write a new talk,' because this talk is not specifically about trust; it's about code.
00:02:59
Which, of course, then means that it must be about teams, and, of course, that must mean it is about trust.
00:03:12
There are a lot of people here I haven’t met before, so let me tell you a bit about my background. Jeff basically covered it: I'm based in San Francisco, currently the Chief Architect at Mine Software.
00:03:30
I've been doing consulting for about ten years, which makes that almost half my career. I've been a developer, a manager, and a team lead.
00:03:46
I’ve been the expert, and I’ve been the newbie. I do a lot of community work, as you mentioned. RubyConf is in New Orleans this year, so come on down in November.
00:04:02
We just released our program. Jeff mentioned RailsBridge; that was probably the biggest turning point in my career regarding community work, and that happened in 2009.
00:04:13
Another developer, Sarah Allen, and I founded RailsBridge, and we were one of the first organizations to provide women and other gender minority folks a free place to learn programming if they were new to it or to learn a new framework if they were returning to the job market after some time away.
00:04:31
In 2009, there were no code schools; there was no real place to send people who wanted to learn more than just meetups, conferences, books, and the internet.
00:04:47
To be honest, at the time we were planning the first workshop, we weren't really sure if any women would even be interested in learning Rails, but we posted the workshop through the San Francisco Ruby Meetup account.
00:05:02
We thought, 'Well, even if nobody shows up, our sponsors behind us for lunch, so we can just sit around and talk to each other over lunch.' But then, less than 24 hours after we posted it, it was completely full and had a waiting list of 125 people for just 30 slots.
00:05:27
So, there was clearly demand, and the workshops we conducted over the years helped generate that demand for code schools. They demonstrated that there was an underserved market out there.
00:05:43
Folks who didn’t come to computer science or programming during college, like I did, but who definitely had the aptitude for it.
00:06:01
Through these workshops, I met many individuals who took to coding immediately, despite having never written code before, and this fed my internal sense that something was wrong in the way we thought about tech.
00:06:17
We were using the wrong model; the way I had been trained in my computer science degree to think about software as engineering, architecture, construction, or manufacturing was insufficient.
00:06:30
For example, if doing something is like creating a physical product, then why is software never 'done' anymore?
00:06:50
If we are engineering solutions, why can we not always plan ahead? If computer science fundamentals are really that important, why are interviews the only time I ever need to think about runtime complexity?
00:07:01
I've felt this vague sense of wrongness ever since my computer science classes in college, but it has taken me a long time to articulate it, and even longer to come up with an alternative model.
00:07:12
This talk here in 2012 was my first attempt at that. For the last few years, as I continued to write code, work with clients, and all that, I've also been working on two new models for software.
00:07:27
One is for development teams, and the other is for codebases. What I'm trying to do is capture software as it is when it's done well and, like any good model, help us understand what to do in novel situations.
00:07:38
We need two models because software is composed of two related, interconnected, but distinct entities: the team and the codebase.
00:07:53
One of the most influential ideas in my thinking about software is called Conway's Law. Formulated in 1967, at this point, it makes it a 50-year-old idea.
00:08:05
Conway's Law states that the structure of your code will recapitulate your team's communication structure. That sounds pretty abstract, but let me give you an example.
00:08:18
From an early startup client I had: they had a team of five engineers. Number one was sort of the manager; he was in charge and tended to broadcast information out to the rest of the team.
00:08:29
However, their internal lines of communication were quite good. Their architecture for their system was made up of five different services, each written in five different languages.
00:08:47
Number one was the orchestrator, but the others communicated amongst themselves as well. In this case, their code literally reproduced their organizational chart.
00:09:0
Now when you have a team all working on the same codebase, this could be harder to see, but it’s still there.
00:09:12
The reason this is so useful is it means if you see a problem in the code, it reflects a problem in your communication structure.
00:09:21
Messiness in the code reflects messiness in the team and in your interconnections as people, or even in how your teams relate to each other.
00:09:36
This means for any problem you have writing software, you have two directions to approach it: you can make changes to your team which drive changes in your codebase, or you can make changes in your codebase which then drive changes to your team.
00:09:48
For any given issue, you can do one or both, depending on which seems more effective. Some problems look like they're purely code-based, while others look like they're purely team-based, but all of your problems are both.
00:09:59
For example, if your codebase contains three competing implementations of user login, you might consider that purely a code problem; it's technical debt that needs to be paid down.
00:10:09
However, this also represents a communication deficit among the members of your team. Presumably, if they were in better communication, they wouldn't have implemented three independent login methods.
00:10:24
If you fix one without fixing the other, you are likely to see it return. That's why we need two models: because the team and the codebase are equally important but distinct parts of a software system.
00:10:41
This talk focuses on the codebase side of the equation. I've talked about Conway’s Law, but I also want to mention another idea that underpins my thinking on software.
00:10:56
That idea comes from a paper by computer scientist Fred Brooks, written in 1986, called 'No Silver Bullet: Essence and Accident in Software Engineering.'
00:11:16
Now, Fred Brooks is better known for a book called 'The Mythical Man-Month,' but I find this paper more relevant. I read it about once a year.
00:11:31
The paper states, in essence, that it is not possible to create a tool or a process that makes software engineering orders of magnitude better.
00:11:50
There are some irreducible complexities in software that do not exist in other parts of engineering, like civil or hardware engineering.
00:12:05
When Brooks wrote this paper in the '80s, hardware chip speeds were doubling every 18 months, and people were convinced there was a software equivalent out there somewhere.
00:12:20
But Brooks said no—there's something different about software compared to every other engineering field. I don't know what it is, but it doesn't conform to the same rules, and therefore, there isn't a way to make big leaps forward.
00:12:38
Our primary metaphor for a software team is often manufacturing, where we make a product, or perhaps it's a workshop where we handcraft each item individually.
00:12:51
In either case, we tend to think about it as a product. This doesn’t fit quite right with how we write software today.
00:13:10
It's not akin to a physical product that's manufactured; it's more like an experience that incorporates the development team, our code, other people in our organization, and even our customers.
00:13:28
At its best, it is a group creative effort. It’s more like a theater troupe putting together a play than a manufacturing assembly line.
00:13:41
Teams are more successful when we think of them as groups of creative people collaborating. This model provides more information and predicts more behavior than a manufacturing model does.
00:13:56
Even though many of us who work in tech, particularly programmers, are not accustomed to seeing our work as creative.
00:14:04
We need to make a similar shift in how we think about code. One thing Conway’s Law indicates is that if there is a rule that applies to the codebase, then there’s another rule that applies to the team.
00:14:24
So what does that rule look like for the codebase? For me, the difficulty in code has always come down to this word: architecture.
00:14:39
Ironically, I’m the Chief Architect, but for 50 years we’ve been told that software is like architecture or, perhaps earlier in our careers, like construction.
00:14:54
We take someone else's designs and we build them. Our goal, at least as individual contributors, is to be the person that makes the plans—the architect.
00:15:10
However, there is a problem with thinking about software this way—it's building something, and it doesn’t reflect how it works anymore.
00:15:27
Creating a building has three very defined phases: the planning phase, the construction phase, and the maintenance phase.
00:15:43
Software projects used to follow this model closely. You’d finish the project, press it onto CDs, mail it to your customers, and then the developers would hand it off to another group responsible for maintenance.
00:16:01
Those people would send out maintenance CDs with updates while developers moved on to something else. Nowadays, with web applications and constant deployments sometimes hundreds of times a day, nothing ever seems to be truly done.
00:16:17
It’s not just web or desktop apps picking up this model; even mobile apps and games—once the last holdout of the three-phase model—are now delivered over Steam or downloaded to your console and can be updated continuously.
00:16:39
Software is getting easier to change, while physical buildings are not; they remain costly to alter after construction. Anyone who has remodeled their kitchen can attest—spending $40,000 only to move the sink seven inches to the right and bash down part of a wall, which takes months to finish.
00:16:58
There are many ways writing code is no longer like architecting or constructing a building. For one, it's never finished, and another, the cost of making changes has shifted significantly.
00:17:12
We work hard to lower the risk of entering a situation like this—for that to be almost nonexistent. Really, our infrastructure should be thought of as the buildings while we live inside them.
00:17:29
If you think about software infrastructure, a lot of it is hidden from us, just like the steel skeleton of a skyscraper is invisible to the tenants once they move in.
00:17:41
The Heartbleed vulnerability, which was announced in 2014, was basically equivalent to saying, 'All the steel beams in the skyscrapers you've built in the last 10 years are faulty, and your building might fall down.'
00:17:57
As residents inside one of these apartment towers, we don’t depend directly on the steel beams we cannot see, but suddenly our stuff is at risk because of faults in this invisible, difficult-to-change infrastructure.
00:18:06
What we create today really isn't just the buildings themselves; most of our applications occupy space within pre-built structures. We add our components to it, and this may feel like a downgrade.
00:18:23
We are moving from architects to interior designers, or something similar, but there’s power in this model. The tech world resembles Manhattan now: there are no more vacant lots.
00:18:41
All the buildings that could be built are built. Sometimes, new stuff arises around the edges, or something large is demolished and replaced.
00:18:56
These buildings form the foundations of our applications—the operating systems are the parking levels, while the frameworks are the buildings themselves.
00:19:12
We've taken good ideas for structuring space in a codebase and literally encoded them into our structures. Now, we build our applications inside them, and the interior spaces they provide are changeable.
00:19:31
You can change them, but it holds larger costs than changing your code or framework. In other words, the spatial layout you choose to constrain you shapes how your codebase turns out.
00:19:46
For example, one might think of Angular as an expansive loft space with very few walls—you can do anything, but you have to do it yourself.
00:20:02
You could think about Ember as more like a single-story ranch house with defined rooms. You can change the purpose of any of these rooms if you want, but it’s going to be a bit more work.
00:20:19
You could picture React as one of those modular houses that can be assembled at the factory and then trucked out to you to snap together.
00:20:35
In your application, you have various spatial layouts to select from, each optimized slightly differently. Your stuff will probably fit in any of them, but one may suit your needs better than others.
00:20:56
You may require different spaces for different applications; however, a loft means you need to create your own walls and partition the space with couches, folding screens, or the like.
00:21:14
In contrast, with a house with more literal walls, you won't need to do that. The code you ultimately produce in your application is shaped by the space you have for it.
00:21:32
In our industry, there are certainly many jobs still focused on working on those buildings, their foundations, or designing new constructions, but most of us build applications.
00:21:49
As the industry expands, that's largely where we’re adding jobs. There was a time when creating a web application meant essentially building your own house. I lived through that era in the late '90s.
00:22:06
Every team designed their own templating system, routing methods, back-end, and front-end code organization. I worked both on front-end and back-end tasks in those days, and every codebase was distinct.
00:22:23
It felt like every team attempted to visualize from first principles what the ideal layout of a house would be. Sometimes, you'd walk into a codebase where all the bedrooms were in the basement and all the bathrooms were on the third floor.
00:22:37
Most of these structures really weren't up to code. These days, you don't need to know how to construct your own house to have a place to live—all thanks to progress.
00:22:54
What I appreciate about the interior space model, rather than construction, is that it clearly outlines what is hard to change and what is easy to change for you.
00:23:09
In a house, there’s a spectrum regarding how hard things are to change. Rearranging furniture, for example, is quite simple; painting walls or changing flooring takes a bit more effort.
00:23:26
However, putting on a second story is no small task. Similarly, no particular piece of code is impossible to change when you’re writing an application.
00:23:44
Your code is the simplest extension to the framework; more complicated changes involve the programming language, operating system, and hardware. While all these changes are possible, they often involve opening up a few walls.
00:23:58
When you combine this with the fact that projects are no longer ever truly done, it means that a codebase isn’t something to build anymore. Rather, a codebase is where we reside.
00:24:15
Our goal isn’t to finish it and move on as it would be in a structure that we built; instead, our goal is to make it livable for us and everyone else who inhabits that space.
00:24:33
When we write code, our goal isn’t to finish and move on either; our goal is to make it sustainable and livable for the team that inhabits it.
00:24:47
Livable for a house means you can do the things you want to do comfortably. There’s light in places you want to read, counter space for cooking, a box of tissues on the coffee table, and a basket for the remote controls.
00:25:06
What constitutes livable space for a group of people depends on those individuals. A livable house for a family with two toddlers is different from that for college-age roommates or a single parent with a teenager.
00:25:29
The same goes for code: livable code allows you to make changes and additions you want without undue annoyance. You know where things are, and you can find them.
00:25:46
Just like a house, what's livable for one team won’t be for another. A codebase that’s livable for one senior developer and several junior developers is significantly different from one that works well for just five senior developers.
00:26:01
It can also differ greatly when there’s an outsourced team involved, and so forth. Making a space or a codebase livable is an ongoing process.
00:26:16
People change, evolve, and come and go. Every time you get someone new on your team, it's like getting a new roommate. They may have a weird couch they're attached to.
00:26:32
You might agree, somewhat reluctantly, to place it in the living room. After two days, they might suggest replacing all the blinds and curtains for energy efficiency.
00:26:51
Worst of all, they might wash their dishes with tabs instead of spaces, but you all live here now, so you'll find a way to make it work—or maybe you won't.
00:27:03
But one thing to notice is that your day-to-day happiness depends a lot on the people who are in the space with you, perhaps less on the actual items and even less on the shape of the space itself.
00:27:21
The same is true for codebases: your happiness depends principally on the people you work with, not so much on the code, and even less on the framework.
00:27:38
But what do you do when that interior isn't livable? What do you do when your kitchen resembles this? How do you make code livable for any group of people when you're starting from a terrible foundation?
00:27:57
One of the central mysteries of software development is, with all the books, blogs, ideas about software design, patterns, best practices, and rules, why do so many of our codebases resemble this: so full of clutter you can hardly navigate them?
00:28:10
It turns out that why people's houses end up this way is somewhat of a mystery too. Some say it's laziness; some suggest the same applies to code.
00:28:29
Psychology tells us that it's not laziness; a room like this gets cluttered one small decision at a time.
00:28:44
Consider that messy kitchen might have started more like this: a small space they've tried to maximize by adding shelves and crates, utilizing windowsills and other marginal spaces.
00:29:0
For a while, they cleaned it every night, but then came that one horrible day when they didn’t, and they couldn’t face it the next morning.
00:29:15
When they returned home that evening, they dumped the groceries on top of the stove, and later opted for takeout because they didn't want to move too much stuff just to get to the stove.
00:29:30
The next day, when they put the mail on top of the groceries because there was nowhere else, they ended up with takeout once again. Feeling despondent about their kitchen's state, it started to seem overwhelming.
00:29:44
Soon after, they were faced with this—decisions compounding despair. It's like saying, 'It's already bad; why not throw another piece of mail on the floor?'
00:30:0
This cycle also occurs with codebases. You walk into a file that’s already a mess, with countless patterns no longer serving you.
00:30:16
Product breathing down your neck for a bug fix, and it seems entirely logical to duct tape it together as best you can and get out quickly.
00:30:34
But all those little decisions over time lead to an unlivable codebase. There are ways, though, to get out of that hole.
00:30:50
A TV show called 'Hoarders' ran for a while—has anyone seen it? It ran for six seasons despite every episode being nearly identical.
00:31:05
It's a reality show documenting people who have unlivable houses, where someone they know requests an intervention. If they agree, the intervention is dramatic—a work crew arrives, takes everything out, throws most of it away, and cleans the house.
00:31:18
Then they return a standard amount of furniture and other items to the house. A significant transformation occurs, removing all that junk over one weekend.
00:31:34
What struck me about the show was that it featured varied hoarded items—some folks hoarded collectibles like beanie babies, some hoarded tools, and others simply junk.
00:31:49
However, the one commonality in all hoarded houses was stacks of magazines, books, and newspaper clippings about simple living.
00:32:08
Beautiful photos of pristine uncluttered spaces, advice about organizing, and suggestions for decorating—all of these people longed for clean homes; they wanted it so badly.
00:32:24
Yet, they did not know how to transition their homes from that state to a livable one, believing a single big event was the only way to accomplish it.
00:32:41
They'd agree to be on the show for their homes to be cleaned out—an event not without drama, of course, as it's reality television.
00:32:58
However, at the conclusion of the show, there’s a big reveal featuring before-and-after shots of formerly filthy rooms restored to some semblance of cleanliness.
00:33:11
I recall an interview with one of the producers who stated this was the reason they stopped the show; they discovered that most of the people profiled, whose houses had been cleaned out and junk removed, went back to their hoarding ways.
00:33:29
The same tiny decision-making led them back to their previous result. An effective method for treating hoarding involves working with individuals living there over a long time.
00:33:46
This change involves adjusting their habits so that they clean a little each time they engage in activities—having the folks residing there do the tidying a bit at a time.
00:34:0
This method takes longer than a weekend to see results, but it effectively pulls them out of difficulty and keeps them out, rather than artificially vaulting them out only for them to fall back in again.
00:34:16
Unfortunately for that producer, though, this approach makes for very dull reality television. Our cluttered codebases operate similarly.
00:34:34
We struggle with them day in and day out just to get anything done, dreaming of the rewrite; if only we could rewrite it, we wouldn't make the same mistakes.
00:34:49
We should rewrite our jQuery soup into Ember, or our monolith as microservices. Sometimes this works for a bit—at least long enough to produce a triumphant blog post.
00:35:2
However, when the cameras stop rolling, and the work crew leaves, if you haven't altered the habits that got you there, you will likely find yourself back in that same frustrating position sooner than later.
00:35:16
People think it's the big mistakes that trip them up—housing isn't enough or the wrong framework. However, it's not the big mistakes that hurt you; it's the little ones. It’s a lifestyle; it’s a habit.
00:35:32
You can do all the rewrites you wish, but if you do not address the small issues that led to the chaos in the first place, you will only end up with a tangled network of microservices.
00:35:49
Just like you had a tangled web of class definitions in your monolith. Let me be clear: these are not individual habits; they are group habits.
00:36:4
This is why the individual professionalism ethos of the software as craft movement does not work. This isn’t due to individual developers being lazy or unprofessional; this is a team displaying dysfunctional group norms.
00:36:19
Change must originate within the group, and all developers have to participate. It may sound impossible, but let's discuss what everyone must do.
00:36:35
Much like dealing with roommates, everyone must contribute daily—washing the dishes they use, cleaning the toilet occasionally, and vacuuming.
00:36:47
They need to put their stuff away after using it in the living space. More complicated tasks contributing to livability can be left to those interested.
00:37:0
For example, reorganizing the kitchen cabinets or swapping out the couch can be left to those who care about it. However, the everyday tasks are what everyone must handle.
00:37:18
That means you can have a team where some are keen on refactoring, splitting up large classes, or creating new abstractions, while others are not. Not everyone has to constantly relocate the china cabinet.
00:37:35
However, everyone must wash their own dishes.
00:37:49
You might say, 'That’s interesting. What should I do if my codebase is already a hoard?' What if it's not that bad yet, but you want to ensure it doesn't get worse?
00:38:0
This is fine; let's keep going, but how do I reach that point? Let’s look at how this manifests.
00:38:17
Is this your team? Is your codebase a hoarded living room of legacy code with little goat trails of understanding running through it? Don’t worry; you’re not a bad person—it happens to everybody.
00:38:32
If you approach this problem from an engineering perspective, it screams rewrite. How could you ever organize anything in this space without clearing it all out?
00:38:47
Top-down planning works excellently for some well-defined engineering tasks, but it doesn't suit a lot of software development. It's not that we’re not engineering hard enough; it’s that engineering does not always work.
00:39:3
What actually works are two approaches. Your code is literally an interior space occupied by people, and to understand it, you will need to understand the people.
00:39:18
Here’s how you can go about it in four steps, and I’ll admit, I cheated because one of the steps has sub-steps, but stay tuned.
00:39:32
This method will apply to any codebase, regardless of language or framework. The first thing you need to do is not to make it worse.
00:39:45
When you enter that disorganized file, agree you will do the not terrible thing, even if you don’t have time to mitigate everything that's already undesirable.
00:40:0
When you see someone make a poor decision in a pull request, just remind them, 'This is what we agreed on—we're not going to create more problems.'
00:40:18
The second step is to value improvement over consistency. Five books stacked on a pile and one on the shelf is better than six books on the pile.
00:40:32
Perhaps next time someone reviews the code, they can help move one more book to the shelf. If you wait until you have time to move them all at once, it won’t happen.
00:40:48
This idea is particularly difficult for many because we're taught to prioritize consistency—ensuring similar operations look alike and convey information on their similarity through the code's structure.
00:41:5
But where does this tendency come from? It arises from the software developer version of simple living magazines showing you a beautiful, entirely consistent, abstracted codebase.
00:41:21
These pictures are lovely to write, but you cannot live in a place that pristine. The homes featured in those magazines are staged for the sale; they are as unlivable as a hoarded house.
00:41:40
For instance, in that room, where would you put your coat when you come in the door? Where do you put your handbag, messenger bag, or shoes?
00:41:54
The couch is not full-sized, which is a clever trick to make the room seem larger. Where do you set a drink when you’re sitting there?
00:42:10
Here’s another view of the same room. There’s no television or space for the Xbox, PlayStation, cable box, and wireless access point.
00:42:23
There isn’t anywhere for the mail, magazines, or books either. All that looks nice, but they’ve stripped away all the clutter.
00:42:36
Because clutter is personal, we require some clutter to feel comfortable; that's as true in code as in a home.
00:42:52
The composition of that clutter varies for everyone: if you enjoy reading, maybe it's books; if you're into video games, then it's game boxes and controllers.
00:43:8
If you're an outdoorsy person, it entails bikes, helmets, kayaks, and equipment. The things you use ought to be accessible and easy to locate—as much as possible, a livable space has to handle some mess but not too much.
00:43:25
Our simple living magazines show us unrealistically clean code when they set unattainable goals. Our software design books, blogs, patterns, and rules depict perfect, consistent, and abstracted code.
00:43:39
Code that adheres to the rules and is perfectly consistent is unobtainable, unless there's no one living there.
00:43:56
Even if you could attain it, you cannot live with it. A team can't survive in a codebase that's overly abstracted to the point where they cannot discover anything or establish places for their components.
00:44:12
Both extremes—complete clutter and pristine abstraction—are unlivable, both in code and in living spaces. If you have a piece of code you can’t comprehend or work with, two issues may be at play.
00:44:31
Perhaps it's too cluttered—you merely can’t differentiate relevant ideas from irrelevant ones. Or it could be too clean, to the point that relevant ideas aren’t even identifiable.
00:44:47
These two states can coexist within the same codebase, sometimes even in close proximity. What we need is livable code—somewhere between these two extremes.
00:45:2
Just as a livable home fits in between a simple living magazine and a hoarder’s reality, we need to find improvement over consistency. We need to be willing to endure some mess, for livability requires a bit of it.
00:45:20
The third principle is inline everything: stop putting in stories for refactoring. Taking a week off to fix one file is great, but it’s yet another big bang.
00:45:37
What you should do is learn to incorporate tidying into your daily tasks. Follow the Girl Scout rule: leave the campground cleaner than you found it.
00:45:53
If you approach your work this way every time, you’ll slowly chip away that debt. The fourth principle is liaison it.
00:46:7
This means you must consistently communicate with your teammates about what you’re doing. Not in a way that hides what you're doing—don’t lie about your actions.
00:46:25
However, treat refactoring and cleaning as part of your everyday workflow, while remaining transparent about it. I want to return to Fred Brooks and his paper, 'No Silver Bullet'.
00:46:38
I’d like to read his actual thesis statement, which claims, 'There is no single development in technology or management technique which promises even one order of magnitude improvement within a decade in productivity, reliability, or simplicity.'
00:46:56
I want to emphasize that he’s looking for at least one order of magnitude improvement—something improving our practice tenfold.
00:47:10
What he doesn’t state is that incremental improvements are impossible with tools or processes—and we know they're not. Those of us who experienced the shift to agile in the '90s know that it wasn’t a Silver Bullet.
00:47:24
However, it still marginally improved outcomes in most cases. What Brooks is concluding here is that order-of-magnitude improvement is impossible, meaning nothing in the realm of tools or processes signifies a useful paradigm shift.
00:47:40
What does this realm entail? I would argue that the realm of tools and processes pertains to engineering. Brooks and others writing software in large companies in the '80s considered their work to be engineering, of course.
00:48:2
They operated within this engineering box, realizing there were provable limits to its usefulness based on the problems they witnessed over time.
00:48:22
They didn’t recognize that this box could be restrictive, showing how people repeatedly encounter this cognitive dissonance throughout scientific history.
00:48:38
Individuals identify issues with existing models, yet do not foresee any new model that resonates, which leads them to function in the familiar paradigm while accepting some dissonance.
00:48:53
This is what I see within the pages of the 'No Silver Bullet' paper. I find it compelling; Brooks is so near a breakthrough yet insufficiently explores it.
00:49:6
He expresses cognitive dissonance: he recognizes issues with the current model, namely that projects often don't succeed, and he articulates clear frustration that nothing they attempt seems to yield better results.
00:49:20
He concludes that we cannot improve because there’s nothing else to turn to—yet, there's a whole spectrum of resources beyond that box.
00:49:34
He states that we do not know how to innovate in software and even goes further to assert it is not knowable. I agree that box itself won’t provide what we seek.
00:49:50
Framing software through an engineering lens is a dead end, and we have exhausted this approach. However, a shift in how we view code and creation will ultimately provide the answer we desire.
00:50:4
The Silver Bullet exists outside of the constraints in Brooks' original perspective from the 1980s. Let’s talk about those sub-steps related to communication.
00:50:18
When you want to undertake refactoring, don’t ask for permission. This is part of your job, yet be upfront about what you’re doing.
00:50:35
Similarly, don’t seek forgiveness for initiatives; doing this does not require authorization.
00:50:46
However, learn from your mistakes. Making these mistakes facilitates your understanding of the problems you're tackling and your familiarity with the codebase.
00:50:59
You’ll overdo the refactoring at times, undershoot it on other occasions, yet you will learn with each occurrence.
00:51:13
Seek advice; ask if you think you should refactor at that moment. However, it’s important not to take every piece of advice as gospel.
00:51:30
Ultimately, your role as a developer is to determine what necessitates refactoring, and you must feel free to make those calls, learn from mistakes, and collaborate with everyone else.
00:51:45
You need to reside here, and I think that deserves its own emphasis: you must live here. Our objective is to transform a codebase from a mere necessity into a space where you want to be.
00:52:0
I approached the question of what software is from two perspectives: how teams function best as creative groups generating experiences, and how codebases operate efficiently as spaces populated by people and their belongings.
00:52:15
What connects these perspectives is the shift from focusing on code itself to prioritizing people. However, over the years, I've often stated that the most critical aspect of software lies within the people.
00:52:30
Presently, I no longer believe that's entirely accurate. The most crucial part of software is not solely the code or the people—what matters most is the system itself.
00:52:47
The more we can regard software as an interconnected system of code and people, the closer we will move toward breakthroughs.
00:53:3
More importantly, we will inch closer to a codebase we are excited to work within. You can achieve this, irrespective of your current challenges.
00:53:16
By fostering trust amongst team members and strengthening those connections, your codebase will follow suit.
Explore all talks recorded at Rocky Mountain Ruby 2017
+4