Tech debt: Flaky Tests and How to fix it

 Are getting Flaky test on your nerves? Here is how you can fix them easily.

 

Here, How to handle flaky tests. Start on top of the list and go down until the problem is fixed. 

1. If it's easy, then fix them.
2. Complain about it. 
3. Disable flaky tests.
4. Delete flaky tests.

Sound easy, yes it is. Now let me explain it.

1. If it's easy, then fix them. But is is in 99.9999% of the cases I seen, it not easy. So you have to try the next idea.
2. Complain about it. This is an underrated or over seen solution. If you complain about a flaky test you trigger maybe an other developer who knows an easy solution. 
3. Disable flaky tests. A flaky test doesn't secure any code behavior, because it's flaky. But it desensitise you, see image above. And a flaky test cost you development time, rerunning the tests. So there are only benefits in disabling them.  
4. Delete flaky tests. If you are ready to disable the flaky tests, you can delete them, because it's dead code. An additional benefit of deleting it, it makes it easier to refactor your code.

 If you you have any comments or other ideas, leave a comment below.

 

Code Quality 2024 Part 4: Collaboration and Software Development

 

Why collaboration influences software quality? This is a very simple answer. If you have a bazaar of ideas or solutions you can select the best idea. Or to describe it a little bit more mathematically, if you know at least two solutions from N and selecting the best of the two, you have guarantee that you solution is not the worst. Software development is not a game of perfect, it’s more important not to pick the worst solution. And if you put some statistics in it, you have two random solutions, then you can imagine the benefit of collaboration.

Collaboration in the Real World

Collaboration in the Real World doesn’t exists, mostly. But try it, try pair programming, learn how to do pair programming. It takes a really long time to establish pair programming. Don’t give up.

Code Quality Part 3: Use Test Driven Developmen (TDD)

First, TDD is not about having unit tests. TDD is a about software design and about specifying software requirements. Using TDD will improve your coding and the product.

TDD and Legacy Code

TDD and legacy Code is a combination from hell. Use TDD for new code parts. TDD will punctual improve the software quality. Don’t try to TTD-ing the complete legacy code, this is an idea from hell, you will get mad. Containment is the better option for legacy code. Build some tests around your legacy code, that covers and describes the most important code flows.

OK some words why I’m a big TDD fan.

- TDD saves time by reducing the time finding bugs in your implementation and believe me your code and my code containing bugs at least in the early iterations. A debugger is common tool for most developers, I don’t need it. I take the debugger only if I handle legacy code. TDD is an inverse debugger.

- It makes refactoring save and enables iterative software development

- It’s a driver for decomposition and the separation of concerns

- You don’t have to write extra tests, only few integration tests

I never seen TDD in real life. That means most developers are not using TDD.

There is on major disadvantage of TDD, it is not common. Every developer heard about TDD but that’s all.

What are barriers of using TDD, as far as I know

- Never tried it

- Stereotypes like: time expensive

- Routine

- No need

How to break down the barriers

- Try it.

- Pair programming

TDD and Test Coverage

Drop Test Coverage Metrics, they are useless. Test Coverage Metrics are to avoid, they costs productivity.

A major misunderstanding is the believe that a high test coverage is a software quality criteria. That is false. But what is true a TDD project have a high quality and have a high test coverage. Don’t mix-up causality and correlation.

Last Words

TDD is a blend of test first, decomposition pattern and iterative software development. Try it.

Code Quality Part 2: Cut down the Muda

 

 So what to next, next step is to create time to build software. What, are you thinking, what are we doing the whole workday? Most teams have a feature output close to zero. Mostly the whole time is consumed by fixing things, meetings or wastings. IMHO Muda in Software development means wasting time. So we have to fight the Muda to get development time. I’m not sure if all of these thing are Muda or other kinds of wastefulness. But here my top list where you surely find inspiration for your Muda cuts. There is no special order on the items.

    • Strictly Timebox meetings, every participant would be thankful
    • Put small breaks into meetings, eg. after 1 hour
    • No back to back meeting. Put some spare time like 10 min meetings. This keeps you fresh. You have time to stand-up and walk, take a coffee. This is not a overflow time box.
    • Strictly Timebox meetings, every participant would be thankful
    • Put small breaks into meetings, eg. after 1 hour
    • No back to back meeting. Put some spare time like 10 min meetings. This keeps you fresh. You have time to stand-up and walk, take a coffee. This is not a overflow time box.
 

1. Participate only to meetings that are really relevant to your work.
2. Keep the circle of meeting participants as close as possible.
3. Meetings are the punishment for not collaboration.
4. Accelerate development
5. Improve technical processes 
1. Automate manual steps 
2. Remove dead code and tests
3. Remove dead dependencies
4. reduce compile time
5. reduce test time
6. fail faster, try to move tests down in testing pyramid
7. Faster Hardware and better OS

Is tech debt a kind of Muda? Is tech debt a time eater? The answer is yes, it is. Tech debt generates bugs, because of the tech debt these bugs are fixed with quick and dirty fixes, this increases the tech debt and the code complexity which leads us to more tech debt and the tech debt cycle begins. Breaking the cycle is hard and painful and not a one point task. 

Tech debt wipes out development time in the future. Tech debt is Muda. The benefit of braking the tech debt-bug-cycle is less bugs in the future and a software that is easier (faster) to modify.
 

Code Quality 2024: Part 1 - Trust: Your are working in a Vacuum.

I struggle writing this part because it sounds like normal bullshit management blah blah. But here it goes to the fundamental of code quality: trust.

First you have to understand code quality can’t be added to a product like the cream on a cupcake. You can’t take a Volkswagen and put some quality on it and then it’s a Mercedes. No, quality or code quality is a intrinsic property. A good negative example of this idea of adding quality later on software are the often misused code metrics especially test coverage. High quality software have a high code coverage but increasing the code coverage later doesn’t make your software high quality. It’s the opposite, adding test later to increase the code coverage makes your code worse by adding complex test that will hinder you in further development steps. So you can’t add quality after development. 

So let’s do it right and start with first a simple step, building trust. Yes, it looks like a big step back from quality and test coverage. But first things first. Trust, without trust you can’t collaborate, cooperate or communicate. Later you will see that collaboration is next step on your way to code quality.

As software developer you are not working in a vacuum. Your are embedded in world full of other developers, admins, product owners, managers (however there are called now). And every of this guys has an impact on the product and therefore on the quality of the product. So how to build trust? It’s a good starting point to show your value and knowledge. Talking and listening is the second point to build trust. Developers often have difficulties to social interactions but you have to talk. I prefer face 2 face communication but it also works remotely. Try to create periodical talk rounds without managers, where all devs can talk without feeling to be observed. Open communication establish trust. And last point, you have to maintain this trust level, it’s a ongoing task.

Don’t forget building trust to the management. It has the same importance like building trust in the team. Talking is king again. And you can try to offer flexibility (in the agile meaning) to the management. The communication to the management should also be open and clear.

Talk not only about tasks or problems, talk also about your successes and goals you reached as a team. Only talking about the next big problem moves the focus of team and every thing feels hard and complicated. You have to avoid that.

Last remark to dysfunctional companies, there is no real chance to establish trust. The company is broken and can’t be rehabilitate, the products will also go broken. It’s only a matter of time. Only adviser from my side, if you realize that your are in a dysfunctional company, leave, leave as fast as you can.

What is "Chore at Last"?

 Chore at Last is a little bit like tidy first but what with different approach. Chore at Last means, before you create a PR or go live with a new feature you chore your code. The idea is to improve the code around the new feature or bug fix to prevent it from going tech debt. This step also includes the usage of common code analyzer tools like PMD or Sonar.

OK, a real world example. I just update a lib to the latest version. The new lib version was improved and has a little bit changes interface. The quest was to update to latest lib version. At this point I could stop and "solve" the JIRA ticket. But I realize that a service class that hides the lib, was not needed anymore. My chore last action was to remove this needless class. It reduces the code complexity and prevent tech debt.

Or you can compare with a craftsman who is cleaning up the work desk and store all there tools. It's not part of the product but still needed.

Do you think this would be banal, I know it isn't.

Code Quality 2024 : Introduction by Mirko Ebert

Code Quality – Quality Code is highly discussed, every company wants it, many developers have a huge amount of tips, tools, frameworks or new language that guaranteed quality software. If you want to dive in this deep sea you never will find it. I also started to write a nice blog article that describes my point of view to code quality. The article was almost done. But the I realize, at the end all these things are useless if you don’t know how to reach this quality code goal. Knowing the details is not sufficient.

 

So I decide it to describe and teach you code quality like the Golf Sidekick teach me to break 100 or how Ben Hogan teach me the golf swing with his book: “Ben Hogan's Five Lessons: The Modern Fundamentals of Golf”. 

In the following chapters I will describe you a simple and proven way to ensure code quality. Every developer can follow the way of code quality. This way will work for everybody, for every development team and for every IT company.