My colleague Stefan created Myco / Pilzkenner for Windows Phone.
The App won the "Best Windows Phone Apps" award in the Microsoft Switzerland App Award 2013.
We partnered up and I ported the app to iOS. Myco is now available in the iTunes Store.
There are three editions of Myco:
If you like the app, please consider submitting a review to the iTunes Store.
From the great talk of Douglas Crockford about Quality:
This is so true in my experience... that is why I don't get why people are argueing over and over again that typing is one of the most important skills of a programmer (the latest is example from Miguel de Icaza and Scott Hanselman).
Software teams have to move away from the idea that bugs are a useful way to measure quality.
Software does not have enough self awareness to be afraid of bugs. That's why it works as well as it does.
Testing shows the presence, not the absence of bugs.
Bugs are like over-parented kids. They get a lot of attention. They might be born in the relative quiet of a developer's IDE, but the moment they are exposed to the rest of the world, they live their lives amidst a great deal of fanfare.
Maybe there’s no such thing as a bug. Maybe there are just things that work well and things that don’t work well.
Unfortunately, in the celebration of testing artifacts (such as counting the number of bugs) we forget about the software. All testing artifacts have value to the extent that they impact the source code and therefore the product.
Comprehensive statistics of past bugs are no more useful for software quality than financial accounts of a chophouse are useful for a steak sandwich.
Highly recommended: the first 5 minutes of Dan North reading from the Book of Geek. Its funny and poignant:
In the beginning the software was without form, and void.
The Architects said "Let there be light" and they separated the light from the darkness.
And they called the light Architecture and the darkness Hacking.
And Maven brought forth a Plague of Apache Commons, and there was a flood of all the Libraries of the Internet as a judgement upon the people.
It's funny how cake mix analogies pop up in interesting speeches lately.
Dan Ariely speaks about the IKEA effect that gives meaning to our work, which was essential for the success of cake mixes:
Dan Ariely: What makes us feel good about our work?
In her hilarious talk Christin Gorman shows how cake mixes are stupid and make us not enjoy our work any more, like many generic frameworks we use as programmers:
Hibernate should be to programmers what cake mixes are to bakers: beneath their dignity.
In his presentation "Designing For Rapid Release" (slides) Sam Newman points out an ugly fact that we often try to ignore: SOA and DRY are to a large extent opposed forces.
Of course this is not a new break-through discovery and I guess it is also nothing new for most battle-proven enterprise developers. But I also have the experience that in most SOA projects this topic is treated like the crazy uncle in the attic: You don't talk about it and you certainly don't plan for it.
The result is usually a schizophrenic feeling: The architecture postulates nice decoupling, but in reality we end up with the feeling that we are not doing it right: either we are using shared logic in several services which negates idea of decoupling or we have a lot of code duplication.
In the presentation Sam illustrated this conflict with two services that share a common domain model:
In the above picture, since service A and service B are both using a common model from a shared library, they get tightly coupled. On the other hand managing the development and releases of the shared library all of a sudden gets much more complicated under the premise that service A and service B should be decoupled.
He further brings the incompatibility of SOA and DRY to the point with the following quote:
Ending up with tightly bound services because of code-reuse is significantly worse than to copy & paste that code.
I like that Sam makes the conflict between SOA and DRY explicit. Not ignoring this fact is the first step to objectively balance the tradeoffs and to honestly plan how to deal with the drawbacks of either approach.
Nothing makes a system more flexible than a comprehensive suite of tests! Far above good architecture and good design!
We have as many testers as we have developers. And testers spend all their time testing, and developers spend half their time testing. We're more of a testing, a quality software organization than we're a software organization
TDD is a discipline for programmers like double-entry bookkeeping is for accountants or sterile procedure is for surgeons..
Tests should be made a first-class citizen and treated like any other feature.
TDD, BDD and other high-ceremony techniques are not recommended for startups! Code is not important in the beginning!
I see TDD as a valuable and important development technique, but there are contexts in which it shines and others in which it is a hindrance.
Insisting on unit tests won't make those unit tests valuable.
I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence.
If I don’t typically make a kind of mistake, I don’t test for it.
Testing is overrated!
A survey of all the studies on TDD has shown that the better the study done, the weaker the signals to its benefit.
Thinking you can improve quality by doing more testing is like thinking you can loose weight by weighing you more. […] If you want to improve your software, don't test more; develop better.
You cannot inspect quality into a product. The quality is there or it isn't by the time it's inspected.
Much of the essence of building a program is in fact the debugging of the specification.
