‘Trunk Based Development’ of ‘GitHub Flow’?

Wacht? dit is niet hetzelfde? De twee branching en merging strategien lijken ook erg sterk op elkaar. Er is een subtiel verschil: daar waar de release vandaan komt.

 

 

 

 

 

Bovenstaand: GitHub Flow een release komt van de branch

 

 

 

 

 

 

 

Bovenstaand: Trunk based development: een release komt van de master/trunk.

Dit subtiele verschil vermindert theoretisch de kansen op regressie.

Maar: als uw afdeling erin slaagt om de levensduur van branches tot een absoluut minimum te beperken, dan is deze discussie een stuk minder belangrijk.

 

Source: https://trunkbaseddevelopment.com/alternative-branching-models/

 

 

 

mini-review: The Phoenix Project

A novel about how to implement a DevOps culture and organisation. The protagonist is confronted with recognizable IT problems and obviously solves them 🙂

The good: Written as a novel and as a tribute to Goldrath’s famous ‘The Goal’. This helps you identify which aspects of Lean will benefit IT, Software development and service management (using DevOps as end goal to implement)

The bad: Many of the people in the book talk the exact same way: It’s easy to loose track of who’s saying what because of that. Characters have little to no development when the story progresses.

The verdict: So? is it any good? absolutely! Great book, not a great novel. get a copy here:

 

 

 

Martin Fowler on NOSQL

Great talk about what NoSQL is, what it is not and how everything is not going to change radically: just some new options have presented themselves.

Jez Humble on Continuous Delivery

Good talk here on why continuous delivery is so important when doing agile software development. Martin Fowler is present as well, although he manifests himself as an on-stage ghost because of broken mike and standing in the back of the stage. Good summary of the importance of continuous delivery.

Software for a concurrent world

Joe Armstrong makes a strong argument for programming in parallel because more powerful linear processing is a dead end (simply said).

source is a infoQ talk

 

 

What’s that smell? Bad Code?

To determine whether a piece of source code is of good quality most of the time the first thought is: “I would have done this completely differently. ” We call this the “Not Invented Here” syndrome and can be very destructive to your product or project. Kent Beck introduced the term “Code Smell” to indicate obvious flaws in software. Most of the time Bad Code Smell is a precursor to much larger underlying problems that will eventually surface leaving the company with not enough time to fix them. Granted the term “smell” can still be very subjective: a much more objective way to look at source code metrics to determine the source code. Using these metrics in combination with a “smell report” would enable you to draw a conclusion about the source quality: is it well coded or the work of code monkeys. The next blog post I found a good argument to pay special attention to a single code metric: the CycloMatic Complexity. Cyclomatic Complexity can indicate too many scenario’s of a single method. It depicts the ideal number of different unit tests needed to cover all paths. Having a high complexity makes the code hard to test, thus smell bad. This indicates how difficult the code is to test either by unittest or manually, this has a direct relation to the maintainability of the code. Very interesting. Build systems for Java like the Maven PMD plugin support this metric.

Why is “Enterprise” software terrible?

The term “enterprise software” mostly covers software designed for use within large companies. This type of software often has many users and complex calculations for calculating pension statements or bank information. I have some experience with these types of systems. The quality of this type of software ranges from abominable to lean and mean. The quality is unfortunately most of the time more of the abominable type than the latter. Why is that? Are we an industry for the larger part completely incompetent? Are we not able to deliver a working piece of software that matches all functional and non-functional requirements? I do not think that this is the case. I’ve seen too many very good coders write utter junk because of time pressure.  I noticed while browsing the following post, in short: “The buyers are not the users”. I think this make perfect sense. Add to the fact that when buying software we try to spend as less as possible and you have the perfect recipe for a useless piece of software. The future? Much more reuse of common components using Open-Source Software. But were not there yet unfortunately.