The second day of the Software Passion Summit started with an inspiring talk by Gojko Adzic. He talked about a lot of different areas including software developments and requirements gathering. A few of his points were very interesting and lingered in my mind…
Gojko said that absence of bugs is not a guarantee for software quality, and good software quality doesn’t mean that the software is bug free. I find this very interesting, and true. I love that someone stands up and says it out loud. Perceived quality, which is the most important thing, is not dependent on the software being bug free. I think that if you deliver an awesome experience and a good set of features, most user are willing to ignore a lot of bugs as long as they aren’t showstoppers.
He also talked a lot about gathering assumptions and goals instead of requirements. Often the “requirements” are made up by people doing estimated guesses, and doesn’t say too much about what we are building and why. And “why” is very important… Gathering the assumptions and goals does. Saying that you assume that building feature A will result in an 50% increase in sales is much more useful, and measurable than saying that we need feature A that does this and that.
An interesting way to get to requirements is by using a technique called “effect maps”. It is basically a collaborative way to get to the requirements for a solution, and rank the different features. It breaks down the solution in a few “layers” or “steps” which makes it very easy to get an overview of what is required and its individual ranking. More information about effect mapping is available at http://gojko.net/effect-map
He also said that it is all about money, whether it be making money or saving money. Software development is ALWAYS about money. Get to the money and document that… Don’t let the clients say that they need feature A, instead force them to go further and explain why. Keep pushing until you hit the money, and then see if feature A is the cheapest way to get there. In some cases it will be, in some it wont. The important thing is the money, not the feature…
Another interesting comment was that we should measure business bugs, and not technical bugs. Look at what the application is doing wrong, not what the code is doing wrong. He mentioned that he published a book, and during the production something went wrong and some lines of text were cut and combined incorrectly, and some restructuring of his text ended up giving the wrong meaning. However, having spent several hours documenting all these bugs and communicating with the publisher, the publisher said that it didn’t matter. He argued that people would give it crappy reviews and it would affect his own brand. But as the publisher pointed out, the reviews on Amazon were all 5’s. So even if there were bugs in the book, the end result gave the end-user a feeling of quality, which is the only thing that matters. So even if there were a bunch of bugs in the system, spending hours finding them was useless, and the end-users still perceived the book as great…
He even said that he in many cases would have unit tests there to make sure the code was written correctly, but then turned them off as the were useless once the had succeeded once. Quite an interesting point…
The final thing in his talk that stayed with me, was “specification by example”. Don’t just write requirements and specifications, no one reads it anyway, instead document examples. Basically for all the requirements that is identified, document examples. Examples are much easier to look at and understand in a short period of time. So when you come back and need to fix something, it is easy to just find the examples and look through them and understand the requirement. It is also very easy to turn these examples into unit tests for your code… More information about it is available at http://www.specificationbyexample.com/…
That was pretty much all that I have left from that talk, which is actually a lot more than I normally have. I hope I haven’t offended Gojko by misinterpreting his presentation. I might have…and on top of that my English might be a bit crappy and unstructured, but I am sitting on a train after a whole day of sessions and I am probably not completely coherent. Sorry about that…