Tidying Up Your Tech Property

A current internet topic is the tidying of clutter around houses, but for those of us who work in software, it's easy to boot up a development machine in a spotless room, only to be confronted with years of bewildering untidiness. Here are some buckets of problems worth thinking about:

Messy Code

The causes of this vary; some teams follow strict dogma on writing and wouldn't save the earth without writing a test first (and in fairness, that's one useful test down the line.) At the other extreme, regularly shippable value-to-end-user can become so all-powerful that only the shortest quick fixes ever get applied. In reality a cause common to both situations is that, whereas new feature code can be thought through clearly and cleanly, the sequential additions of unseen use cases make a fool of the most extensible code design if nobody feels enough ownership and responsibility to tidy it up. Where there is a mess, at least make sure it is a DRY mess, or the clean up can become significantly more onerous.

Breaking Tests

Sometimes tests are built too fragile, but more often they get that way as the code they were coupled with changes its nature and purpose. However it happens, it's more than just a nuisance. Tests often give their greatest value not when a new feature is being created, but when a forgotten feature is impacted by changes. If there are red flags that people ought to see, they'd better not be lost behind the tattered red flags that everybody expects and has a chuckle at.

Broken Builds

Builds used to be so complicated that being the build engineer was a significant role, and it still can be the case in some organizations. But often the comparative simplicity of modern builds mean the role ends up shared out, and so the build file is often slightly unknown, which is a piece of technical danger. Your tech lead doesn't remember what half of the build file does. By next year that'll be a quarter. The developer who follows him will spend his tenure trying to scratch the surface of its mysteries like a philosopher hunting for universal truth.

Too Many Tech Stacks

Words like polyglot make it sound quite clever, but sometimes using eight different tech stacks is like clogging a wardrobe with multiple suits that do the same things. Sometimes tech teams get overwhelmed just remembering the rudimentary level information to make such a broad set of technologies work. More technologies are better only when they each serve some special purpose.

Outdated Libraries

Even when third party libraries are brought in to solve a single problem and the consuming code is never touched again, security in a community solution wanes over time if a library isn't kept up to date. Moreover the best advantages of third party libraries are lost: answers from other developers, debugs, and growing over time to meet changes in best practice. 

Documentation 

When piles of paperwork stack up in random places, as human beings we appreciate that we will be unlikely to find things when we need them, or even to remember that they exist. Unkempt wikis can cause the same problems, and by not being able to identify a pattern/process/solution in a timely fashion, the chances of creating some of the previous buckets of problem are amplified. Make sure the important areas of documentation are cleanly organized so that people know where to look for them, even if they aren't 100% aware they've ever been created before.

Closing Thoughts

In an age when productivity frameworks are superimposed over technical leadership hierarchy, it can be hard for people at many levels to feel justified taking the time to keep things tidy. When a problem gets large enough that it requires more formal scheduling, it can be hard to communicate to business the intricacies of the change; from a functional point of view, it often looks like replacing one solution with something almost identical. However, like a freshman finding they are the only person around who will tidy up their things, tech teams know that problems will only get worse without directed effort. When something needs to get out of the door it's fair to take short cuts, but when environments are too much in disarray, it's no surprise if the productivity can't be found.