In the past year 2013, I made several proposals to improve software development in my project. Some of them got implemented, like having agile meetings with the customer. Others got refused several times, like setting up a serious fundament for JUnit-tests, only to finally got the attention they deserve. Often I, as a developer, wanted to implement best practices of software development and the customer wanted to postpone these to implement more functions and to accelerate releases. This article is about this old “battle in the trenches” game during daily software development and how I dealt with it in 2013.

Although I often hear the analogy of the “battle in the trenches” for software development (and I choose this as the picture for this article), I find this image not accurate for my, if not for the most of situations. My customer and I are talking to each other instead of fighting and there is great dynamic between the “fronts”. The customer compromises, and I compromise. If it would be too much like the historic trench warfare, I wouldn’t work there. However, it’s a known meme.

It can be quite painful to see the own proposals dismissed in favor for “just another new function” and of course this function had to be there yesterday! As I mentioned, this happened quite some time this year. My problems with that were:

1. It is frustrating to repeatedly tell the same thing.
2. My name is linked with the source code I write. Decisions made today are influenced by economic and political factors. This is not reflected in source code. In a couple of years all that is left from the struggles today is bad source code with my name under it.
3. Not following best practices of today’s software development process means technical debt which means more work for me later on, which I want to avoid.

I asked myself: How do I deal with the gap between the urge to write great software and the desire of the paying customer for more functions?

This is what I and a handful of people I talked to came up with:

1. Solution for the Frustration of Telling the Same Things Over and Over Again

That seems to be part of working for a customer in time and material mode. Often, the customer is driven by current needs and wants his functionality quick. The software supports the main resource of the customer (like a production process or the management of things), but it itself is not the main resource. In contrast, a company that sells software products has a naturally higher interest in a sustainable software that can be developed further because this software is the product that gets selled. Hence, I simply have to deal with repeating myself when working for a customer on a time and material basis.

2. solution for Bad Karma Doing Bad Development

I always try to implement the most elegant solution I can come up with in the most state of the art way. If I cannot do this, I write a bullet-proof documentation of my suggestions to avoid getting a negative reputation and in guarding against later accusations. I do this in the following way:

1. I write concepts that illustrate and prepare my suggestions. Thereby, I illustrate the consequences that could occure when the change doesn’t get implemented.
2. I make these concepts persistent by commiting them in the document management system of the customer and keep a copy for myself.
3. I reference to these concepts in protocols of meetings and in the source code. The later is important to avoid becoming “that guy who mucked up the code for no reason”.

3. Solution For Technical Debt Buildup

I think a developer has a certain responsibility and should have a personal agenda what he can account for and what not. I imagine a certain professional honor that every serious developer should follow. If things get really rough it is better to leave the field without making a bad impact. Luckily, I’m far from that at the moment. But it is good to know what to do, if times change.