How to Fix NPEs forever

Null is biggest flaw of Java, saying some developers. Null causes NPEs causes crashing software. IMHO this is the same vibe as C vs Rust and I totally disagree. Crashing software is caused by developers and not by the programming language.

The easiest and best way to prevent NPEs is … proper exception handling. It is as simple as it sounds.

Bye the way, NPEs are often a side effect of OOP. All Objects are unsafe until you checked them. But checks are unsafe so go with exception handling.

 

 

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.

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.

 

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
   

Test Driven Development (TDD) more then software tests

In the practice of software projects and software developers there are great misunderstandings about test-driven development (TDD). Most developers do not see or know the difference between JUnit testing and TDD. They believe that TDD is a theoretical, time-consuming testing approach.

 TDD is more then testing:

1. Proof that your code does the expected thing
   
2. Safety net for (your ongoing) refactorings
3. Helps you to separate concerns in your code
   
4. Last but IMHO most important, TDD is the spec of your code
   

PS: If you think you have to spend more time for the TDD, try it without.

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.

Test Coverage as Software Metric

The measurement of test coverage is often used as indicator of software quality. This is OK but be a aware of following interpretation of this number, if the test coverage is low that means:

1. You have to write tests
2. You are in trouble because your code is not developed in the TDD way and the code is not easy to extend or to maintain.

On the other hand if the code coverage is high, this means nothing. Or with other words: 

High code coverage != High quality code

How to build stable and reliable System Test for Micro Services

Work in Progress, I'm currently overwork this article. Please come back later!

 

 

System tests are testing the orchestration of a bunch of micro services. Most of the test covers external features used by other micro services or by the front end.

If the current micro service is optimized for resilience (Yeah, Great) then system tests on feature endpoints can't discover errors related to (incoming) dependend micro services. The root cause of this lower power system test is the decoupling of micro services eg via the Fail Fast Pattern  or other Circuit Breakers (Thanks to Netflix). Or with other words resilience pattern could reduce the value of system tests.

System Tests improved by Diagnostic Endpoints

One way to avoid this negative side of resilience is to introduce what I called Diagnostic Endpoints. A diagnostic endpoint is only used by system test an not by features. The goal of diagnostic endpoints are to verify that functions that are covered eg by resilience pattern work.

In the real world, we save a huge amount of time after establishing of diagnostic endpoints. The software developers and the Project Owner love them.

How to avoid Fat Git PRs with massive changes

Fat PRs with massive changes are a huge  and anyoing workitems for reviewers. The question is how to avoid these massive Git pull requests (PR)? But there is a more easy way.

Massiv PRs contains many changed files. If you look more into the detail you can recognize differtent pattern of code changes:

1. Code changes not related to the new function. These changes are clean-ups olf existing code without any relation to the new functionaliity. These changes are caused by the boy scout rule "Every time you work on some code it may get a little bit better." This is called Tidy First.
   
2. Changes that relates to the function but are only preparations for the following implementation. These changes are functional neutral.
3. The new feature itself.
4. Cleanup the new feature code. These changes are also functional neutral.

The idea is to split large PRs into smaller PRs by seperation of these concerns. This keeps PR small an easy to review.

The down-side of these PR seperation of concerns that all code changes are spread over multiple PRs. You review 3 times code that will properly change again. Rool-backs are maybe a little more nasty. 

At the end reviewing 4 PRs looks like extra effort but it isn't because every PR is bound to his own concern. That makes it much easier to review.

Fail Fast vs Fail Early

If you look into Stackoverflow or so, you see tha Fail Fast and Fail Early used as synonyms. But that is not true. Let me just explain it.

Fail Early

Fail Early is working on method level.  The idea of Fail Early is to verify at method entry the parameters. The result is an early return or an early exception. The downside of fail early is that you have multiple exit points. That's why you have to keep your method short. But you have always to keep the method short or you handle different concerns in it.

At the end fail early is a technique to verify method parameters at the start of the method to avoid issues caused by data. The Lombock annotation @NonNull is a simple kind of fail early.

Fail Fast

Fail Fast is working on System Level. It's a technique to improve the resilience of micro services. It's a server side implementation of a circuit breaker. I developed this idea 2014 for a German company but I think many other software engineer also has the same idea. The fail fast pattern could be implemented in diefferent ways and for differen aspects of the software system. Now two examples of the fail fast pattern show the different aspect of it:

Fail Fast Example 1: Health Check

The micro service monitors his own health and if the service in unhealthy maybe because of an unhealthy or not responding subsystem the service can decide of fail fast some related (HTTP) request without going the whole service to the unhealthy state.

Fail Fast Example 2: Performance Check

The micro service monitors his own  request runtime. If the runtime exceeded a timeout the the service can cap the reuqest execution to free resources and response with an (HTTP) error code. This improves the performance resilience of the software system.

If you understand this pattern, you can imagine that are many more cases for Fail Fast.

Over all, the Fail Fast pattern avoid that slow or weak subsystems can shuts down all your services. It's a kind of an circuit breaker apttern.

Summary

• The difference between Fail Fast and Fail early is the Abstraction Level. Fail Fast protects your micro service. Fail early makes your methods more stable. At the end you should use booth.
  

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
   

Reduce the code to the minimum

Reduce the code to the minimum but not less. This fundamental  principle of mechanical engineering fits also extremely well to software engineering and software resilience. Remove all unneeded wrapper, boiler plate code, indirections. 

1. Less code mean less bugs
2. Less code keeps your software side effect free
3. Less code means less hidden knowledge 
4. Less code - less dependencies
5. Less code means less code to read

But be careful. Be sure that your code is well-covered from tests. Every mature project came's into a phase where the software developer delete more lines than they are writing new.

How to name a method.

Class Names and Method names are more important like the most programmer expect. If your software is longer then 30 lines, you should invest some time to find a good name. If you don't know what I'm speaking about, please read this book Clean Code.

If you look more into the naming topic, you will see that the amount of method names or name patterns are very limited. But on service level you find a vary amount of strange names. To avoid mixups, following the SQL query pattern for method names, eg. 

List <Product> getProductsByCostumerIdSortedByDateAsc(final String customerId) 

is a rely good understandable method name, the concern is clear, and the meaning of the method parameter is clear and the side effect (sorted) is also clear.