Sunday, October 12, 2014

Weekend Reader, Week 41


Wow, already week 41 … I missed some weeks since last time. Time to catch up!


The controversy around SAFe goes on:

Erwin van der Koogh on When is SAFe appropriate to use?

SAFe is great for companies trying to delay the inevitable.


 And there seemed to be some fun at the Agile Business Conference:



Trouble in Paradise: Disillusion about GitHub

GitHub was always my poster-child as a modern software company. Their approach to a no-managers culture is fascinating:

And the presentations of Zach Holman of GitHub are famous. They give the impression of being a paradise for software developers...

… but at the beginning of the year there seemed to leak some concerning stories from that paradise:

I don’t know what to think about it, but for me it’s a a modern case of “Paradise Lost”.


More about the No Managers Culture

How Medium Is Building a New Kind of Company with No Managers:

In Holacratic systems, individuals operate without managers because many of them have decision-making power in a particular area. And since everything is made as explicitly as possible, everyone in the organization knows who has authority over what.

Harvard Business Review: First, Let’s Fire All The Managers

Management is the least efficient activity in your organization.

What I find particularly interesting in the above HBR article is, that the No Managers Culture is not rooted in nor confined to the software industry.



More about Plans and Estimations

My Customers Need Estimates, What Do I do? 

If you choose to serve customers who need an estimate/price, then do estimates/prices. If you choose to serve customers who are willing to let requirements emerge, then get good at the Agile way. It’s your choice.

Two Reasons Why Estimates Aren’t Worth It

Creating estimates is pretty frustrating because everyone who sits in an estimation meeting knows that these estimates have got nothing to do with reality.

Why are software development estimates regularly off by a factor of 2-3 times? 
This brilliant analogy is showing the impossibility to plan a hike from San Francisco to Los Angeles. 


The challenge of planning incremental product development (from Incremental development at Spotify):

Incremental Development Spotify

Quote about plans from Friedrich D├╝rrenmatt:

Zufall Dürrenmatt

(The more humans proceed according to plan, the more effectively coincidence is able to meet them.) 



JavaScript continues to conquer the world:

But not everybody seems to be delighted:

Monday, September 29, 2014

Another JavaScript Bootcamp for Java Developers


At the beginning of this year I held my JavaScript bootcamp for Java Developers for Puzzle ITC, and it was fully booked.

Since then I had the pleasure to repeat the course several times for Glue, IMS, BIT and UBS and also at this year’s ch/open workshoptage.

Due to popular demand Puzzle is now repeating the course on October 6th in Bern. The course is public, this might be a perfect opportunity to get bootstrapped in professional JavaScript development!

Tuesday, September 9, 2014

Our App "Myco" reached 100’000 downloads! Here are some statistics.

Myco is a project of Stefan and me. We published the Windows Phone App in December 2012, followed by the iOS version in May 2013 and the Android version in April 2014.

The app is available in a free edition and two paid editions (standard and pro) on each platform.

The app proved to be much more successful than I would have expected. Last month we reached 100’000 accumulated downloads of the App.

In the following I present some statistics about the downloads of Myco:


Note that the Windows Phone edition is available since 21 months, the iOS edition is available since 16 months and the Android is only available since 5 months.

For me it is interesting that Myco seems to break with some common myths of app development (at least when we look at the last 4 months):

  • Android is the most successful platform regarding total downloads and paid downloads, followed by Windows Phone. iOS is trailing behind, even though our main markets are Switzerland, Germany, Italy and France where the iPhone has quite a strong position.
  • Windows Phone is our most successful platform regarding conversion rate. Apparently the willingness to pay is even bigger with Windows Phone users than with iOS users.
  • The conversion rate of Android is not lagging far behind Windows Phone or iOS. The alleged “unwillingness to pay” of Android users does not prove to be that significant in our case.

Of course the above numbers and conclusions are still quite premature. Our app is highly seasonal. We had a high peak last autumn where iOS was dominating over Windows Phone (Android was not yet released). Therefore we are looking forward to the current mushroom season, which has just started.

Some explanations of the above observations might be:

  • The Windows Phone edition regularly gets recommended by Microsoft in their store (Myco for Windows Phone has won the “Microsoft Switzerland App Award 2013”).
  • The iOS edition has probably the bardes competition, since there are many good Mushroom Apps in the iTunes Store.

If you are now interested in Myco, you can download the app by following the links below:



En generic rgb wo 45

Thursday, July 24, 2014

The Software Grief Cycle

People pile layers on top of layers, abstractions on top of abstractions, complications on top of complications, crap on top of patches, and patches on top of crap until everything collapses onto itself and the singularity appears.
- Source lost on the Internets


After reflecting upon my last Weekend Reader, I came up with some more thoughts about the fact that software is eating the world and the  long-run problems that result from the fact that we create new systems at an ever increasing rate.

Tudor plays with the idea of “Software Environmentalism". This implies that there was a clean environment that gets polluted by software systems. The assumption is, that, as in nature, the environment can only deal with a certain amount of pollution, therefore we must start taking care and according to Tudor's idea:

No system should get away without dedicated tools that help us take it apart and recycle it effectively.


Let’s see what Steve Jobs once claimed about software: Eventually it collapses under it’s own weight!


Let’s repeat:

"It doesn't matter what you do, eventually it will collapse”.

It's like with humans and death ... it's inevitable. We can prolong our lives by living healthy and modern medicine sometimes allows to keep us alive even when it does not make much sense any more ... but we all are getting old and finally we will die.

So there you have another analogy, actually a full bag of analogies.

Any software will age and finally it will die. Some software will age more gracefully than other software, but they all will die. We have to accept that. This is not an easy insight, there are the five stages of grief (denial, anger, bargaining, depression and finally acceptance). Letting the software die might become painful for everybody involved… especially if you try to deny the fact. Often developers are way ahead of management on the stages of grief:  


I would argue that we are still dealing with a very high mortality rate in the software industry today. But we are not dealing with the tragedy of stillborn children or sudden child death. No, in the software industry we mostly deal with monstrous frankensteinian abominations that will not be able to breathe on their own. Still we keep trying to somehow create the perfect monsters ...

Often we are helpless in dealing with dying software. There is also a lot of software that should have died a long time ago, but it was not allowed to. Nowadays there are armies of maintenance developers defibrillating, heart-massaging and mouth-to-mouth breathing thousands of zombie systems all over the world.

Undead code

How can we deal with dead and dying software? Maybe we just have to be more cruel (and more honest) and accept their death. Maybe this enables the rest of the software population to live healthier, maybe even to thrive and prosper… the other important thing here is to get rid of the dead. Make a clean break, don’t keep the dead (or  almost dead) software lying around. Dead or dying software has the tendency to keep you incredibly busy. If you are not cruel, you won’t get rid of it:


Different cultures dealt differently with ageing and dying individuals. A well known example is the senilicide in ancient Eskimo culture: Old people that could no longer contribute to the well-beeing of the group were cast out to die in the snow. This certainly was a very cruel way, but it ensured the survival of the group in times of scarcity.
It is a well known fact, that enterprises have big problems finding developers to maintain their legacy systems. Developers often are not motivated to deal with legacy software. The lack of good developers that deal with legacy software, makes maintaining dying systems even more difficult and can accelerate the rotting of that software.
So maybe this is the cruel way in the software development ecosystem: In times of scarcity, developers choose which systems should die by refusing to work on them ...


Saturday, July 19, 2014

Weekend Reader, Week 29

IMG 0210

On the News:

Translation of the Apple-IBM romance

You heard it, Apple and IBM are best friends now. But what does it mean? This funny post translates the press release into something that we can understand:

 Enterprises love hand holding more than fat kids love candy. Apple is going to offer them hand holding through IBM.


Reflecting on Software Engineering:

Software Environmentalism

My colleague Tudor is musing about how we can deal with the fact that software systems get larger and larger, and they are being created at an ever increasing rate.

We cannot continue to let systems loose in the wild without any concern for how we will deal with them at a later time.

He proposes:

No system should get away without dedicated tools that help us take it apart and recycle it effectively.

For the profession he concludes:

Software engineering is more about dealing with existing systems as it is about building systems.


The Maintenance Developer Myth and The Noble Art of Maintenance Programming

So, software maintenance and dealing with legacy code is only going to increase as software is eating the world. But introducing a chasm between “real” developers and “maintenance” developers is probably not going to help.


What are good developers anyway?

Why are we interviewing developers by asking architect questions? Is it really what we need? When we deal with legacy, architecture gets less and less important. Problem solving skills are what really matters ...


But software eventually collapses under it’s own weight

(the obligate wisdom from Steve Jobs, which seems fitting at that point)


On JavaScript:

Breach: A browser written in JavaScript

Atwood’s law exemplified: "Any application that can be written in JavaScript, will eventually be written in JavaScript." is on sale!

If you want to learn JavaScript seriously, this screencast is a good starting point.


A JavaScript survival guide

If you are afraid of the pain of learning JavaScript, this post gives you some valuable survival tips.


Tech learning  recommendations:

Modern Structured Logging With Serilog and Seq

This is a interesting course on pluralsight. I am wondering what the alternative would be for the Java ecosystem? I guess I will attend the ELK workshop at ch/open Workshoptage in this regard.


Java Script Jabber Episode 106: Protractor with Julie Ralph

A good introduction to end-to-end testing in general and to the Protractor test framework. The episode also contains good discussions about software testing in general and gives insight about testing at Google.


Getting Started With Protractor and An Introduction to AngularJS End to End Testing with Protractor

If you are interested in Protractor, then this is a short tutorial and a longer introductory presentations


Some facts about Stateless EJB beans

It’s always good to repeat that stuff ...

Saturday, July 12, 2014

Weekend Reader, Week 28

IMG 0207

Developers are taking over the world!


Everyone involved in software development projects should read the book The New Kingmakers.

The book gives the background why traditional tayloristic approaches are not effective in the knowledge work environments of software projects: Plans and roadmaps are not going to work as long as you don’t get developers intrinsically motivated.

For some reason the book is free on the Kindle.


On the same topic:


Planning, planning and more planning!

Speaking of motivating developers. In my experience, one of the most demotivating construct in enterprise development is planning. 


The Agile Manifesto speaks about "Responding to change over following a plan”.

While Scrum is facilitating many Agile principles, the concept of the backlog is often used to re-establish a waterfall-like long-term plan. With the long-term plan comes the justification for controlling and micro-management. Newer methodologies that promise to “scale agile to the enterprise” (like SAFe) even reinforce this tendency for establishing and following a plan (note how the arrows in SAFe all point in one direction?). SAFe is an approach by classical management to re-apply tayloristic approaches that have been questioned by the Agile movement. 

That’s why Water-Scrum-fall is the reality of Agile today.
And that’s why I don’t believe in scaling Agile to the enterprise
That is why we have the Manifesto for Half-Arsed Agile Software Development.

 Ken Schwaber (the inventor of Scrum) puts it like this:

A core premise of agile is that the people doing the work are the people who can best figure out how to do it. The job of management is to do anything to help them do so, not suffocate them with SAFe.


Do we really need strict control (which is basically the reason for all that detailed planning)?

Tom De Marco (a pioneer and author in the area of software project management) has an interesting thesis about this in his paper: Software Engineering: An Idea Whose Time Has Come and Gone?

strict control is something that matters a lot on relatively useless projects and much less on useful projects


What can developers do: They should choose their work!

So for us developers this boils down to making a choice: What kind of projects do we choose to work on?

Mike Monteiro repeats that in his brilliant presentations: How Designers Destroyed the World

The work we choose to take on defines us!

Webstock '13: Mike Monteiro - How Designers Destroyed the World from Webstock on Vimeo.



I want to point to two special upcoming local conferences:

SwissJeese - An indie JavaScript conference in my beautiful hometown of Bern (July 26th 2014). I have never been to that conference and unfortunately my talk-submission was not accepted (probably the topic of Nashorn is too enterprisy for the conference :-)). But the program looks very promising and there are still tickets left.

ch/open Workshop Tage - An excellent event with a marvellous collection of interesting topics (September 9-11, 2014). I am attending and also holding workshops at the Workshop Tage for the last 7 years, and each year I am looking forward to the event again.


Battle Cry

Speaking of conferences: Philip is calling for an epic battle: Web vs Native on mobile devices - let the strongest prevail!
(actually, according to the rules of Philip it would be the quickest, not the strongest ... maybe Philip should look again at what happened to Oberyn Martell?)


On JavaScript

The obligate Gartner prediction:

Through 2014, improved JavaScript performance will begin to push HTML5 and the browser as a mainstream enterprise application development environment.

ThoughtWorks Technology Radar chimes in

The ecosystem around JavaScript as a serious application platform continues to evolve. 

Prezi writes about their experience from migrating from Flash to JavaScript … and why it took so long:

Large JavaScript codebases are hard.

Stackoverflow explains the difference between JavaScript and Java

Java and Javascript are similar like Car and Carpet are similar.

One is essentially a toy, designed for writing small pieces of code, and traditionally used and abused by inexperienced programmers. The other is a scripting language for web browsers.


ch/open Workshop Days: Great Program as Always!

Ch open logo

The program of this year's ch/open Workshop Days has been published.

As every year, it is a great program with many interesting sessions. This year even with 5 parallel tracks. It’s going to be a hard for me to decide which sessions to attend...

On Wednesday I will hold my “JavaScript Survival-Bootcamp”. The session was a big success last year (fully booked twice), and I intend to repeat that.

Unfortunately Marc will not be able to hold the workshop with me this year.

Related Posts Plugin for WordPress, Blogger...