7 Mistakes Java Developers Make that Prevent to Refactor Bad Legacy Code

We all know that bad legacy code is a big problem. If we change any part of the code, everything can stop working. It’s a nightmare to maintain a software in this situation. Any simple bug turns into a big monster. Instead of trying to mend the code, refactor it!

But what are the mistakes we make to not refactor the code?

1 – Focus on Short Deadlines

In many companies, time is very short. We just spend a lot of time fixing the bugs, we test it, it works. Until then it’s ok, but most times another part of the application just breaks. Simply because the code is too coupled. If we fall in the illusion of correcting those bugs all the time because we don’t have time the consequence is that more bugs will appear.

2 – Focus on Numbers

Numbers, numbers, and numbers. We software developers have to take action to avoid situations where we have to generate numbers. If we accept generating numbers we will become part of the problem.

Sometimes we are told to fix 10 bugs but we again would be entering in the infinite cycle.

Fix bugs -> Generate other bugs -> Fix bugs -> Generate more bugs -> ….

The problem has to be solved by the root cause. The code must be refactored!

3 – Fear of Breaking the Application

It’s very common and natural to be afraid of breaking an important part of the application. Refactoring a bad legacy code without automated tests is obviously a risk.
What do you want to do? Do you want to be in your comfort-zone facing the nightmare of maintaining bad code? Sometimes we have to take the responsibility if something happens and be able to take action to reduce risks. A very simple action would be to get the test team by your side, you can create a separated branch to work and then, make it happen. Take action and improve the quality of the environment you are working for.

4 – Lack Negotiation Skills

Some time ago I thought that any other skill not being technical was useless. I was completely wrong. How can we propose a good technology for the project if we are unable to negotiate? Soft Skills are extremely important and we need to master them if we really want to do an amazing work. We can contribute much more improving them.

5 – Fear of Losing the Job

It’s tough to take the hard path, but certainly, it makes a great difference in your career. We want to cut the bad from the root. Also, you can lose your job breaking some important part of the software. That’s why you’ve got to bring everyone on your side to work with you, convince them to take the risk with you. It’s always better to see a high-quality code easy to maintain.

6 – Lack of business knowledge

We must be always curious about the business of the application we work on. How can we be sure everything is working fine if we don’t know the business? It’s not possible to test the application without knowing the business. Find a way to know better the business if you don’t know it yet. If you don’t have enough business knowledge you can always have someone by your side that can support you with this.

7 – Not knowing the  Best Programming Practices

To refactor the code in the best way we must know the best programming techniques. Simple things make a big difference like organized packages, method and variable names.

Simple concepts as well:

DRY – Don’t repeat yourself
KIS – Keep it simple
Apply Design Patterns

Remember, develop your code as if there is a psychopath that knows where you live maintaining your code.

What pill do you want to take? The blue one and keep everything in “control” inside your comfort zone? Or you want to take the red where you will face tough challenges but will make the world better?

There is more! You can get this FREE E-Book too!
No Bugs, No Stress – Create a Life-Changing Software Without Destroying Your Life

Keep up improving yourself!

7 Mistakes Java Developers Make that Prevent to Refactor Bad Legacy Code

7 Steps to Convince Java Developers to Implement Better Code

When software developers don’t care about producing a good code all the environment tends to be impacted by the consequences. Bad code leads to a stressful environment full of bugs where you don’t have time for you and your family. That’s why we will explore the 7 steps to avoid this problem.

1 – Be a Reference

If you need your team to produce a high-quality code, you must be a reference. It doesn’t matter if you are not the team leader; we can take the lead of anything without a title for the greater benefit. Share your knowledge with the team you work with, show them new programming techniques. Motivate them to be thirsty for more knowledge so that they can study by themselves. If your team admires your work, certainly they will be more willing to be like you.

2 – Show them the wasted time to fix a simple bug

How much time have we spent trying to find/fix a bug when the code was really bad? Much time indeed, it may have lasted for one or two days or maybe one week? Yes, this is the impact of producing a bad code. How many times did we have to find out what was the meaning of a variable or method because of poor names that don’t mean anything? We have to be detectives sometimes to find out what is happening.

Show them a giant do it all method and make them realize how stressful is to fix a bug under those conditions. That’s why we have to know how to convince and influence the team to use the best programming practices. We must show them the price we pay when a bad code is produced.

3 – Don’t be arrogant

Many developers fall into this mistake of being arrogant. It’s very unlikely you will be able to influence people by being arrogant. People tend to be defensive when they are treated in a bad way and they won’t trust you or follow your leads. So, it’s simple, you must be the opposite, have the attitude of supporting your team without being too harsh. Show them the right path to follow.

4 – Show them how rewarding it is to write high-quality code

What if we had written bad code? Certainly, we would waste much time until we could understand what is happening.  It’s very rewarding when we see the code after some time and we are able to understand everything. If we put more effort when writing a code,  everyone wins. As we know, we spend 10 times as much time reading bad code than writing a high-quality code one.

5 – Use a quality-code tool

Tools like PMD/Checkstyle and Sonar don’t solve the problem entirely but certainly help. They prevent very ugly things in the code such as very long methods, huge classes, unused variables, and nested loopings. Just remember that you must configure these tools in the right way, or else you will be correcting everything in the code and it will be really annoying.

6 – Implement Code Review Culture

This is crucial to improve the code-quality from your team. Every time someone finishes their tasks the Code Review must be executed. You must make other members of your team learn the best programming practices so they can work on their own.

7 – Implement Knowledge Transfer Culture

Certainly, the culture of sharing knowledge in your team is extremely powerful. You will be improving your speaking skills and will be learning new content that is crucial for your daily work. You can prepare Knowledge Transfer about best programming practices techniques, frameworks, tests, whatever you find your team needs most.

There is more! You can get this FREE E-Book too!
No Bugs, No Stress – Create a Life-Changing Software Without Destroying Your Life

Keep up improving yourself!

7 Steps to Convince Java Developers to Implement Better Code

5 Tips to Avoid Short Deadlines and Prevent Bugs

1 – Learn how to say no

What developer has never worked with short deadlines?

I believe most of us have already had this experience and, as you know, it’s extremely stressful!

Sometimes managers want to show numbers instead of quality.

So what do we have to do? We have to say no! We can’t accept short deadlines.

Provide clear reasons against short deadlinesunnecessary stress, poor quality, and an increase of bugs!

In the end, shorter deadlines can result in greater expenses for the company including overtime for developers and loss of credibility with clients.

If you don’t say no to short deadlines:

Master Yoda would say:

Your project, in chaos, will be.  Multiply, bugs will.

2 – Break up your task into sub-tasks

If your task seems too broad, you have to break it up!

It is impossible to know how much time you will take to deliver a task if you don’t know exactly what it is.

If you don’t know the business rules, the database model, or the technology you will use, for sure you will take more time just to understand what you have to do.

Remember, even breaking up the tasks will take time.

3 – Use a development methodology (SCRUM, XP, LEAN, KANBAN, etc)

Yes, use a development methodology. Using a methodology is much better than not.

There are a lot of very good methodologies like SCRUM, Extreme Programming, Lean and Kanban. You can mix and match parts of different methodologies and adapt them to your project.

For example, you can use SCRUM with KANBAN and use pair programming from the Extreme Programming methodology.

Pair programming is very useful. It can balance the team experience and developers can learn from each other. For complex tasks, it’s extremely useful. If you have never tried, when you do, you will think the same!

It’s easier to control software development with a methodology.

You can define how much you can deliver on your “sprint”. Most times the sprint lasts 2 weeks.

4 – Use complex points! (Define the complexity of your task)

At first break up all of your tasks so your team is capable of understanding what must be done.

Once you have organized your tasks, you will assign a point to each task.

On SCRUM methodology, we use Fibonacci numbers, 1, 2, 3, 5, 8, 13,

21, 34, 55…

These numbers are very subjective. You can define your own pattern, but typically, it is like this:

  • 1 to 2       – Easy
  • 3 to 8       – Medium
  • 13 to …    – Hard

 You must consider everything when you are defining complex points –

business rules, database model and technology.

 5 – Be persuasive and convince everyone that you won’t have enough time to deliver the product

Do you think you have to be just a technical person? No! It’s one of our mistakes. We must develop other skills too! How can you convince your manager or your client if you don’t practice persuasion skills? Learn how to negotiate and save your project!

Books to read for learning how to be persuasive:

  • Getting More, How You Can Negotiate to Succeed in Work and Life, Stuart Diamond
  • Crucial Conversations, Tools for Talking When Stakes Are High Kerry Patterson, Joseph Grenny, Ron McMillan, and Al Switzler
  • Influence, The Psychology of Persuasion, Robert B. Cialdini

If you don’t have enough time to read the books, just think about how a short deadline can damage the project and explain it. Make them understand they are making a mistake!

5 Tips to Avoid Short Deadlines and Prevent Bugs

5 Situations Developers Go Through That Cause a Lot of Stress

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 the 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 a high quality software everyone wins.

2 – Extremely generic architecture

Your code can get very confusing if you design it by thinking about all the possibilities and build, for example, your logic model to fit all of them. Don’t design this kind of model, instead, design the solution thinking about your needs.

You can also develop your model thinking about the future, but don’t exaggerate on your decision by making your architecture too generic and unnecessarily complex.

3 – 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 extremely 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 NoBugsProject 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 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!

4 – Bad code design

We’ve all seen bad code – poorly designed classes, badly implemented architecture and substandard programming techniques.

Consider doing a more deep refactoring for changing the bad code design. Most of the times this code becomes a monster very difficult to understand if we don’t do this.

To avoid it, always write high quality code using the programming techniques you will be receiving here. Think very carefully about your code design!

5 – Fixing bad code

Most developers fix bad code in a way that solves the immediate problem, but doesn’t take into account 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 method

low coupling, separate code by classes and methods

– use method refactoring shortcut on your IDE, select the code you think can be a method and let the IDE extract it for you

That were the 5 great problems you will face on your developer’s career, use the techniques you learned and become the developer every company want to have working!

Keep up the good work!

Follow me on Twitter to learn more great programming techniques. I will be sending a new one each week!

Get the free E-Book:

5 great programming techniques every developer should know

Remember, practicing these techniques will make you an even greater developer!

Share it!

5 Situations Developers Go Through That Cause a Lot of Stress

5 Indications That Your Project May Not Be Prioritizing Quality and What to Do About it

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!

5 Indications That Your Project May Not Be Prioritizing Quality and What to Do About it

5 Mistakes Developers Make That Causes Bugs Without Even Noticing

1 – Using business code in View layer

Well, as the name says, View layer is not used for coding business logic.

Your objective when using View layer is to implement what is necessary for user interaction. Whatever framework you are using, it’s possible to implement the MVC pattern. If you can use your View logic on your Controller layer, do it!

For example, if you are using JSP, implement the logic of your View on your Servlet.

Don’t fill up your JSP with ifs or any other code. It’s better to use Taglibs instead.

2 – Using business rules in Controller layer

The Controller layer needs to be used as a connection between the View and Model layers. If you have business code in your Controller layer, check it again, and move it to the Model layer.

The Controller layer also can be used to implement the View code.

For example, if you need to load a Combobox after an action or add some format rules in your ‘inputText’ components.

You have to think, does this rule only apply to the View layer? If your answer is yes, then you should use this logic in your Controller. It does not make sense to move code that is only related to the View layer to the Model layer. The best thing you can do is to encapsulate View logic in the Controller layer.

3 – Using a lot of different architectural patterns in your project

Define a pattern to be followed in your project.

If you are using Java EE, it’s a good idea to follow an architectural pattern so that developers will more easily understand what is happening in the code.


  • (View) XHTML
  • (Controller) Managed Bean
  • (Model) Façade – (Business) EJB

4 – Creating a lot of unnecessary layers in your project

If you perceive there is a layer just invoking another layer, something is wrong.

Most times it does not make sense.

For example, you can be using the DAO (Data Access Object) layer for nothing!

If you are invoking a lot of layers in one line, all this code is unnecessary. You can remove the DAO (Data Access Object) layer and do your query in your “Service”. But remember, use your SQL code in a separate XML file.

5 – Showing code log everywhere

Hey! It’s not necessary to show code log everywhere in your application. You can just throw your Exception to the View layer and show the error in a Dialog. Remember, use words that make sense to the user!

Use your log ONLY where you catch your Exception. You will have the stackTrace, so why show log in every throw statement?

If you really need to know everything that is happening in your project, use AOP (Aspect Oriented Programming)! Don’t repeat code for logging all your system! Imagine all the trouble you will be in if you need to change your log!

There is more! You can get this FREE E-Book too!
No Bugs, No Stress – Create a Life-Changing Software Without Destroying Your Life

Keep up improving yourself!

5 Mistakes Developers Make That Causes Bugs Without Even Noticing