I have recently heard a genuinely true argument: programming comprises of 95% frustration when it doesn’t work and 5% of unrestrained pride when it works.
When it eventually starts to work, we sometimes get carried away in the moment and set our code within the production environment and then, a moment later or a longer while later, a team member or the boss or a client comes to us and says: “It doesn’t work – it’s your fault!”.
You may try to defend yourself with the cliché “It works on my computer” or “It’s not a bug – it’s a feature”, but such statements rarely bring the desired result. The truth is that we often aren’t the ones responsible for errors that come up during the execution of a project.
I would like to present some tested methods that will be helpful in battling against such accusations.
1. An orderly creative process
We all work according to some methodology. This may be the infamous Waterfall or the praised-to-the-skies Agile, or any other variation derived from the two. And this is a good thing.
What we shouldn’t do is just saying we have a methodology when we don’t truly practice it. I watch a huge number of projects run within what I tend to call Chaos Driven Development.
These projects are characteristic of the fact that anyone can be their hero, because the more you work, the greater your contribution is… Sounds like a fast lane to burnout? It surely does to me. More importantly, the chaotic development process deprives us of the means to defend ourselves. While an orderly process enables us to answer like this:
“Why isn’t it done?” – “It wasn’t included in the Backlog”. – In such a situation, tasks aren’t being executed merely because someone said they weren’t supposed to be executed, but because there is a structured development plan.
Thanks to it, the tasks are usually well-thought and this alone facilitates the development of the most desired functionalities.
Hence: “Why isn’t it done?” – “It wasn’t included in the Backlog”. If we make sure the description is complete, we secure the grounds for defence as well as enable ourselves to execute the task according to the client’s requirements.
The list of such examples is long, so it’s worth paying attention to task documentation, regardless of whether it is recorded with a dedicated tool, such as Azure DevOps, Jira, or with a simple spreadsheet.
2. Numerous teams – which one is to blame?
In most cases, your client puts all the blame on the visual layer. It’s natural that someone without the technical background perceives an error in an app that makes an interface available to its user, let’s say in a mobile app, and blames the creator of that app for this error.
We, however, know that what the user sees comprises of many layers of infrastructure developed by several teams. The database team made a change to a table and models don’t map?
The API team made a change to the registration process? The network team replaced certificates?If the remaining teams haven’t had a chance to react to such a change, the client will learn about it through an error in their mobile app.
So, if you are a member of a team closest to the client, you can do your job in a way that protects your professional reputation. It’s widely known that we write tests. A coverage test is often required to get access to the code repository. However, the tests that will be especially helpful in scouting changes within the infrastructure that are beyond our control are the integration tests, which are performed to identify errors in communication between components and interfaces.
Testing the integrating layer before any of the infrastructure components is changed will prevent anyone one from putting a spoke in your wheel (at least, it won’t be easy). If you plug your tests into a well-configured Continuous Integration/Continuous Delivery process, you will be able to relax.
3. Code repository will tell you what you need to know
It seems that we, the technical people, love searching for someone to blame: have you seen that silly mistake in the code? Blame! And you instantly identify the last person to modify the code line, you instantly know who to make fun of …
Unfortunately, even GIT, most popular nowadays, can play a trick on an unexperienced used. The history of persons making changes to GIT may be easily overwritten by your name. I
don’t intend to give a lecture on operating GIT here, but if you happen to be working with GIT, pay attention to the good practice of using the rebase command, in particular in situations when there is more than one person working on a single base branch.
Maintaining the correct GIT history is quite a common issue and you can easily google that to find out more details. I strongly recommend becoming familiar with the topic, because why should anyone make fun of you when it’s not your fault.
4. Code Review
It seems only natural that any code implemented in your production should be reviewed and approved by another team member – authorised to do so.
In the context of defending yourself against allegations, this may not be the most friendly thing – putting the blame on the person who approved the Pull Request, but the mere fact that we have ensured that the PR is reviewed will result in a decrease in the chances we make a mistake.
5. Test yourself
Software development teams usually include a dedicated tester. However, it doesn’t excuse us from thinking of the code as a working functionality which doesn’t affect negatively two others.
Apart from checking manually whether the code works properly, it is worth employing automated methods by implementing unit tests and, in particular, proven practices of Test Driven Development (TDD) to test implementations, or Behaviour-Driven Development (BDD) to test entire functionalities.
You are capable of taking care of all these elements yourself. Making these a daily routine will increase your efficiency as a programmer – both within the context of team work and within the context of improving your skills and, as a result, of your financial success, for which I hope as much as you do.
