Author: Sarah Mei Publishing/Release Date: October 12, 2017 Link: https://www.youtube.com/watch?v=8_UoDmJi7U8&ab_channel=Confreaks&t=0s
If computer science fundamentals are really that important, why are interviews the only time I need to think about runtime complexity?
Conway’s Law
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.
She gives an example of a startup team with 5 people, number 1 being a manager type who would broadcast information out to the rest of the team. The team also has fairly good internal lines of communication.
This team produced a system comprised of 5 different services, written in 5 different languages. Service number one was an orchestrator, but the other services talked amongst themselves as well. Their code quite literally reproduced their organisation structure.
When you have a team that’s all working in the same codebase, this principle can be harder to see, but it is still there.
This is useful because if you see a problem in your code, it is symptomatic of a problem in your communication structure.
Messiness in the code reflects messiness in the team.
If you are having problems writing your software, you can approach it from two possible directions
- Make changes in your team to drive changes in your codebase; or
- Make changes in your codebase to drive changes in your team
For any given issue, you can apply one or both, depending on which seems more effective.
Some problems look like they are purely code-based, some problems look like they are purely team-based, but all of your problems are both.
She gives an example of a codebase that contains three implementations of user login. You could consider this purely a code issue, it being technical debt that needs to be paid at some point. It also represents a communication deficit amongst members of the team, because if they were in better communication, they wouldn’t have implemented three versions of user login.
If you fix one side of the problem without addressing the other, you are likely to see the problem return.
The classic metaphor for a software team is something around manufacturing — we are making a product. Maybe it is an an assembly line where workers assemble a product, or its a workshop where you hand-craft each one individually. In each case, the central idea is that we are producing a product of some kind.
Modern software development no longer fits this description as cleanly. We aren’t so much creating a product as we are an experience. It’s more like a group of theatre people putting together a play than it is a group of workers fabricating something physical.
Teams are more successful when we think of them as groups of creative people collaborating.
On Software Architects
The idea of a software architect has been around for at least 50 years. The architect role is often the final step in the non-manager, individual contributor career path. The software architect, as in the real world, creates the plans and hands them off to other people to do the actual building. The problem with this way of thinking is that is no longer reflects how software development works.
Building a building in the real world has 3 phases:
- Planning
- Construction
- Maintenance
Software projects used to look like this. These days, software projects are never really done.
An analogy might be that the infrastructure (in this case seemingly in reference to your choice of software framework), the stuff software developers depend on is the building, and we just live inside. A lot of software infrastructure is hidden from us, in the same way that the steel skeleton of a skyscraper is invisible to the tenants once they move in.
Most of our applications take up space inside one of these pre-built structures. The interior space they provide for us is changable. It’s a much greater cost than changing your code, but you can change it.
Your choice of framework, the space layout you choose to be constrained by, shapes how your code turns out.
- Angular
- A big open loft space with no walls
- You can do anything, but you have to do it yourself
- Ember.js
- A single-storey ranch house with defined rooms
- You can change the purpose of the rooms if you want
- It will be a little bit of work
- A single-storey ranch house with defined rooms
- React.js
- A modular house that can be assembled at a factory and shipped to you
When you’re building an application, you have a number of different space layouts to choose from, and each one is optimised for something slightly different. Your stuff will probably fit in any of them, but it may be a better fit in one than the other.
Keeping with the building metaphor, there are some jobs that involve working on the buildings themselves, or the foundations or designing new buildings. Primarily however, the jobs are in creating the applications that inhabit these buildings.
The interior space model of software development more so than the construction model, makes clear what is easy to change, and what is hard to change.
Change exists on a spectrum of difficulty
Easy
Changes to your application
Extensions to the framework
Changes to the programming language
Changes to the operating system
Changes to the hardware
Hard
No changes are technically impossible, but following on from the building a house metaphor, some require opening up a few walls.
The goal when writing code then, isn’t to write something and move on. The goal is to make it sustainable; livable, for the team that inhabits it.
Livable for a group of people, depends on the people. A livable house for 2 adults and a baby is different from a livable house for young adult room mates.
Livable for code means you make the changes and additions you want without undue confusion or annoyance. Things are where you expect them to be.
Everytime you get someone new on your team, it’s like getting a new room mate.
On happiness in the team
Your day-to-day happiness depends a lot on the people who are in the space with you. Less on the stuff in the space, and even less again on the shape of the space. That is, it’s the people you work with, rather than the code or the framework.
On the path to mess
A messy codebase doesn’t arise out of laziness on the part of the developers. It is a product of many small decisions over time.
A building with broken windows looks like nobody cares about it. So other people stop caring. They allow more windows to become broken. Eventually they actively break them. The despoil the facade with graffiti and allow garbage to collect. One broken window starts the process towards decay.
Hoarders
A parallel is drawn between a messy codebase, and show reality TV show Hoarders.
Hoarders documents people living in unlivable houses, to the point where someone they know requested an intervention. If the hoarder agrees to the intervention, the transformation is very dramatic — a work crew swoops in and carts the majority of the hoarded stuff as trash, cleans the entire house out, and then repopulates the house with a reasonable amount of furniture and stuff. Big bang — all over the course of a weekend.
She notes that in the show, the one common ocurrence across all of the hoarder houses, is that they all have magazines of pristine uncluttered living spaces, advice about organising and the like.
One of the reasons the show was discontinued was because it turned out that participants who had their houses cleaned up in this way eventually went back to a hoarded house.
A much better way to fix the problem of hoarding is to work with the hoarder, over a long period of time to help train them out of their behavioural patterns that lead to hoarding. Have the people that live their do the cleaning.
Cluttered codebases are the same. We as developers dream of that big rewrite. If we could rewrite it, we wouldn’t make the same mistakes.
Much like with the hoarders however, a big bang rewrite is only a short-term fix. If we don’t change the habits that got us to where we are now, we’ll end up in exactly the same place, saying exactly the same thing about another rewrite.
Habits of the group
The habits that lead to messy code aren’t habits of the individual, but of the group. They’re group norms.
This is why the individual professionalism ethos of the software as craft movement doesn’t work.
This isn’t individuals being lazy or unprofessional, this is a team with dysfunctional group norms. Change has to come from the group, and all of the developers have to do it.
You can have a team where some people are interested in refactoring (splitting up a big class, creating new abstractions etc.) and some aren’t. But everyone must contribute to the every day upkeep of cleanliness.