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
3. External Service providers trying to dominate the customer
4. Team Metrics 
5. Big bang releases only
   
4. What to try next
1. SCRUM beyond
2. Mob Programming
3. Pure JIRA
   

Raspberry 4 als Streaming Client für Netflix, Amazon Prime und Youtube

 Die Idee ist einen Streaming Client auf Basis eines Raspberry 4B zu bauen. Die Anforderungen:

1. 4K Video mit 60 Hz
   
2. Netflix, Amazon Prime und Youtube
3. Touchmonitor

Ein Pre-Test ergab, dass der Raspberry 4B mit 4 GB RAM nicht in der Lage war 4k Youtube Videos zu streamen. Er konnte 1080p Videos streamen aber das Bild war sehr rucklig. Er schaffte keine 60 Hz.

 

Das Ergebnis

Wir warten auf den Raspberry 5 der Ende 2023 erscheinen soll. Die Rechenleistung des Raspberry 4 reicht nicht für einen 4k Streaming Client.

How to transform legacy Software into up-to-date software

How to transform legacy software in to up-to-date software.

You have to follow these steps, I will explain the steps later:

1. Evaluate the state of the current software

2. Improve the Understanding of the software

   1. Generate missing documentation and charts

   2. Improve logs and error messages

   3. Use better names in the code

   4. Simple refactoring

   5. Simple test improvements

3. Managing the expectation of the lower management

4. Building the test fence and closing the gaps: encase the code with test

5. Refactoring as long as you need it to achieve your view of up-to-date software

Well, lets look into some of steps above.

Point 1: Evaluate the state of the current software means talk with customers, testers, developers with every body that has a stake in the software. Analyze the errors related with the software. Analyze the reasons for the errors. What are the risks. These five point gives you an raw overview and scope.

Point 2: Improve the understanding of the software means change the software to improve the understanding without changing the programming logic.

Point 3: Manage the expectations of your management. This is important because managers are often no programmers. It’s hard for them to understand why it is so important to transform the legacy code into maintainable code. It’s important that every body understand that you have tp spend some time now to save a lot off time in the future. It should be clear that if you don’t transform the software then you stuck in the future and the software is dead.

Point 4: Test are part of the product. Software without test are not software. Legacy software has often bad, useless and sometimes misleading test. Remove them makes the following refactorings much easier. But fence the software with test and close all gaps. This tests are the cornerstone of your software transformation. The test specifies the the behavior of the software.

Point 5: Just do it. Now you have the knowledge, the support of the management and the tests. Let’s do the refactorings.

Improve Code Coverage Metric

 I know, every body knows that Code Coverage is a weak metric (Link). But there are two ways to improve the value of he code coverage metrics:

1. Remove all exclusion pattern
2. Remove integration test from the calculation

Point 1 should avoids that you cheat your self.

Point 2 is not so obviously but it's easy to explain. Integration tests ensure that the whole software or larger parts work. Unit tests are the result of TDD and code coverage could measure the TDD impact. That's the reason why only unit tests should part of the code coverage calculation.

CQRS/CQS is a way to share data over two micro services via common data source

 Best practice in micro service design is share nothing. every micro service have it own data store. This makes the micro services resilient against slow data provider and resilient against outages of data delivering micro services. But there is one way to speed up this micro service architecture. If you use the CQRS pattern (Query Responsibility Segregation) or CQS pattern (Query Command Separation), my favorite pattern, and combine it with micro services.

Service A write or modify data only e.g. import billing data as large CSV  from the main frame. And Service B (E-Commerce-Backend) read only the data. Service B doesn't alter the data, it's a read only service. Both services using the same data source. Under this conditions (CQS) a common data source is a save and easy way to handle common data in a micro service environment.

Tight coupling vs Lose Coupling by Abstraction Level

Over the last decades, lose coupling is know as good development practice. Yes decades is right, we have 2023 now. 

But often it helps to know what is not lose coupling and then to replace it.

Abstraction Level	Tight coupling	Lose coupling
Application	Monolith, Modules	Micro Services, Lambdas
Packages, Classes	Inheritance	Dependency Injection
Code	Good classes, Spaghetti Code	Separation of Concerns, TDD

Indicators for bad software design

There are many well known bad code indicator which are tested by different metric tools like PMD, FindBugs/SpotBugs, Sonar or ..

 

But there some bad software design indicators that are not covered by tools, at the moment. Remember these indicator works well for every day software development.

1. Test are not executable at my developer computer
2. Long test methods or test classes
3. Tests with conditions (if, ...)
4. Test with checks against a logger
5. Inheritance in test or in main code
6. Comments 
7. Byte code or class manipulation
   
8. ... will be extended
   

Not every indicator will point to bad code but in over 90% the indicator is right. I will explain the indicator in later posts. 

If you know a good indicator for bad software design. Please comment!

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.