How to simply improve efficiency of software development without costs

It's an often heard, software developer have not enough time for coding. Short look in my calendar reveals that I have at least 20% meetings and I know many developers have much more. So how can I increase the efficiency of coding:

1. Skip useless dull meetings
2. Work only at one item at time and close all tabs and applications you don't need for the current task.
3. Don't switch to often or to fast between topics. I call it: human process trashing, it's a computer analogy of https://en.wikipedia.org/wiki/Thrashing_(computer_science)
4. Regular breaks keep your mind fresh
5. Try to switch between topics after a break like in the morning or after lunch 
6. Don't work overtime 
7. Finishing your tasks before going into weekend 
8. Compensate your sitting time at work with sport

And as Bonus: Writing, reflect and write it down. The important part is writing! 

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 log 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.

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

 

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

1. What is working well
   
1. TDD
2. Tidy First
3. Chore at Last
4. Agile Software Development
5. Distributed teams in the same time timezone
6. Remote working
7. Freelancers
8. Deploy often
9. OKR
10. Linux on development clients - new entry
    
2. What is working but still need to improve
1. Pair programming - down from What is working well 2023
   
2. SCRUM
3. Align business flows to teams 
4. Conferences
5. Code Metrics
   
3. What is not working and should be avoid at any costs
   
1. Waterfall plus JIRA, some Companies call it Agile Development but it isn't
   
2. Hybrid Agile approaches, whatever that means
   
3. External Service providers trying to dominate the customer
4. Team Metrics like Sprint Velocity
   
5. Big bang releases only
6. Complete Teams from Service Providers or agencies
7. Distributed Teams over time zones with big time differences
   
4. What to try next
1. SCRUM beyond
2. Mob Programming
3. Pure JIRA

Pair Programming is going down in 2024. Well, pair programming itself is still major productivity improvement. Why I move it down is that there are huge obstacles starting with par programming. It's very important to find an easy way to lower the entry obstacles.

2024 ONCD Report - Toward to Secure Software - My Review Part 1

 In case you missed it, the Whitehouse released the ONCD Technical Report - A Path Toward Secure and Measurable Software (Link).

It's a only 19 pages long report containing mostly nothing new or interesting. You can read it but is mostly dull. More interesting are some of the source links.

The only important thing is the preference of memory save programming languages. Well, this could be the end of the Rust vs C debate, but it isn't, see this video with Linus Torvalds (Link).

What you can take out of this debate, if let all the pseudo relgiouse aspects of programming languages beside, there two takeaways:

1. A fool with a tool (programming language) is still a fool
2. There are some programming languages (Rust, Go, Java, ...) that have advantages if you are not Linus Torvalds or me if you are a normal software developer
3. The discussion about which new programming language will be so much better, will never end. 

What I personally found remarkable in the Video was the argument of simplicity of C.

Next chapter, the verification thingy, I have major doubt of this idea, It sounds for me like some academics are on the search for gold. The other thing, the usage of trustfully libs, dam this common sense. But for Go and Python this is areal problem at the moment.

The next chapter about software measurability, hey that's exactly my business. At the end, it's a hard problem to measure software security, no way Sherlock.

To be continued ... or not.

The rest of the report is generic or common bla bla. It's not worth reading.

NSA suggests these memory-safe programming languages

 

1. Go
2. Rust
3. C#
4. Swift
5. Java
6. Ruby
7. Python
8. Delphi/Object Pascal
9. Ada

Source https://readwrite.com/the-nsa-list-of-memory-safe-programming-languages-has-been-updated/

 What is missing: C, C++

This recommendation exist because of the ONCD Report from the White House.

Sources

1. https://www.whitehouse.gov/oncd/briefing-room/2024/02/26/memory-safety-fact-sheet/
2. https://www.whitehouse.gov/wp-content/uploads/2024/02/Final-ONCD-Technical-Report.pdf

 

OK, wait for more insides.