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:

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.

https://www.zensoftware.nl/wp-content/uploads/2015/03/ZenLogo31-300x72.png00Arjan Franzenhttps://www.zensoftware.nl/wp-content/uploads/2015/03/ZenLogo31-300x72.pngArjan Franzen2008-10-24 07:27:262018-10-10 20:55:11Software for a concurrent world

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 MavenPMD plugin support this metric.

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.