Programmer's Life: Are Tiny Changes the Worst?

Every programmer has experienced at least once in their life that moment of pleasure when the code is finished; some huge chunk, a complete service, or even the whole project. It’s that blissful moment when everything is perfect. The system is working, everything is in its place, and what’s more important the code is clean. Then – dun, dun, dun! The client comes with a “tiny change”. And the horror film starts.

To be fair, normally, if the change is really tiny (or at least small), it is possible to implement it without messing up the code, or breaking down the parts that are already in place. The only problem is that most clients have no idea what constitutes a “tiny” change. There is a minority of clients who are prepared to find a compromise on how to implement what they need without too much change or impact (and yes, these clients really exist and are not only a part of myths circulated among programmers).

Then there is the majority of clients: those who want a change, but use the word ‘tiny’ to get it faster or cheaper. The best representative of this category for me is a client who requested a system for their school. The school contained “branches” which had teachers, schedules, and students. While the branch was responsible for lessons, the school was responsible for billing and contracting. Halfway through the creation of the system, the client came with a “tiny change” to switch responsibilities: branches would do their own billing, but teachers could teach in any branch. This change was necessary, and it caused a lot of troubles. As a bonus, it had to be done so fast that it messed up the code.

Of course, we can’t predict what type of client comes to us. Not even analysis and conversations can stop changes in the middle of the process when the client sees or starts to use the product. Even in companies such as Pixel Federation which deal with game creation, it’s no bed of roses. Though we don’t have clients in the traditional sense, we need to be agile and react promptly and efficiently to players’ feedback. Game designers have a much clearer idea of what they want than most clients, and they sure know how to word it, but even they can’t predict the impact the feature will have. It’s great to work with them, but “tiny” changes still happen.

So how to deal with these requests which come either from clients or from game designers? Well, saying “no” isn’t an option, and it sure shouldn’t be the number one response. The only thing that can scratch the idea is the excessive finances or time needed for implementation. Praying for clients who don’t want “tiny changes” is also an option, but this one most likely won’t work. But don’t panic. All you need to do is to find a working solution in these situations that will make the client happy and will keep the code clean. Simple, right?

Right! The number one thing to keep in mind is the code. Make sure it’s always clear and well documented (the documentation doesn’t have to be outside the code). If the code contains hacks or shortcuts, changes may become more difficult or dangerous to implement, so try to avoid them. (Or at least make sure they are easily removed from the code when no longer necessary). Also, any change that comes should be integrated properly and as clearly as possible. This allows programmers to add features in the future and to debug the code in case of any problem. Spending a little more time on thinking the change through, brainstorming with other programmers, and creating checks and tests to make sure no existing code is ruined may seem like an extra work not worth the time and effort, but it couldn’t be further from the truth. True, with only one change, it may seem like overkill, but in reality, no production comes with only one change.

If you make sure that your changes are not ‘hacks’ of the existing code and that you created tests to control the development, you will create a code that you can control and improve. Those “tiny” changes are part of the development, so don’t fight them. Just remember that any change that comes has to be implemented under specific rules. Set those rules and keep them. Then the “tiny change” will be just a phrase with no special meaning; and the horror film will be only in your television and never in your life.