1 – Not worrying about production errors
Some developers implement solutions thinking only about now, sometimes using the same code repeatedly. Then when it’s necessary to change the code, it has to be changed in multiple places in the system. This error is often erroneously justified by short deadlines and high stress levels.
We developers MUST know how to say NO for insane deadlines. We are the professionals that know if we can deliver or not.
It’s very probable that production errors can occur if we don’t test our new features or don’t know business rules as we should.
2 – Not taking responsibility for errors that customers see
TDD (Test Driven Development) is a great technique that can avoid a lot of problems.
When testing we must use baby steps and ensure we create simple tests to make sure the implementation is working properly. The best thing with TDD is that our code is created having already been tested.
The chances of getting a bug are reduced, but it’s important to remember that tests don’t guarantee zero bugs. We must know the system as a whole. We must know the business rules clearly.
3 – Not thinking about reusing code
OO (Object Orientated) paradigm is difficult to master. Dedication and hard work are necessary.
Some developers just don’t care about improving their programing skills. They only care about delivering a working feature because they think this is what really matters.
Most of the time managers don’t really care about quality code. They only care about getting the software working and don’t think about the possibility of implementing a new feature or changing the software.
This problem can be solved with the culture of code review. In this way, developers can help each other by sharing programming techniques that will help them develop better code.
4 – Not thinking about changing features (Software always changes)
When managers negotiate short deadlines with their clients, it’s a huge problem because the work falls to the developers.
What happens with short deadlines? Most of the time we have to work many hours of overtime and unfortunately it’s very difficult to implement the code with enough quality. Thinking just about solving the problem would be the most common action of the developer.
When the problem is in the root process of the company, it’s our role to negotiate and convince our managers that we need more time to develop the project in order to have better results.
Just create a presentation and show managers the numbers – the amount of bugs, the wasted time – and how difficult it is to change a feature in a system written in a hurry.
5 – Not knowing the business rules well enough
We developers sometimes underestimate the complexity of business rules.
We think they are easy because they are not code, but we can have real trouble if we think like this.
If we don’t know the business rules clearly we won’t know how to implement the solution effectively.
Some measures can be implemented for this problem. A very effective way to solve this problem is to write the main business rules in a Wiki (central website of the company where you work) and share it with all developers. The business rules will be centralized and it will be very easy to understand them.
Having weekly or periodic meetings (Knowledge Transfer) to talk about the business rules is a great way to minimize this problem.
Until new developers realize that fully understanding business rules takes a lot of time, we can use these measures to make this easier for us!
Keep up the good work!
Follow me on Twitter to learn more great programming techniques. I will be sending a new one each week!
Download the free E-Book:
5 great programming techniques every developer should know
Share it!
