Bugs are clearly one the most stressful problems that developers face every day
Companies spend a huge amount of money to maintain software full of bugs, the time spent to create new code is nothing compared to maintaining it.
Let’s explore the top 14 mistakes so you can avoid bugs and stress.
14 – Not giving enough importance to Code Structure
A bad code structure is another core problem that may cause a negative impact on the code. When a bad code structure is defined, it’s very likely that every developer will follow it. Then when the project gets bigger, refactoring becomes really difficult.
It’s a good idea to give high importance to the code structure because it will save a LOT of time in the long run.
Here are some reasons to do so:
- Developers will implement less code
- The code will be much simpler to understand
- Developers will be able to focus mostly on the business problems
- The code will be reliable
- Less experienced developers will develop better code
- It will be far easier to track down bugs
13 – Defining a very generic Database Model
With badly modeled database queries get difficult to implement and it’s also reflected in the code, entities will have lots of relationships and what should be simple becomes very complex to solve. There may be lots of joins on queries and when a new feature has to be implemented based on the database model it is a nightmare to adapt new tables to the current model. It’s crucial to balance what you really need in your database model because if you create it in the most generic way, you might create a very high complexity that might never be used in the project.
In order to avoid those problems, it’s necessary to understand the business rules very clearly and then do your best to create the database model in a way that is flexible, normalized, and the simplest that meets the solution for the business.
It’s definitely not an easy task to create the database model but it’s crucial to give it a very high importance because it will have a huge impact in software development.
12 – Giving Bad Names in the Code
The main problem with code naming is that even the creator of the code has no idea about what is the purpose of the code anymore. It will be necessary to dig deep and deduce the find out what is going on in the code and bugs will hide very easily. Hours, days, or weeks have to be spent to solve a single bug. Debugging will be your best friend in those times of despair. The code that was written to the machine will be very hard to maintain.
When abbreviating names for example there is no way to find out what the code means.
Names like:
CstmrPrtyPrdt, ClntLvlItm, GrpHrchyMst, Dermst
Do you want to risk yourself trying to guess what are those names?
What about mono-word names?
Variables named as a, b, c, x, y, z, magic numbers spread in the code. Can you guess what the variable means? I am sure no one knows that.
It’s not easy to give a clear and meaningful name to your code, developers have to do this as they give their firstborn child a name. It’s hard to name the code in the best way, it requires thinking about the code structure, classes, packages, methods, and variables. The code must be cohesive to code naming work greatly.
Do it always so with time and practice it will become easier. It’s very rewarding to see the code written in a clear and meaningful way. It’s amazing to see the code we produced after a long time and be able to fully understand it.
If you want to go deeper on coding naming, you can check out the article Improving Code Naming to Easily Kill Bugs.
11 – Not knowing Soft Skills
Do you think you have to be just a technical person? No! I’ve made this mistake for a long time and I had no idea why I wasn’t advancing in my career. We certainly must develop Soft Skills too!
There are many Soft Skills that will massively help you to create high-quality software, such as knowing how to work in a team, communicate effectively, mentoring, coming up with innovative ideas, ability to solve problems effectively, and sharing your knowledge with your co-workers.
Persuasion and negotiation skills will also be crucial to your career. You will need to convince your manager/client when you realize that you will have to sacrifice quality to deliver illusionary numbers.
Books to read for learning how to be persuasive:
Getting More, How You Can Negotiate to Succeed in Work and Life, Stuart Diamond
Influence, The Psychology of Persuasion, Robert B. Cialdini
Think about how a short deadline can damage the project and explain it. Make them understand they are making a mistake!
If you wish to go deeper into Soft Skills I highly recommend you to check John Sonmez’s videos and his Soft Skills book.
10 – Culture and processes problems
If you are not using good tools to develop software in your job, you must take action and change the culture. It’s tough to change the culture but it’s possible, guess what Soft Skill you will need? Negotiation and persuasion skills here.
Show everyone the benefits of using the tool you are proposing. People are naturally against change, you must be very good when showing your arguments. You can even use numbers, to show the profit when using the new tools.
It may be anything, DevOps, new code frameworks, methodologies such as Scrum, a code review tool, and new version control software.
Powerful tools such as Jenkins make a big difference if you can convince everyone to use you will be adding a lot of value to the project.
In order to handle cultural problems patience is required, it will take time until things change and get on track. Don’t expect to see culture changes instantly, instead do what you can do to change it bit by bit and when you less expect, developers will be doing their very best and the project will get to the next level.
Another key aspect here is persistence, sometimes it seems that your actions are not effective but keep in mind that the actions you take daily make a great difference in the long run. Those actions will take stunning results. Just keep on doing your best.
9 – Not refactoring code because there is no ‘time’
The illusion of numbers will always exist in companies if we don’t do our job to convince managers/clients that generating numbers is a big mistake, they will continue thinking that delivering it in any way will be the best for the project. If we developers allow this to happen, for sure everyone will pay the price. A new code will be tough to implement and bugs will hide very easily. Good developers won’t be willing to participate in the project anymore and the code will be tending to rot.
As a result, the company will spend LOADS of money to maintain this software because of such an unnecessary complexity. Sometimes it’s really tough to convince our stakeholders that this is the right path to follow to avoid a project failure but we must keep on saying and trying our very best to make the best for the project.
When there is a bad legacy code, things get tougher. Probably there will be no tests and nothing we can rely on. But fortunately, a friend of mine Scott Wierschem is a specialist in refactoring bad legacy code. If you are having problems with this, contact him at Keep Calm and Refactor.
8 – Allowing wrong decisions to be made
Sometimes we listen to the wrong ideas and don’t speak up to make it different because of insecurity or fear of being rejected or whatever reason.
The thing is, if we keep our mouth shut when seeing a wrong decision being made, everyone will feel the consequences, the project will lose money, developers will be stressed, and a complete mess may happen. The project may even go to failure if you don’t take action.
Remember, you don’t need a title to be a leader, you just have to speak up and be persuasive. To be persuasive you must express your ideas in a clear way.
Avoid discussions that lead you to nothing, and don’t try to argue against the bad idea you are listening to. Instead, when you realize that some idea might be wrong, ask “why” this person wants to follow this strategy, when you do this, you force the person to think and explain why it will be good for the project and if you ask deep enough the person will simply realize that the idea might go wrong because you forced the person go through the subject and then it’s your chance to propose something you think it will bring a great value to the project.
7 – Fixing a Bug with a Golden Hammer
Some developers fix bad code in a way that solves the immediate problem but doesn’t take into account code legibility.
This method can be problematic because the bad code still exists and can reappear elsewhere.
To avoid this, rewrite the code with the goals of:
– more cohesion, just one responsibility by a method
– low coupling, separate code by classes and methods
I believe all of us developers went into trouble when we needed to test a method that does absolutely everything, we can call those methods Mister know it All methods. All you can possibly imagine is there. Now imagine creating Unit Tests for this kind of method. How many flows would we have to predict? And worse, any line of code changed in the method and all the tests would have to be changed. Let’s avoid Mister Know it All methods.
Use the method refactoring shortcut on your IDE, select the code you think can be a method, and let the IDE extract it for you.
6 – Not implementing DevOps culture in the project
Nowadays it’s known that DevOps is crucial for having better control of the software. Software without continuous integration is difficult to predict and very serious problems may occur when deploying the software. Bugs may start to pop up in production with the customer using the system. No company wants that for their products and developers even less. When a problem occurs, the manager or the client “throws” an “Exception”, then guess where the problem goes? Of course, it’s to developers, we always catch Exceptions like “DevelopersFaultException”. In the end, we know that everyone that is involved in the project has the responsibility for decisions, we must do our part, and if there is something we can improve we must speak up and convince stakeholders to use continuous integration for example.
The advantages of implementing DevOps culture are great, manual deploys will simply not exist anymore, tests will be executed before each deployment, and fast feedback when there are broken tests or code that don’t compile. Deploying to different environments such as test, Dev, Homologation, and Production becomes very easy because they will be all automatic.
If you want to know more about software automation, I would highly recommend the blog of my friend Rodrigo Moutinho, CyborgDeveloper. He is a Software Automation specialist and he will help you to solve your problems regarding it.
5 – Lack of tests
A code without tests is not reliable and keeps developers afraid of touching the code. Refactoring becomes much more difficult because the code is very sensitive, any change and developers won’t know if the feature is still working. Chances of finding a bad code on a project that lacks tests are much higher because ultra-responsible methods don’t have to be tested.
When there is enough testing in the project, the code becomes more reliable, and refactoring is much easier because after you make your change you can simply execute tests to check if something was broken. Automatically, the code becomes simpler and more specific because developers know that the implemented code has to be tested.
Tests are very handy to track bugs down too when there is a problem in a business Service and you know there are tests, it’s much quicker to fix it.
Consider implementing integration tests as well, Unit Tests can’t make sure that the integration with the database is working. Integration tests are not supposed to test every specific scenario, instead, it is mainly to reassure that the basic flows are working fine with the database.
A great advantage of integration tests is that when there is a bug in your Service that is related to the database, it’s much quicker to find the problem and execute your Service. If there are no Integration Tests, developers would have to run the system, go to the screen, put data again and again, and repeat many steps until the real problem is found.
When there are automated tests, you can easily find out if there is a bug in the software, it’s faster, reliable, and brings more quality to the project.
4 – Not knowing business rules well enough
Developers sometimes underestimate the complexity of business rules. 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 handle it 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.
When we know the project as a whole, we can suggest better features and we can design the software in a more effective way.
3 – Not thinking about reusing code
The OO (Object Oriented) paradigm is difficult to master. Dedication and hard work are necessary.
Some developers just don’t care about improving their programming 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. It’s a big mistake because the company will pay a really high price to maintain the software and no developer will be willing to maintain the code.
This problem can be diminished 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.
2– Lack of knowledge
Developers write bad code when they don’t know the basics, for example, of the framework’s API and the chances for developing bad code are high. You don’t have to be a ninja programmer, but you DO have to know what tools you have available. You can avoid this issue by studying at least the basics to know what you can use to solve problems. Also, keep on reading the No Bugs No Stress book for more problem-solving tips.
If you know the basics, you will know there is something you can use for solving the problem and you will be able to search for what you need on Google.
For sure, if you master the language, the best programming techniques, and the framework you are using, your code will be better than if you just know the basics!
You can refine your Java skills in Oracle Dev Gym for example by solving Java puzzles, you will learn deep core concepts that will help you in your day-to-day work.
You can also follow the Java Challengers series on the Java World website.
1 – Short Deadlines
Short deadlines are an unfortunate reality of the IT world.
Do you know Steve Jobs‘ famous quote “customers don’t know what they want until we’ve shown them”?
Managers and clients often think they are doing their best by developing software very fast with unrealistic deadlines.
They think that developing software quickly is better than developing high-quality software. They don’t know how disastrous this can be.
If you ask a doctor to perform your heart surgery in 10 minutes, do you think she would do it? If she does it, she could kill you. The same situation happens with us developers.
Managers and clients often set unrealistic timelines for software development projects. Usually, this is motivated by the goal of a fast plan. Unfortunately, doing this often results in unnecessary stress for the developers and a fragile product that is full of bugs.
We MUST negotiate better with our managers and clients and show them that if we develop software with more quality, we won’t have bugs and maintenance will be easier. As commonly known, software changes all the time, so expansion will also be easier. If you didn’t already know, software maintenance is a company’s highest cost.
By creating high-quality software everyone wins.
