We’ve already been here for a few days, and now while I’m writing this sitting in the luxurious lobby of the Hilton sipping from a hot Hazelnut Macchiato, I’m really glad First8 gave us the opportunity to be here at JavaOne. A lot of sessions and presentations are about technology and frameworks we’re very familiar with at First8 and from a professional perspective we‘d like to stay updated on the latest Java platform developments, such as Java SE 8 and JEE 7, but next to that I‘m also keen on reserving enough time to visit personal interests ranging from agile methodologies to coding and design techniques.
“We’re an Agile shop, but because we’re Enterprise we have to do some planning upfront.”
It’s always a delight to hear Martijn Verburg and Ben Evans on stage work together – this time sharing their experiences in The Lean Startup Ninja. Both feel – after having founded jClarity – they get to do ‘bleeding edge tech’ now, but they had a lot of wise things to say about what it really meant to be “Lean” and “Agile” in general en hard-learned lessons from start-up life. Why? 7 out of 8 start-ups don’t seem to make the first 12 months at least in the UK – happily adding to it jClarity being at 18 months now. They experienced that if you have an idea, 5 or 6 start-ups are right behind you within weeks. They changed their product 2 or 3 times, changed markets (from cloud to enterprise and back to cloud again) and they finally laughed at their original business plan.
Lean practices that helped them:
- Stand-ups (showing any warning signs 24 hours in advance)
- Retrospectives (everything in the open)
- Small, 1 week, achievable sprints
- Being honest with clients 🙂
Any barrier to run tests, to go to production etc. are taken away from the developers. Time gets spend into thinking and prototyping (which happens quite often) up to 60% of the week – the rest is “just typing out the code”, which allowed them to achieve a lot in a 1-week sprint. This really got me thinking that you have to have a culture and supporting systems, not just talent, to be an order of magnitude more productive team.
Some other lessons I picked up which I think are also applicable to the regular projects I’m in:
- Validate your product early with actual, real customers. Only then you’ll get the actual feedback about the product, instead of waiting too long to get it our as a Beta.
- Poorly thought out UX will kill the experience with your application, so don’t just check with your peers (usually other “specialists”) but get things verified as much as possible in a user lab or similar construction.
- Try to automate as much as possible. Saves time, less errors, easily repeatable.
- Technical debt is much bigger risk than you think. It slows you down & makes you less flexible.
Martijn and Ben recommended a Lean Start-up Parody for your viewing pleasure.
In Functional Reactive Programming with RxJava Netflix’ software engineer Ben Christensen showed how the Netflix API uses RxJava, a library for composing asynchronous and event-based programs by using observable sequences with Clojure, Scala, Groovy and Java 8 lambdas, to implement concurrent webservices against asynchronous datasources without blocking, synchronization or thread safety concerns. Wow, that’s a mouthful. The shown examples were all in Groovy and very elegant, and some of the elegance of the “functional reactive programming” I hope to see actually being used in one or more webservice challenges we occasionally encounter in our projects.
After having missed almost 2 planned sessions by writing this post (which allows me to go to bed this evening on time once for a change ;-)) I hurried to Evolutionary Algorithms: The Key to Solving Complex Java Puzzles, presented by Bas Knopper of the Dutch NCIM. Pretty good speakers, the Dutch. He’s hoping to gain some traction about #EvolutionaryAlgorithms, develop some interest in the subject and add it to our developer’s toolbox of solving problems. The NASA video about “evolutionary antenna synthesis” explained very well how a handful of computers created hundreds of thousands designs for a new kind of satellite antenna which had to be a) small and b) still according to the specification. Great, but to make it understandable for us Java developers we need something more familiar… Traveling Salesman Problem:
- Given n cities (n = number of cities to visit).
- Find optimal route for visiting all cities.
- Visit every city only once.
- Return to origin city.
- Search space if huge, so brute force is not the solution.
What follows is a session filled with (not your average day-to-day) evolutionary theory of candidate solutions and survivor selections, but with actually seemingly pretty accessible Java code to match. The idea is that everyone should be able to apply this technique with some Java programming which isn’t all that complex, and I must say I do know more for what kind of puzzles I would contemplate using an evolutionary approach for. Fun session and +1 for the speaker’s enthusiasm!
That’s it for today. Tomorrow we’ll probably post somewhat earlier in the day, because we’ve got to get ready before the Oracle Appreciation Event 😉