GOTO conference Amsterdam – report of day 1
The opening keynote was by Google. Kasper Lund gave us the almost-worldpremiere of Google’s new programming language: Dart. Dart is a substitute for Javascript. We got a technology preview, and some Dart programming was done on the spot. It was interesting, but due to its Javascript integration being not very strong, I wonder if there is a feasible migration path for the enterprise. Good Javascript integration, combined with a few Google websites, all in Dart, is at least needed to get wider acceptance, I think. For more Dart info, see for example http://dartinside.com.
After that there was a session by Fred George titled “Programmer Anarchy”. The speaker explained how his company, Forward Internet Group, had tried Agile but it did not work (I heard familiar agile pitfalls pass by) and that they went “Beyond Agile” to a state where the programmers controlled everything, no managers (not even Scrum Master or similar), the customers can request but no say in what they get, none of the agile practices are performed, and that the company makes approximately one million pounds profit per developer. Impressive that they have achieved that in this way. It must be said however, that they have a strong (unit-tested) framework within which they have little apps that each have a short lifespan. This allows their ecosystem to work I guess.
Next session was a very interesting story by Jez Humble (co-author of Continuous Delivery) titled “Remediation Patterns – How to Achieve Risk-free releases. Main point of Jez was: If something is painful to do, do it more often. Release often and in small increments. Be able to release with the push of a button. Then you can release a fix quickly after you notice things go wrong. According to him it was more about Time To Repair than about Mean Time Between Failure, he compared it to a Jeep versus a BMW, a Jeep is often broken but much easier to repair. A BMW does not break often, but if it breaks, it is expensive to repair. He also talked about “canary releasing”: release the software to a select group of users first. If that works, you can convert more users so you can also test the software under increasing load. In addition, he advised to monitor business metrics in your application because you can then quickly see whether the metrics trends go in the wrong direction after a release. All good stuff but not easy to pull off. Though if your business depends on your software you’d better make sure you can detect quickly if things go wrong and better be able to fix it quickly as well.
The next session was stimulating and entertaining: an angry Greg Young in “Developers have a mental disorder. The only presentation this conference I’ve seen that was done completely without technological aides: purely the man himself. He said that developers too often grab their known frameworks for a product, even before they know what the customer wants. You do not always need a database, ORM layer, web framework to build the needed application. He coined “Developers are good at solving problems nobody has”. I think he has a point. Tool and framework choice seem very often dogmatic, or just because it’s the only skill the available developers have.
Then there were two Danish developers who had an interesting topic : How do you test your Android applications, because each device works definitely different (more than just screen size, the defaults for all screen objects are different from other brands, bugs in still-used older OS versions, etc.). They have made a super cool rack where they have 12 real devices mounted on servos so they can get landscape mode. On these devices they run the Cucumber test scripts in parallel. Customers can easily upload their apps and scripts, and then their test gets scheduled among the other customers. This was basically a product demonstration, but the testing rack made up for it.
The closing keynote on the first day was by Steve Vinoski, who gave a summary of a few ‘Innovation’ books. His main lesson was: know the innovation cycle (innovators, early adopters, early majority, late majority, laggards) and be aware of the chasm which your innovation has to cross or it will die a silent death. Know which category your customers are, and yourself, your manager, your colleagues ….

This was the end of day 1. I’ll write about day 2 in a next post…
Recent Comments