These are the edited notes from my talk on scalability. Slides are at the end of this story.
When talking about application scalability, most people expect a deep dive on system design and software architecture. We all are technologists and passionate about those topics so I totally understand that. But before being an architectural problem, scalability is a cultural and operational one.
“organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.”
— M. Conway, 1967
Throughout my career, either as a internal developer or an external observer, I have witnessed Conway’s law hunting down countless software development teams. (elaborate)
In particular, I want to delve into code quality since I see it as a reflection of the culture of the company but also of the individual team members forming the team that will take on the challenge of scaling an application.
What is high quality code? To me (and to many people I talk to), it is code that:
- reduces complexity
- is reusable
- respects conventions and is cohesive
- documented (more about that bellow)
- tested
- and of course versioned controlled (with meaningful commit message)
You probably already are asking yourself “Why does code quality affect scalability?” good question, glad you asked! Here is why:
Have you heard of the broken window theory proposed by James Q. Wilson and George Kelling in 1982?
The theory states that maintaining and monitoring urban environments to prevent small crimes such as vandalism, public drinking, and turnstile-jumping helps to create an atmosphere of order and lawfulness, thereby preventing more serious crimes from happening. (link)
Your code is the window to your application. Take care of it, fix it on time and by doing so you will prevent more crime from being done. When developers see that some parts of the code are a mess, hacked or done without care, they naturally lower their own standards — I have seen this happen over and over again, even with the best developers, and I don’t blame them, it is just how our brain works.
Something really important in high quality code is the abstraction. Do yourself and your team a favour and do not hardcode your database preferences in the code — and by that I mean — SQL queries in the middle of your business logic code. Use abstractions so that when the time comes, you can easily improve, shard or even interchange with different technologies.
Now, on documentation. I often hear people debating about documentation’s usefulness. Before being useful for the end customers, documentations is the best way to describe to yourself and your organisation what you are actually trying to achieve and code. How many times have I worked with teams that started coding before knowing what they were really trying to build … and __all__ the time, it ended, well.., really badly: wasted time, spaghetti code, lack of focus, etc. Documenting the code prior to writing it is actually an incredibly efficient solution to clarify what you are trying to build and how you are going to build it.
This is actually not a new idea. Tom Preston, CEO of GitHub wrote a nice blog post about readme-driven development in 2010.
Consider the process of writing the Readme for your project as the true act of creation. This is where all your brilliant ideas should be expressed. This document should stand on its own as a testament to your creativity and expressiveness.
- Tom Preston.
At Amazon, we use a similar process: Before any developer writes a single line of code, they have to write the hypothetical product’s press release and FAQ announcement. This working backwards approach forces the teams to get the most difficult discussions out of the way early in the process.
High quality code and a good documentation is not however your ticket to scaling to 10 million users, but it will insure that you maximise your time on solving problems that actually help you scale.
- Adrian