Saturday, January 27, 2024

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.


Saturday, January 6, 2024

Dysfunctional Companies

 There are more dysfunction IT companies out there as you imagine. As freelancer there is a high chance to get engaged by a dysfunctional company. Some times it's possible to determine it before the engagement, some times not. In my working years I worked at least for three dysfunctional companies and I avoid to work for one.

  1. First rule for dysfunctional companies, don't do that. It's pain to work there.
  2. Second Rule: If working for a company and you find out that this company is dysfunctional, run, run fast, run faster. Leave the company because such companies can damage you.

Thursday, November 23, 2023

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

Thursday, September 28, 2023

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.

Wednesday, September 13, 2023

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.

Friday, April 28, 2023

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.

Friday, April 7, 2023

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.