Serverdude

The book, “The Essence of Software Engineering: Applying the SEMAT Kernel”, is written by Ivar Jacobson, Pan-Wei Ng, Paul E. McMahon, Ian Spence, and Svante Lidman. Published by Addison-Wesley, January 2013, ISBN: 978-0-321-88595-1

I am a bit confused. I had the notion that this was about improving software quality through the application of a rigorous set of rules. Section 1.1 “Why is developing good software so challenging?” seems like we’re on the right track. But I find that it has not that much to do with Software, nor Engineering. It seems it is a method for applying rules and visual indications for the progress of tasks by people for people. Which means that to me at least, this book is more about general project management than anything near software or engineering.

I found the tone of the book to be rather preaching and praising of this new found holy grail, the Kernel, all praise the Kernel, apply it to anything and everything. A common phase throughout is: “How can the kernel help you.” The kernel consist of just about 57 cards, but can be extended. Seems like the marketing managers choice for gamification Yu-gi-oh!-style.

I’m all for simple and concise ways of working. I do believe that visual aids can support collaboration and communication as well as bring a quick overview, and that these are needed for projects to succeed, but they are not all which is needed.

I believe in the “as simple as possible, but no simpler.” – as Einstein put it. As well as Antoine de Saint-Exupéry’s “You have achieved perfection not when there is nothing left to add, but when there is nothing left to take away.”

Throughout the book the Kernel will simply help do everything, it’s a veritable Swiss Army knife. I don’t think I’ve seen any professional choose the Swiss Army knife above their own set of tools. While the Kernel is lightweight – at least compared to RUP – then there are alternatives, which are even more lightweight, e.g. Impact Mapping.

To me it seems that applying the Kernel kind of looks like Kanban with a “work in progress”-board. But then it also looks a bit like a concurrent waterfall, which could be due to the fact that I read RUP and UML into the stuff that Ivar writes. Both of which were praised. In my opinion wrongly so. UML is great for back of the napkin illustration of concepts, a variant worked wonders in the Design Patterns book, but UML in the latest incarnation seems overly verbose as a modelling language – under the notion that a model is a simplified abstraction of the real thing.

Perhaps Ivar is biased from electronic engineering with all their symbols and glyphs (Try looking for IEC 60617 on Google). But what he fails to realize is that those symbols are really their programming language. For software development, we have our own programming languages, and we don’t need a modelling language to go into minute details – at least not as a document. If you generate the model from the source code you can apply as much details as you want, but believing that a change is applied both to the model and to the source code is betting against the DRY principle: Don’t Repeat Yourself.

Why do have a sense of concurrent waterfall? Well, the cards follow 7 aspects, called alphas: Opportunity, Stakeholders, Requirements, Software System, Team, Work, and Way of Working. While I agree to these, and their connections noted in the graphs, e.g. Figure 2-1 on page 15 (not shown here), then there is a notion of the 5 or 6 steps, and seemingly you can only progress, e.g. from Opportunity :: Identified to Opportunity :: Solution Needed. And while that might be true for opportunities, then I don’t see why Way of Working :: Working Well will stay there until the project is done.

Some of the praise in the book is from academia, and while it is easier to teach a rigorous system, it may still not be the right thing to do – at least it hasn’t helped adding UML, RUP, etc. to the curriculum.

In the praise section, Ed Seymour notes that: “This book represents a significant milestone in the progression of software engineering.” I’m sure that any book is a milestone in its domain, I just feel that this book is a milestone along a different road going in the, not quite right, not quite wrong, direction.

Uncle Bob – one of the three to write a foreword – wrote: “After reading the book, I found myself wanting to get my hands on a deck of cards so that I could look through them and play with them.” I felt the same at the beginning of the book, but now I’m thinking more about which game to play, and how many expansion packs will be published in the future.

All in all I’m quite disappointed with the contents of the book, though I’m sure it’ll get wide adoption, and we will be off course for another 10 years. Some of the contents is true and solid, the rest – apart from the intentionally left blank pages (all 34 of them approximately 10% of the book) – seems to me to be more of an academic solution to something which is only half the problem. It is easy to prove me wrong though – apply the Kernel to 12 or more different and average teams and have them develop successful software solutions on time and on budget for projects around the $5-10 million budget. Public projects seem to fare really poorly, that would be an interesting case to follow. If more than 1 project fails, then the Kernel is not the holy grail, depending on the success rate, we could argue whether or not the method is helpful at all.

I’m more disappointed with this book than I was reading Impact Mapping, which at 86 pages is about 25% of The Essence of Software Engineering, but with more information about applying the method, which is far easier if you can remember the correct order: Why, Who, How, What.

Resources

Written by Tim Berglund and Matthew McCullogh published by O’Reilly, ISBN: 9781449304638

The only book out there on Gradle, and it is relatively new published July 2011. At 110 pages it is rather short, and doesn’t cover everything about Gradle – it’s not a ‘Complete guide to Gradle’, but the 6 chapters cover the basics in the obvious ways:

1. Hello, Gradle!
2. Gradle Tasks
3. Ant and Gradle
4. Maven and Gradle
5. Testing with Gradle
6. Multiproject Builds

The book does provide pointers for migrating from e.g. Maven to Gradle. As I’m not intimately familiar with neither Maven nor Gradle, I can’t really say if it is sufficient to jump from Ant directly into Gradle, or if a quick pit-stop in the Maven (3?) camp is beneficial.

There are a few kind of typos in the book, e.g. Example 1-5 the src directory seems to be a subdirectory of the build.gradle file, this is fixed in Example 1-6 though.

There’s also a minor issue with the doFirst() method – I’d suggest saying that this would prepend or prefix the closure to the existing block as opposed to saying appending to the beginning.

The book is more concise and better organized than the Gradle user guide which seems to do a halfbaked description, then referring to a later chapter.

Running some modified examples from the book – not from the github repository – I experienced a rather detrimental blow up when applying the plugins for Scala and Groovy. The compiler dependencies need to be added to the build file.

Being the only book on the subject it’s sad that it’s not a Complete Guide, but it does fulfill what the title promises, it’s just not enough. An okay read though.

Gamestorming is a really nice collection of different games to play during a brainstorming session, or any other meeting requiring some different attack vectors – sometimes just to keep the meetings fresh and interesting.

The collection is a diverse set of different games ranging from short time, few people to long time, a lot of people.

Most of the games don’t require more than pens, post-its, and flipovers or whiteboards.

If I was to have more meetings than I’m currently involved in, and if those meetings were with collocated participants, then I’d love to use some of the games listed in the book.

Some of the games make me think of ‘The back of the napkin’ by Dan Roam (an excellent and inspiring book), and some of the games make me think of Esther Derby and Diana Larsen’s book: ‘Agile Retrospectives’ Needless to say that some of the Gamestorming games would fit a retrospective perfectly.

In this digital age, it puzzles me that I haven’t seen a plethora of utility software for this kind, e.g. a best match for meeting and games. But then, I may not have been looking.

The book is organized into 8 chapters:

1. What is a game?
2. 10 essentials for Gamestorming
3. Core Gamestorming skills
4. Core Games
5. Games for Opening
6. Games for Exploring
7. Games for Closing
8. Putting Gamestorming to work

So, who should read it?
Well, anyone participating in sufficiently many meetings where people tend to get stuck or wants to try a different approach. There are different ways to hold meetings.
Meeting leaders looking for a different way to motivate people, or perhaps to get a different kind of action.
Consultants, project managers, …

– and other mathematical explorations

21 chapters of mathematical recreation. Usually I find the professors books rather entertaining, but I must say I’m feeling a bit disappointed about this volume.

It’s off to a good start with “the Lore and Lure of Dice” – the context specific reflection on the question of probability, and the non-transitive dice. Then quickly passing Piet Hein’s board game Hex.

Why we’re introduced to Tarzan and Jane in the midst of an otherwise interesting subject, “Walking with quadropeds” – the patterns of the gaits of four legged animals, I have no idea.

Chapters 7, 8, and 9 touches upon time travel, which – as I recall it – is much more physics and sci-fi than mathematics. Luckily though chapter 10 serves a nice gem – Cone with a Twist – the sphericon.

Chapter 11 touches upon the shape of a drop, and in chapter 12 we’re back to probability and fallacies in The Interrogator’s Fallacy, where we now use Bayes’ theorem and Mathews’s formula. There’s an error in the formula printed on page 173 at the top though, it should be:
P(A|C) = P(C|A) * P (A)/ P(C)

Then we get to the title chapter: Cows in the Maze. And while it has cows and is kind of a maze – it’s not a standard maze, it’s a maze of logic statements.

Leaving the maze on a Knight’s Tour into Cat’s Cradle over Klein bottles (and Möbius bands) into Voronoï celled craters into knots, which again I found a bit disappointing.

The construction of Most Perfect Squares are matched up with Mathematical impossibilities.

The final chapter of the book regards dancing with strings forming regular solids.