Tags:
Every developer will have spent some of their time maintaining systems, whether that be a few small websites they've lovingly crafted, a deployment tool that pushes code to servers, or monitoring applications that can analyse and report on issues. Looking after and using a few of these is easily manageable, but the more you inherit, the more difficult this task becomes as you have to split your time across them all, making it more difficult to learn about them in as much detail. The popular phrase about being a Jack of all trades but a master of none comes to mind, as each new system introduced comes as the cost of another, and introduces infrastructure debt that can be hard to be rid of.
The following are (extremely simplified) scenarios of fictional developers to illustrate how this debt accumulates.
Scenario 1: A Backend Developer
Consider the typical scenario of a backend PHP developer who has to maintain a few websites. They're probably using a couple of CMS's, e.g. WordPress and Drupal, and maybe something built on an MVC framework such as Laravel. As well as this, they have to deal with servers, so they will need to know a bit about Linux command line, and they use a deploy tool to push their code to various environment servers.
This is a total of 6 systems (including PHP itself and the CLI stuff) that they have to use on a regular basis, so their skills are split (not equally, but probably distributed by usage) across each of them. Things are happily churning away when a request comes through which will require them to maintain another website built a long time ago on the Joomla CMS. The next day they're asked to test out a new deployment tool. Now our developer needs to split their knowledge across yet another system, and this process of knowledge dilution continues for each system added to the mix.
Scenario 2: A Frontend Developer
The second example is a frontend developer who splits their knowledge across learning JS, CSS, and a frontend built tool, like Gulp. They will also be using the same kinds of CMS's as a backend developer above (WordPress and Drupal), giving a total of 5 systems.
Now they want to try a new build tool that will do their CSS and JavaScript, so they pick Grunt. But that means they have some legacy projects still using the previous tool which they have to maintain that still use Gulp, and they don't have the time to update them all. In the same manner as our backend developer, they are getting spread across more systems, making it more difficult to specialise in any single one. Now that they're interested in Grunt, they want to improve their workflow even more, so add more NPM tools to their mix.
Scenario 3: Backend and Frontend Developers Working Together
It's fairly untypical for developers who aren't full stack to work in isolation; more often they work together, such as in a production company or agency. This brings its own complexities, as now they will also need to have a little bit of coverage overlap knowledge about each others systems so that they can better work together.
So, each time a backend developer adds a new system, the frontend developer needs to learn a little about that too, as it may have a direct impact on how they work. For example, the backend dev adds a new image optimising tool to the server, but it needs frontend developers to configure this for each set of images a website uses.
This behaviour applies the other way round also when a frontend developer adds a new system to their tool belt. They want to start using a new tool to compile their JavaScript as it can tree-prune, and this means that the backend developer now needs to know about this system in order to implement it on the deployment setup.
With each system added, the amount of knowledge needed across the team needs to increase to reflect this, and each individual has to spread their learning across more areas, but that often comes at the cost of not having been able to use that time to learn something else.
The Solution
Of course this is a simplistic way to look at the problem, as there will be some knowledge overlap, but for all the overlap there are likely to be just as many areas of difference. Consider it like a huge Venn diagram, where each circle is a system, and the overlapping areas are shared similarities.
There is clearly no doubt that over time, the needs of a developer and a business changes, and that tools and systems need to change accordingly, but it's important to consider what each change means, especially when working in a team, as each change ripples out amongst every team member. Ripples themselves aren't bad, but they could be deemed unnecessary if they're being created by changes for changes sake.
If you're working as an isolated developer, then your choice of tools is entirely up to you, and you should make the call on what makes sense for your situation. If you're part of a team, consider your colleagues who will have to also use those same tools you choose. Is your choice based on a real need, or do you just want to try a new technology? Can you make a good case for using a new system that your team can also agree in supporting? If you can't, but you still want to try out something new, speak to your team, see if you can agree a way to incorporate it and if it's feasible. A quick test is to just take 5 minutes (and only 5 minutes) and see if you have a genuinely good reason to add an extra system to your various stacks. Does it solve a problem you have, or you will have in the foreseeable future? Does it plug a gap in your workflow? Or are you just using it because you want to?
At the end of the day, it's up to you (and your team) to strike a balance between maintainability of existing systems and making sure nobody is spread to thin, and being able to use new technology that allows you to make improvements to your workflow. A cavalier approach of trying every new tool that comes along doesn't help create a strong team, can alienate some people, and can lead to type of technical debt that can get out of control.
Comments