Predicting the future of your code
It all starts with poor design and ignoring the overall picture. This is how the story goes… You’re required to build a web page and you need to do it FAST.
You create the page and the page contains a SINGLE component, … you’re thinking: Hey, why over complicate it? I will create it inside the page, it’s the fastest solution, it will work , it will be readable … if more components will be needed in that page later on, we can always refactor the code…
The next developer that arrives to this page (it may be you) has another feature that he needs to develop, He first needs to waste time to figure out what parts of the code is related to the page and what parts are related the component, and by the time he finishes understanding, he thinks: Well I already wasted time, and the other developer placed that component here, nothing BAD will happen if I place my component just below the other component, It’s still readable, It’s not too much code, I understood what’s going on in here and I’m sure others will understand too…
The third developer that arrive at this page (it might be you) needs to understand which code is related to the two components… the state variables and functions are all mixed together, it starts to feel like a mess, it starts to smell BAD, So that developer will have a choice will he continue with this BAD design ??? Or will he do it right because it’s starting to be unreadable…. so he does the right thing and create a new file for his component, and import it to that original page….., but he does not have enough time to refactor the original page, he needs to deliver with reasonable time frame… so he leaves it as is… for later refactor
fast forward 1 year you have containers with a jumble of components in it, and a bunch of components that are required… the code is hard to read and hard to understand, and development time starts taking longer, so the responsible team leader is called to the flag to battle the monster that is in front of him, I mean hey he wants his team to be productive and who wants to work with an ugly code, spending the time all day investigating where you should place a single line… we want to move forward, we want to add features we don’t want to fix what is by now feels like a broken product.
And yes there are bugs, many bugs… So we start thinking about how we can make it better, we invent these amazing solutions to separate our code base and to create micro frontends, and micro services and micro this and micro that…
who wants to work on a monolith … it’s a BAD word … oh no.. you should separate everything make it small building blacks so you can require it like a simple library. It does sound great I mean who would argue with that suggestion.. so the R&D agrees and the team leads are happy because they think this will be their salvation.
Fast forward few months, the R&D team needs to add features and also align the code base to the new design, and a new developer has joined the team and you need to explain to him why when he needs to add a single line of code, he needs to first start 3 services, move between 4 files only to find out that he needs to add it in a different repo, so he will need to start that repo, develop on it and then acquire it to his project and integrate with it on the main project or another service or a core lib, and then wait for Jenkins to find out that it works and then wait with PR, deployment and integrations.. and all this for a SINGLE LINE OF CODE …..
It should not be this way and these things affect developer happiness and productivity, we have all been in that road, every tech company that is more than 2 years old has reached that point, and most 6 year old company is struggling to maintain a large code base that is a nightmare to maintain, so what can we do about it???
1. Time your most atomic task, from development to production, (think of the most complex scenario) if it takes more than the threshold time you think is reasonable, you should rethink that architecture.
2. Reduce complexity by limiting the number of files a developer would need to read while he develop new features
3. Reduce the amount of libraries you use in the product, this will make the learning curve lower and make coding easier.
4. Decide on a code structure that is needed to be followed across the codebase so developers can predict where the code is located and how it is composed.
5. If you working with Agile methodology, please please allocate time to refactor the code and do regular maintenance.
Happy coding :)
