As developers, we spend thousands of hours seeing the world through the lens of code in a digital world. But have you ever wondered if you should improve your own quality of life in this digital world?
In our projects, we work on many tasks that require all of our expertise to implement new features, investigate and resolve bugs, and many others. On a daily basis, we deep dive into debugging and reading code, probably with more frequency than actually typing new code.
We take a lot of time learning the way the code is structured; the good or bad practices that are followed; all the components, modules and third parties that exist in the project code; and all the technical aspects of the project.
The more time we spend on the project, the more we build and have a second life there. So, let me ask you, is this digital world where you live… and is it such a nice place to spend so many hours?
Let’s put it into a different perspective. Our project source code and architecture are like a community, neighborhood or city — depending on the size of the project — it might even look like a whole world. Every piece of the project has a function and a meaning to exist. All the components are like buildings or functional structures in this virtual world.
If we think about architecture, imagine a monolith city like a medieval, fortified, wall-protected city, that connects to other services outside of the city, but most of the important concerns happen inside.
A Service Oriented Architecture (SOA) project might be more like the city of Budapest, where we have “Pest” connected to “Buda” with a river in between, the Danube. Pest is the chic and touristy side — where the fun happens — with a lot of interaction, kind of like the Frontend world. Buda on the other side is more classic and residential, functional but organized. It is the Backend world. Both parts are connected by bridges, APIs, like the famous and beautiful Chain Bridge.
Microservices might be more like an archipelago, with many different islands, of different sizes, and all of them connected and communicated in different ways. Information flows all around in buses, boats or trailers.
Why is it so important where we live in this virtual world? Well, every time we build a new component, it is like a new building or piece of infrastructure in the code city.
If you live in a nice and modern city, and someone puts a very ugly and unappealing structure close to a beautiful park, it will stand out. And it will be very clear that it is out of place. However, if you put the same ugly, almost falling structure in an unsafe or undeveloped neighborhood, it will probably look like the rest of the structures there.
The well-known “Broken Window” theory by James Q. Wilson and George Kellin says:
“Social psychologists and police officers tend to agree that if a window in a building is broken and is left unrepaired, all the rest of the windows will soon be broken. This is as true in nice neighborhoods as in rundown ones. Window-breaking does not necessarily occur on a large scale because some areas are inhabited by determined window-breakers, whereas others are populated by window-lovers; rather, one un-repaired broken window is a signal that no one cares, and so breaking more windows costs nothing.” (https://www.theatlantic.com/magazine/archive/1982/03/broken-windows/304465/)
The same thing will happen in your codebase. If you build a very unacceptable or deficient component, it is very likely that another citizen (teammate) will follow yours as a guide and soon will have many of those. So, our codebase dictates the way things are done and built there.
Doing things right matters. At any point in time, someone — it can be any developer, an intern, or even worse, your future you — who will complain about how much time they spend fixing or understanding a code that was poorly written.
Let me tell you a real experience and scary story. I worked for many years on a huge project that started as a regular monolith. At some point, it grew so much that it turned into a monster, a big city of modules. Each module was a city of its own and had its own rules and ways of doing things, but it was all connected to the big application. Something like NYC, that’s divided into five boroughs, all very different among them: The Bronx, Brooklyn, Manhattan, Queens, and Staten Island; but all connected via the subway, streets and bridges.
There was a specific module that when I was assigned to work there, I knew it would be like if someone would have asked me to go and visit a very dangerous neighborhood… a favela. Why? Because I knew I would be stolen there. My time would be stolen, my mental peace, my productive feeling, everything.
Just imagine: most of the files contained 4,000 lines of procedural code with big chunks of hard-coded complex SQL queries. Identifying a solution for a fix always took no less than a week. The code was scary, but it was also fragile. Any change would imply another long time of testing and redoing because as most of the time happens in programming, things do not work right the first time.
On the other hand, there were some other very well-architected modules, where I really enjoyed working. Here, doing changes or adding new features was really easy in terms of how everything was created. Everything was using a proper ORM, MVC pattern and following good software principles.
We followed Sandy Metz’s advice and rules for developers, and everything was easier. https://thoughtbot.com/blog/sandi-metz-rules-for-developers
- Classes can be no longer than 100 lines of code.
- Methods can be no longer than five lines of code.
- Pass no more than four parameters into a method. Hash options are parameters.
- Controllers can instantiate only one object. Therefore, views can only know about one instance variable, and views should only send messages to that object.
Our codebases, like cities, are constantly evolving and changing. We add components, buildings, bridges, roads and sidewalks. But there is always room for improvement. We have bottlenecks, traffic jams, abandoned buildings and pollution, to name a few. The development team knows those pain points, they are usually called “Tech Debt,” right?
If you start seeing the code like the community where we live, you are going to only want the best of the best for your surroundings. Therefore, it is our responsibility, as citizens of this virtual world, to make sure there are no broken windows, no problematic neighborhoods or non-functional parts.
So, make sure you are building the place where you wanna live, or at least a world where your future self will be healthy, happy and proud!
