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.
 

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.

2023 Software Development Review: What works, what not, what needs to improve, what to try next

The current sate of software development in 2023 from the practical side. What works, what need to improve, what to avoid and what to try next.

1. What is working well
   
1. Pair programming
2. TDD
3. Tidy First
4. Chore at Last
5. Agile Software Development
6. Distributed teams in the same time timezone
7. Remote working
8. Freelancers
9. Deploy often
10. OKR
    
2. What is working but still need to improve
1. SCRUM
2. Align business flows to teams 
3. Conferences
4. Code Metrics
   
3. What is not working and should be avoid at any costs
   
1. Waterfall plus JIRA and called Agile
   
2. Hybrid Agile approaches, whatever that means
   
3. External Service providers trying to dominate the customer
4. Team Metrics 
5. Big bang releases only
6. Complete Teams from Service Providers or agencies
   
4. What to try next
1. SCRUM beyond
2. Mob Programming
3. Pure JIRA
   

Anti-Pattern: SCRUM Backlog as Refrigerator of Agile Software Development

 

This is a well known ant-pattern of software development with SCRUM. I call it the backlog refrigerator. I choose that name because of the same behavior of backlogs and refrigerators. Both accumulate old things nobody need and blocks space for more useful things. 

Following points that you use your back backlog as refrigerator and not as backlog:

1. Backlog counts more then 50 items
2. Some items celebrating birthday (are older then one year)
3. Multiple duplicates
4. Slim description tasks where nobody can't remember the reason creating it

How to solve it

1. Remove every task that is older then 4 weeks without inspecting it. Why? It's much easier to recreate a task instead of holding and discussing it. 
2. Next step is to avoid such kind of backlog refrigerator. Therefore you have to re-thing what should in your backlog. My advise, only user stories and only for two sprints. This keeps the development team focused and keeps your backlog in size.

 

PS: These advises works for your frige and your backlog.

Agile Anti-Pattern: Architectural Decision Records (ADRs)

Architectural Decision Records (Link) are ... a decision log. How can ADRs improve the agile software development? What is the ADR benefit? I can't see it. For me ADRs looking like an 'cover your ass' thingy. After reading most of the linked articles, I'm very confident that ADRs are a new kind of the obsolete old Waterfall  Software Development with a cool name. It breathes the old idea that it is possible to catch all software requirements before we start to developing. This wrong assumption lead us to the first software crisis, it's proven false in the 90s and in 2022 too.

Suggestions:

1. Don't use ADRs
2. Talk with your real customers and write extensive user stories
   

Software Architect as Agile Anti-Pattern

You can find Software Architects in I guess the half of all German software projects. A Software architect is often a formerly senior developer. Sometime he is part of a software development team sometimes multiple Software architects are aggregated a Architecture Teams. Why companies think that a Software architect is good idea:

1. Increasing the software quality
2. Have the big architecture picture in mind and keep every thing right
3. Avoid divergent development branches 
4. Avoiding the development of concurrent solutions for the same problem over different teams
   

If you know more arguments for Software architects, please comment below.

 The main misconception is that companies and many developer too don't understand that software development is different to 'normal' engineering or building a house. The major difference is the complexity! Software development is much more complex.  This is also the reason why all model driven software development approaches fail.

Lets talk about point 1, Software architects ensure software quality. How could he do that? Bad Idea, give him the power to merge feature branches. This gives him the power do suppress alternative ideas. This means the software architect impede the software development progress. If he accept only code that is like his code he additionally blocks all development because every other developer have to ask for every thing. The creates a frustrating situation in the whole team. At the end, we impede progress, limiting work throughput and frustrate the software developers. 

Point 2, that's for me a pseudo argument. No team need a dedicated developer for this purpose. This is done by normal inter team communication. There is no befit but higher costs.

Point 3. Many project people like many developers believes that alternative solutions are bad because it"s a wast of time. But this not right. What you have to understand is that alternative solutions are great. You can choose between different solution and take the better one. If you have only one solution there is a risk that your current solution is the worst solution but in case of multiple solutions your are sure that the chosen solution is not worst solution. This is a totally underestimated benefit.

Point 4. This is a general misunderstanding of requirements. On the first view same problems looks equal. But in reality the problems are different. If someone comes with this idea around the corner please understand that this phrase is an indicator of a lack of user stories aka requirements. Pressing the second problem into an existing software solution ends up with a huge bunch of  technical debt and missing of at least one requirements.

At the end the software architect is not needed an brings more risk to every agile project. May software development can learn from golf. Golf is not a game of perfect. Golf is a game the best miss. The one that makes the smallest mistake wins. 

PS 1: Software architects are almost formerly senior software developers. Now in the new position they spend most of the time in meetings. Some of them have no time for coding. The advises they give are 5 to 10 years old. It's greeting from the past but not an improvement.

PS  2: I also worked together with great software architects (greetings to the real Mirko). But these guys working differently.

SCRUM Beyond: Nano Demo an efficent Technique

 Every agile developer knows the three long meeting at the Sprint change: Review, Retro and Planning. As an improvement to keep the development cycle short, shorter then the spring length is to introduce a so called Nano Demo. In the Nano Demo the developer presents the in the last days finished tasks to the product owner or to the users. You can do the Nano Demo periodic every two or the three days. The Pro of the Nano Demo is the meeting is realy short 5 to 10 minutes. The developers need no preparation time and the feedback loop is very close. That gives immedently feedback to developers without any delay. A second positve aspect of the Nano Demo is the better motivation of the developers by the close feedback.

Summary:

Nano Demo is a efficent Review technique used to improve SCRUM.

1. 5-10 minutes short
2. every two or three days or two time in a week
   

PRO:

1. Close feedback cycle
2. No Preparation from the developer side needed
3. Keep meeting effort short
   
4. Improve developers motivation
   

Part 1: What is wrong with SCRUM?

Since I started with XP, I mean eXtrem programming not Windows XP, I'm a big fan of agile software development.

I see many different companies as freelancer. Currently in the most companies I worked for SCRUM is the weapon of choice. There is no discussion to use it or not. SCRUM is the up to date way of scalable software development. The software development is scalable not the software. But in reality most companies have open or hidden problems with SCRUM. But why? SCRUM is easy, many good books are written about it you can hire SCRUM coaches What should could go wrong?

To make a long story short, every thing in SCRUM process can go wrong and it goes wrong. Believe me. But why did this happens, SCRUM is not complex and easy to understand. The answer is the people doesn't match to the SCRUM process. What? I believe that many experienced developers can't understand what it means SCUM doesn't match the people. But in one of the next post of the coming series What is wrong with SCRUM?, I try to explain it.

But not only the humans are source of trouble also SCRUM itself has some disadvantages that could be slow down the software development.

1. Growing technical debt
2. To high feature development speed

For booth problem exists ideas to solve them. In the following posts I will describe the problems and ideas to solve them.