Archive for juni, 2013

Many years ago there lived an Emperor. He was so fond of new clothes that he spent all his time and all his money in order to be well dressed.

Apparently, today we have a lot of ‘emperors’ so fond of new software that they spend all their time and all their money in pursuit of software solutions.

Visitor arrived every day at court and one day there came two men who called themselves weavers, but they were in fact clever robbers.

They pretended that they knew how to weave cloth of the most beautiful colors and magnificent patterns. Moreover, they said, the clothes woven from this magic cloth could not be seen by anyone who was unfit for the office he held or who was very stupid.

The Emperor thought: “If I had a suit made of this magic cloth, I could find out at once what men in my kingdom are not good enough for the positions they hold, and I should be able to tell who are wise and who are foolish. This stuff must be woven for me immediately.”

And he ordered large sums of money to be given to both the weavers in order that they might begin their work at once.

The hype curve of the potential usages of the product is as clear today in software as they are in this story.

The Emperor sends his old minister to check up on the weavers’ progress. The minister can’t see any product, but will not attest to the possibility that he is unfit for his job or very stupid, thus he expresses the wonders of the cloth.

The story repeats itself with other officials all claiming to see the wonderful product. Finally the Emperor is presented with the ‘cloth’ - and he too is too proud to admit that there is nothing there.

Getting dressed up in the makebelieve clothes, the Emperor starts off on a procession throughout the fair city. Everyone passed speak wonders of the cloth until a little child says: “But he hasn’t anything on.” Resounding throughout the crowd.

I’m not saying that software developers are swindlers - far from it, though there are less than adequate developers for some tasks. What I am trying to say is that people would rather try to keep up a facade of understanding than ask questions.

As Groucho Marx said: ‘It is better to remain silent and be thought a fool, than to open your mouth and remove all doubt.’

Silence is golden - unfortunately it is the price of silence, not the reward.

Software is not incomprehensible magic. If the solution you get is nothing like the solution you wanted, then most likely there have been communication issues.

If there is no executive support, no user involvement in the process, then you - the customer - will suffer. Whether this is due to failed projects, cumbersome work processes, or brittle solutions, you are partly responsible.

While H.C. Andersen might have had other reasons for writing The Emperor’s New Clothes, my parallel is the IT-illiterate decision makers out there. I’m not saying that everyone must speak IT, I’m saying that you should know your limits, and if you don’t know stuff you have to do, you should ally yourself with someone who can bridge the gap. But you should not be any less engaged in the production.

If you order a steak, medium-rare, at a restaurant, you would complain if you get a boiled steak, a well-done or a bleu steak. And rightly so. In software it seems you would not complain, just assume that you misunderstood the term, and the production facility - the kitchen and the waiter - performed their magic par excellence.

But this is just when it doesn’t go too bad. Quite often the parallel would be you orderingÂ lemon sole (the fish), and getting the sole of a boot with a lemon on top. Paying the restaurant for their services, leaving the establishment still hungry, and returning the next day for another order of misconceptions.

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.

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.