Tech Team Cancer

Hi guys

I keep promising that I will be posting frequently, and then life happens. I will continue my posts and tutorials and trying to share and disseminate things I’m learning or have learned over the course of my career.

I’m incredibly lucky, not only do I have my own experiences and exposures to draw upon when trying to make decisions, but I have a number of friends in development, from starting their careers right through to development managers and such. Of course, it would be unfair for me to take all of the credit for the things I’ve learned along the way, and at some point in the near future I might post a list of people I’ve learned from, but it will be a long list; and it would be wholly unfair for me to miss anybody crucial out of that list. It’s been a long career so far and I’ve met a lot of people.

Anyway, today I want to cover a topic that’s quite close to my heart. I received a huge compliment the other day from a long time friend of mine, Oliver Sarfas, he was saying that he has just picked up a piece of software I’d developed. Now I want to throw some context into this, I first met Oliver when I was only a couple of years into my career. We have stayed in touch the whole time, but were professionally reunited at my last role.

This particular piece of software, it’s fair to say, is quite complicated in its structure; in that very little is hardcoded anywhere. I was taking a matrix of equations and building them into a data structure, running them against years of legacy data as a rule by which to calculate some financial information. In terms of fluidity and flexibility it’s one of the most complicated bits of software I’ve built. It had a feature or two that I didn’t get to finish before leaving for my current role.

Anyway, Oliver was tasked with finishing up the project by building some of the functionality I didn’t get chance to do. He sent me an email, the long and short of this email was a thank you for writing code using industry standard techniques and leaving decent documentation. I can only presume following PSR-2, known design patterns, and decent naming conventions played some part of this.

This really conveniently brings me to the point of this post:

Tech Team Cancer

It sounds like a really horrible thing to refer to, but truthfully the things I am about to describe are cancerous. I’m not pointing at any of my previous roles here, everyone does at least one of the things on the list, some companies are better than others, but generally, these things help kill tech teams:

1. Not Leaving Documentation (Ivory Towering)

There is nothing worse than finding yourself having to work on a project you know nothing about, that has no code comments or documentation attached.

One thing I would like to say on this, however, is code comments are great tips for a developer. But code comments document that piece of code, that module, that class. They don’t document the over-arching design or principles of the piece of software.

Documentation is essential in other developer’s being able to work on your software.

2. Not Following Patterns

This is a bit of a weird one. Using known design patterns, and principles, and everything else does help your code’s maintainability. But what I really mean here is being consistent, across all of your code (really it should be across all of your team’s projects). Any convention is better than no convention.

If you have a piece of software and you name all of your classes following PSR-2 standards and your namespaces follow PSR-4, great! Get everything else consistent too, table and field names are a really common one for this.

3. Not Knowing When You’re Out Of Your Depth

This is another seriously fluid one. Any time you are out of your depth is bad. It doesn’t matter the context. Don’t fully understand the specification, don’t fully understand what they’re aiming to gain, or the use case, for this software, don’t understand the technologies you’re using. Any of these things lead you to build bad software.

What usually happens, in my experience, is that you, for want of a better phrase, blag it. Blagging, in development, is terrible. It means you don’t have a plan, if you don’t have a plan how can you have a coherent software design and accompanying principles?

If you have none of those things you’re destined to end up with spaghetti code, indecipherable nonsense and, as you learn more about what you’re supposed to be doing, horrendous shoe-horning to make functionality work.

The big problem with this one is that if you fall foul of it you will definitely fall foul of the other points here as well.

4. Bad Commit Messages

We’ve all been in that position where we’re asked to fix a bug on an existing piece of software. Fair enough. And then we look at the code, and all we can say or think (depending on your personality) is “Oh for ****s sake, what the **** was that **** thinking?! Seriously why the **** would you do that?” and this usually lasts for a few hours, before resigning yourself to shoe-horning in the resolution or stating it has to be rebuilt.

This is where a decent commit message goes a long way, and a code comment. If I have to do something a bit nasty, dirty or something that would get my immortal soul cussed out once I’ve left the office, I leave a code comment and a commit message; keeping professional but saying something like “This is a workaround for requirement X which was introduced after the original specification; if you change it Y will happen and you will also need to check Z” – because that’s the kind of information I would like to find if I were inheriting the maintenance of that code.

A good commit message is the difference between “Why the hell did you every hire X? He didn’t know what he was doing!” to “Ah, right. I see why he did that, it sucks, but I get it”.

5. Relying on Tribal Knowledge

This one is so much more dangerous than it sounds. When you build something, or when you fix an issue. This one isn’t just for developers either, testers, client facing staff and project staff are all guilty of this (usually). If you know something about a project or a piece of infrastructure it really does need to be written somewhere.

Take this real world example. I was working on a large and complex project which was business critical for the company that I was working for at the time. We were nearing the end. Luckily I keep documentation and code comments pretty up to date and always communicate how I’m working on. Unfortunately one Friday afternoon, I’m on my way home from work, all is good, we’re ahead of schedule and everything is great with regards to the project.

Then I’m on my way home, hit oil and come off of my motorbike. I go rolling up the A14 in Cambridgeshire, breaking and dislocating my shoulder and snapping my thumb. That’s me unable to drive for about 12 weeks in total. I was really lucky, firstly I didn’t die. Secondly, I used to work part remotely, so was able, within a couple of days and a makeshift injury-friendly work space, to get working again.

Imagine if it were worse, or if I couldn’t have worked remotely. The company I was working for would’ve been right up the creek without a paddle.

In Summary

To summarise this article. The main problems any development team, whether growing or shrinking, young or old, is information and sharing it.

Whether you’re sharing it through documentation, code comments and git commit messages. Or however you’re sharing it. Whether than information is software design, client facing, client requirement, anything at all. If ever there is a piece of information that you, and you alone, have you need to find a way to share it; otherwise you really are asking for something to go wrong with no conceivable disaster recovery available.