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):
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:
If you are now interested in Myco, you can download the app by following the links below:
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.
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!
"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.
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 ...
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.
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.
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.
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.
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 ...
(the obligate wisdom from Steve Jobs, which seems fitting at that point)
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.
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.
If you are interested in Protractor, then this is a short tutorial and a longer introductory presentations
It’s always good to repeat that stuff ...
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:
Here's an updated version of my "What makes knowledge workers productive?" venn diagram pic.twitter.com/9FfmcjECiq— Oscar Berg (@oscarberg) March 24, 2014
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.
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
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!
I want to point to two special upcoming local conferences:
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.
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?)
The obligate Gartner prediction:
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.
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...
Unfortunately Marc will not be able to hold the workshop with me this year.
Actually Angular was declared a MVW (Model-View-Whatever) Framework to avoid further philosophical discussions.
Still, for my current Angular workshops I created my own visual interpretation:
What do you think?
PS: If you are interested in an AngularJS workshop for your team, please contact me at email@example.com.