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.

Unit Test Anti-Pattern 2

Branches and loops in unit test are tech debt.

General rule: unit test should have a cyclomatic complexity of one.

If of If-Else or Switch branches are a clear indicator that your test is bad one. It's clear that you are not testing one case, maybe your test setup is broken.

If you have catches (exception handling) this also mostly a indicator that you don't understand the code behavior. Don't mix this up with negative tests.

Loops are a little bit different, loops could be a indicator that your test setup is not optimal.

If you have higher cyclomatic complexity test you should try to refactor them. Have a look at parameterized tests, maybe it's the way to refactor your test.

Unit Test Anti-Pattern 1

 Unit test to only increase the coverage metric is an anti-pattern.

Example:

1. testing data object
   
2. testing getter and setter, ... if there is no logic in
   

Why it is an anti-pattern? Here my view.

1. These coverage only unit test hide missing tests because they increasing the coverage metric but not increasing the code quality. No logic part is tested and it makes the coverage metric useless.
   
2. If you have normal unit test then these tests covering all these simple things (getter, setter), if not then you ether missing real unit test or the code is not needed.