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.

Some thought about hiring in IT

1. Summary
   
2. Background
3. What's wrong with the current IT hiring
4. An idea to better IT hiring
5. Conclusions
    

Summary

The following article describe my current way to engage developers. It's proven over 15 years that it works. It's a fair, simple and efficent way to hire new software developers. 

 

Also I try to show why coding challenges are a bad idea for hiring.

Background

Thanks to Robert Niestrój to trigger me to finally write this article after so many years.

 

First, a few insights from me.

• I'm a big enthusiast of agile software development since many years. And I mean agile software development in the Agile Manifesto way and not in AGIL(TM) Way or how I call it WAT-JIRA aka Waterfall process with misused JIRA.
  
• I was hired
• positive: 11
• negative: 6
• I hiring
• positive: 6 (FTE) and many more students
• negative:8

But be careful with this data, the are only the cases I can remember. The real numbers may be higher. IMHO I have some experiences from both sides of the table. So let's start.

What is wrong with the current IT hiring

The code snippet is part from a coding challenges which are popular since some years. I can't remember when I first saw it.

 

Robert's question reflects a typical IT hiring process and show also why this way doesn't work. In my following words, I exclude all special things like hiring a 10X for Rocket Science or so, that's adifferent stotr. For now, I assume that you try to hire one new developer to get more development power or to replacing someone.

First an first most important, you are hiring people. Yes, yes I'm a agile software guy. Please read the first line of Agile Manifesto under the viewpoint of hiring. Before you process reading this, you should wait 5 minutes and think about it, you hiring people. Speak with them, ask them interesting things, not this standard phrases like weaknesses, strength, where do you see you in 5 years bullshit. These question does not work anymore. Predictable questions produces predictable answers with no information. Remember you try to hire a coder and not a manager. These kind of questions are a waste of time, for both sides.

 

All psychologiacal games cast a bad light on your company.

Coding Challenges missed the smart guys

Coding challenges are pointless waste of time. Imagine following scenario, I'm going to a job application in a IT company. On the other side of the table is a team lead or a software architect, god forbid, remember I'm a very experienced Java Native, my counterparts often stops developing 5+ years ago, so my challenge is to meet the lower technical level of my counterparts. An believe me, if I come with some latest edge case programming ideas, I will not get the job. People tend to engage people that are not smarter them them self (Well done ESA). Coding challenges are for me like rolling dices.

 

At this point if I should do a coding challenge, I will stand up and say polite "Thank you. My time is to valuable." and leave the building.

Coding Challenges missing the shooting star

Most coding challenges are overwhelming for newbies like graduates or career changers. They won't make it. You wasting potential.

Interpreting the coding challenge results

Let's go back to the coding challenge example. There is the Lombok data annotation. It's very popular because it make it run. On the other hand it adds some often not used code for equal and toString. This means you generated more code then needed and this maybe increase the properbility of side effects. One of these side effect could be that you log sensible data via toString. So how rate it in the coding challenge.

1. The data annotation is right because it make it run, it's only one annotation instead of two or three. In 95% of all cases is equal to high sophisticated multi annotation apprach. Form the development time perspective it's faster.
2. The seond mult annotation approach don't generate unused code. It makes it more side effect unlikly. But on the other hand in 95% of all cases it's waste of time because the outcome it the same.
   

So what is right, it's in the eye of the reviewer. Is one appraoch better then the other, it depends on the context of your application. It's not a developer skill. The developer skill is knowing the differences between booth solution. And by the way, there are many more soltions. Speak with the guy.

Should you hire the first or the second one. It doesn't matter. But anyway, you have to realize that you and all your developers learning new things. And if he doesn't know the difference makes him not a bad developer. Or how I call it, develop your developers, develop your team.

Some simple ideas to a better IT hiring or what works well

This is a fair, simple, working an very effective way to make a job interview. Only preconditions are a good kind of common sense and hot tea or coffee. Instruct all your interviewers how it works.

1. Interview format (2024): Only 1:1, simple talking, no tricks, no traps, no games, 10 to 30 minutes, two interviews with the candidate in a row, at least one with a team member. As preparation read the CV carefully, better more then one time and make some tea or coffee and bring some cookies and be on time.
   
2. Decision making: No discussions, every participant take a Postit and write secretly yes or no, a maybe is a no. Reveal. Hire the developer only if booth noted YES.

If you make a negative decision, tell the candidate, no delays needed. Do not justify your decision, no discussion, the result is final (like my method parameter). And if you decline him and you know a company that fits better to the candidate, give him a hint.

Conclusions

1. Always remember: You hire people. People are the real value of an IT company but can also the biggest risk. 
2. Hiring people is the biggest investment you make.
3. Try to hire smarter people. 
4. Treat applicants as human beings, be honest, do without psychological games.
5. Coding challenges are in most cases a pointless waste of time.
6. It's better to miss a good one then to hire the wrong one.
7. It's better to hire no-one then to hire the wrong one.
   
8. Have a good conversation with the applicant and use your common sense. Your common sense is a strong tool. Or how I say: "If it looks strange then it is strange".
   
9. Develop your developers
   
10. Company HR Departments are 95% use-less.
11. Recruiting agencies are a little better but expensive.

 

Dropping TDD, not - Part 1

 This article based on a Twitter discussion, this is Part one. An IT consultant came up with a slide of transformation, I guess. There are some interesting points on the slide and I don't know the real context but the first point was: dropping TDD. This triggers me and I jumped in a small conversation.

 

I like TDD, I use it for more the a decade. From my point of view TDD is a good practice in developing quality software, what ever quality this means.

So I was triggered and someone in the discussion send me a video link of Dave Thomas (https://youtu.be/a-BOSpxYJ9M?si=kcwuhVgyQoxmGLEL). The video is from 2015 it's amusing, most of the things are true, most things mentioned are over simplified, but that's for the audience, OK, anyway.

There was one point in the presentation about TDD. He (Dave Thomas) didn't use TDD and not writing tests. That's a big Huh, really. Yes, I assume, what he want to point out is that if your very experienced in TDD you can write TDD like code without a tests first. This works fine if you have the ideas of decoupling and separating of abstraction levels or concerns internalized deeply that you are capable to write TDD like code without the tests. I have to confess that I do it often in the same way. But that doesn't mean that I not writing tests anymore. I write test for following reasons:

1. To verify that complicated (eg. RegEx) or not intuitive code parts are working fine.
2. To clarify for other developers that this specific code behavior is important. 
3. To have a security net for refactoring.
   
4. Reverse engineering

Tests are still important and TDD is one really good approach for quality software. Don't drop TDD.

Dysfunctional Companies

 There are more dysfunction IT companies out there as you imagine. As freelancer there is a high chance to get engaged by a dysfunctional company. Some times it's possible to determine it before the engagement, some times not. In my working years I worked at least for three dysfunctional companies and I avoid to work for one.

1. First rule for dysfunctional companies, don't do that. It's pain to work there.
2. Second Rule: If working for a company and you find out that this company is dysfunctional, run, run fast, run faster. Leave the company because such companies can damage you.