00:00:00.000
I was not expecting to be up here this morning. This was decided about 15 minutes ago, so I apologize for being a little nervous just now.
00:00:13.139
I had just found out that I was going to do this, and I had been thinking, okay, I need to talk about the t-shirts and the socks. Oh my God, what are we talking about again? Okay, so hello, good morning.
00:00:24.539
I am actually very disappointed that we can't have Fara here today. She's a really amazing person, and I do encourage you to check out a lot of the stuff she has written in various reputable places, including The New York Times and The Huffington Post.
00:00:42.450
She's got some really interesting things to say, and I wish the travel gods had been kinder to us. I’m going to talk about software architecture. Fara is an attorney who had some interesting things to say about that, and she previously worked at Facebook.
00:01:04.769
I’m not going to talk about social media and privacy because I don't feel super qualified for that. I already introduced myself this morning, but I’ll introduce myself again. I am a software architect in the UX engineering group at Salesforce.
00:01:18.540
Before that, I spent about half of my career in software consulting for about 10 years. I’ve worked in companies of various sizes, so I've been a developer, a manager, a team lead, an expert, and the newb.
00:01:37.619
I think the thread that has tied my career together has been my community work. This includes what I do at Ruby Central. However, the thing that has impacted my career the most is RailsBridge, which I co-founded in 2009.
00:01:55.649
RailsBridge was one of the first organizations to offer women and other gender minorities a free place to learn programming. When we started in 2009, there were no code schools, and the first coding boot camps graduated their first cohort only in 2012.
00:02:15.370
So, there was no place to send people who were excited about learning programming other than meetups, conferences, and books. To be honest, at the time, we weren’t even really sure there would be any women interested in learning Rails.
00:02:29.049
We posted the first meetup through SF Ruby's new DEP account, thinking that worst-case scenario, the two of us could have lunch together. To our surprise, less than 24 hours after we posted the first meetup, it was completely full with a waiting list of 125 people.
00:02:41.890
Our workshops helped generate demand for code schools because they demonstrated that there was an underserved market. The folks who didn't come to programming through computer science, like I did, still had the mindset for it, albeit in a very different way.
00:03:08.230
In doing these workshops, I met many people who took to programming immediately, even though some had never written any code before. I had been taught that my way of thinking about programming was the only way to approach it, which was fairly math-oriented and engineering-like.
00:03:18.790
However, right before me were people who were clearly naturals, who loved programming, and who didn’t possess a mathematically oriented brain like I did. This fed my internal sense that something was wrong with how we thought about software.
00:03:36.760
In reflecting on this, it amplified a voice inside me that suggested we were using the wrong model because it wasn't explaining these different approaches. I was trained to think about software as engineering, architecture, and manufacturing; the very terms we use reinforce this model.
00:03:56.889
For instance, if we are crafting a product, why is software never considered 'done'? If we're engineering solutions, why can’t we plan for everything? If we're architects or builders, why do so many projects utterly fail to complete? And if computer science fundamentals are truly essential, why are interviews the only time I ever need to think about runtime complexity?
00:04:29.950
The question that looms over all of this is: despite all the advice, best practices, rules, and resources available on software design, why do so many codebases become unwieldy, unusable, and unfun places to work? Has anyone ever worked on one of those? It just feels like you are slogging through molasses to get anything done.
00:04:54.190
I've felt a vague sense of wrongness ever since my computer science classes in college, but it's taken me a long time to articulate it. It has taken me even longer to consider what an alternative model might look like. I’ve been giving talks around this central theme since around 2012.
00:05:22.300
While writing code and engaging in pair programming with other developers, I have been contemplating two models for software: one for development teams and the other for the codebases that they work on.
00:05:36.070
These models help us capture software as it is when done well and, like any good model, they help us understand what to do in novel situations. We need two models because software is composed of two related yet distinct entities: the team and the codebase.
00:05:47.080
One of the most influential ideas I've encountered regarding software development is something known as Conway's Law, formulated in 1967. Conway's Law indicates that the structure of your code will replicate your team’s communication structure.
00:06:11.590
This might sound abstract, so let me illustrate it with an example from an early startup I worked at, which had a small team of five engineers. The CTO tended to broadcast information to the rest of the team. Due to the size of the team, the communication structure was functionally flat and formal lines of communication were good.
00:06:48.009
However, the software architecture consisted of five different services written in five different languages. The main service acted as the orchestrator, but the others communicated amongst themselves as well. In this case, their code literally mirrored their organizational chart.
00:07:08.009
When a team works within the same codebase, it can be harder to discern these patterns, but they still exist. The usefulness of this idea is that if you see a problem in the code, it reflects a problem in your team's communication structure. Messiness in the code reflects messiness in your team interactions.
00:07:32.750
For any issue you face in software development, you can approach it in two ways: you can make changes to your team, which will lead to changes in the codebase, or you can change the codebase to drive changes in your team. Depending on which seems more effective, you can pursue either or both directions.
00:07:52.610
Some problems may appear to be solely code-related, while others may seem team-based, but every problem encompasses both aspects. For example, if your codebase includes three competing implementations of a user login, you might view it as purely a technical problem that requires addressing technical debt. However, it also reveals a communication deficit among your team members.
00:08:16.740
That’s why both models, the team and the codebase, are equally important and distinct parts of a software system. This talk focuses primarily on the codebase side of that equation, although I’ll touch a bit on the team side.
00:08:30.260
In discussing Conway's Law, I want to introduce another idea that underpins most of my thinking about software: a paper written by computer scientist and software engineer Fred Brooks in 1986. The title of his paper is 'No Silver Bullet: Essence and Accidents in Software Engineering.'
00:08:50.130
Brooks is better known for his book 'The Mythical Man-Month,' but I find this paper much more compelling and relevant. I read it about once a year. The central thesis of the paper is that it is impossible to create a tool or process that improves software engineering by orders of magnitude.
00:09:10.740
Brooks posits that there is an irreducible complexity in software that simply doesn't exist in other types of engineering, such as civil engineering or hardware. When Brooks wrote this paper in the 1980s, chip speeds were doubling every 18 months, and people believed there must be a similar leap possible in software.
00:09:34.530
However, Brooks suggested that something different about software prevents it from conforming to the same rules, and hence, there is no single magic approach that can dramatically increase productivity. I’ve been mulling this over for many years and my gut instinct tells me he was right.
00:09:55.900
One of the things I often discuss in relation to teams is that our main metaphor for them often resembles a factory, where workers are assembling a product. Alternatively, one may say it is like a workshop where items are hand-manufactured with tools.
00:10:11.850
However, this does not accurately reflect how we write software in this modern era; software is not akin to a physical product anymore. It functions more like an experience that incorporates the development team, the code, and even our customers.
00:10:28.370
When done well, software development feels more like a group of theater performers collaborating to put together a play, rather than just employees fabricating something physical. Teams are more successful when we think of them as creative groups collaborating.
00:10:44.639
There's a wealth of research about collaboration that can be applied directly to your software teams. By crafting teams as creative groups, we can predict behaviors with more accuracy than with a traditional manufacturing model, even though many of us in tech, particularly programmers, are not used to considering our work as creative.
00:11:10.579
Now, the challenge is how to make a similar shift in thinking about code. The difficulty comes down to how we conceptualize architecture. I think there's an irony in my personal situation, as I recently took a job at Salesforce, and my title is now architect.
00:11:35.880
For 50 years, we've been told that software development resembles architecture, implying that the careful and methodical assembly of software systems can be modeled after the careful assembly of physical buildings. In early careers, our jobs felt more like construction, where we followed someone else's designs.
00:11:57.459
However, being an architect has always been the end goal, even if we don't label it that way. Despite making jokes about the term, at least on an individual contributor path, we all wanted to be the person making the models and plans to hand off to builders.
00:12:16.700
Nevertheless, the issue is that this way of thinking about software doesn't genuinely reflect how it works anymore. Creating a building has three defined phases: planning, construction, and maintenance. Different groups carry out each of these phases, unlike software projects, which used to mimic this structure.
00:12:45.419
Initially, software projects were temporary, eventually becoming finished products, often put onto CDs and mailed to customers. Developers would then hand the project off to a different team for maintenance and move on.
00:13:00.110
In the current landscape of web applications and continuous deployment, sometimes hundreds of times a day, software never seems to be truly finished. This shift has affected other areas too; mobile apps and games, once the last holdouts of traditional three-phase models, are now continuously updated.
00:13:26.540
Software has become easier to change, unlike physical structures which remain enormously expensive and challenging to modify post-construction. Anyone who has ever priced out remodeling their kitchen knows what I mean. $40,000 later, all you might have done is move your sink seven inches to the right.
00:13:44.900
This difference extends to costs and potential risks; software adapts quickly while physical buildings and infrastructure remain much harder to alter. In essence, the goal should shift to maintaining a livable codebase for developers, as opposed to a construction project.
00:14:10.440
If we view our codebases as places where we live, the aim shifts from finishing the code to maintaining it—making it livable for ourselves and future developers. A livable codebase means having the ability to make changes and improvements comfortably.
00:14:43.310
What is livable code? It means you can make the necessary changes and additions without undue annoyance. You know where everything is and how to find it. Just as in a house, what’s livable for one team differs from what is livable for another.
00:15:21.920
The concept of livability varies depending on the people. What's livable for one senior developer and four junior developers is different from what's livable for a team of five senior developers or a single parent with teenagers. So, making codebases livable is an ongoing process.
00:15:43.390
Every time someone new joins the team, it’s like getting a new roommate. They may have different preferences or habits. Over time, the team needs to work together to adapt and create a livable space for everyone.
00:16:02.730
Your happiness in a codebase depends on the people you're working with as much as it does on how well the code is written. If the internal space isn't livable, how do you improve it, especially if you're starting with a chaotic foundation?
00:16:38.200
Why do many of our codebases end up cluttered and difficult to navigate? This reality resembles the messy kitchen issue. It often starts with small decisions that compound over time, leading to despair and an overwhelming feeling of chaos.
00:17:10.350
Much like how households become cluttered, codebases can accumulate issues that lead to an unlivable environment. The TV show 'Hoarders' showcased this reality as individuals living in cluttered houses often sought out drastic interventions to clear their spaces, but they frequently returned to their former states.
00:17:46.100
The solution is typically gradual; changing habits over time rather than relying on a one-time intervention to declutter once and for all. This philosophy parallels how we can systematically clean up a chaotic codebase.
00:18:14.000
Our cluttered codebases often result from small decisions made over time. We wish to clean up the mess in one fell swoop and rewrite it to something clean and organized. Structured thinking often leads to duct-tape fixes that barely scratch the surface of the core issues.
00:18:43.160
It's not the big mistakes that create chaos; rather, it’s the accumulation of smaller issues and poor habits that lead us to tangled frameworks. The solution involves changing collective habits, as opposed to isolating individual practices, which won't address the larger systemic issues.
00:19:11.110
What does it look like to have a codebase that is already cluttered? How do you prevent good practices from devolving into a hoard? It's possible to create a livable codebase, but it’s a constant effort.
00:19:35.130
The first rule is simple: don’t make it worse. When you encounter a poorly written file, commit to doing no further damage, even if time constraints make it hard to address all the existing issues.
00:20:12.720
The second rule: value improvement over consistency. If you can improve the state of your code even slightly, it’s better than waiting until you can make everything perfect.
00:20:35.440
Sooner or later, if you commit to improving one aspect of your code at a time, those small gains will compound for a greater overall improvement.
00:20:55.430
The third rule states, inline everything. Refactor code in real-time while addressing stories that have immediate business value, rather than letting substantial issues fester until they become overwhelming.
00:21:18.270
The fourth and final rule is to foster communication. For those of you who are introverted, this doesn’t necessarily mean talking face-to-face. It can be done through emails, chats, or any form that you prefer, but ensure you communicate with team members on progress.
00:21:43.580
Your progress should be shared with the project management team so they understand your intentions. This creates transparency and trust in building the collaborative efforts needed to maintain a livable codebase.
00:22:09.110
Your communication should also encourage involvement among your colleagues. Many are not aware of proper coding practices, so sharing experiences and suggestions helps elevate the entire codebase.
00:22:27.920
Building and maintaining codebases need to be a group effort. The goal is to transform your codebase from a place of dread to a space that is enjoyable to work in.
00:22:56.070
'No Silver Bullet' holds much insight into the nature of software development. There is no magical process that yields significant improvements to productivity; rather, it's maintaining a persistent effort towards incremental enhancements.
00:23:19.340
Brooks highlights the necessity for paradigm shifts outside the conventional frameworks we have operated within. These shifts start when we realize that existing views of software engineering limit our potential for growth and enhancement.
00:23:41.410
Acknowledging that software development is a complex system incorporating both code and people allows us to rethink how we approach our work, leading to refined practices and an overall happier and more productive environment.
00:24:08.940
In summary, there is no singular 'silver bullet' solution for improving software practices. So, focus on building trust among team members, nurturing those social bonds, and the codebase will inevitably follow.
00:24:29.890
Thank you very much.