Mik Kersten talks about current and future trends in ALM and the support for approaches like large scale Agile, DevOps, Docker, Big Data, functional languages and the Internet of Things.
“BDD In Action” is a book that aims to cover the full spectrum of BDD practices from requirements through to the development of production code backed by executable specifications and automated tests.
The YOW! 2011 Australian Developer Conference was held a couple of weeks ago in both Brisbane and Melbourne and I was able to attend with thanks to Dave Thomas and the organisers of the conference on my press credentials for InfoQ. I had the ability to record some podcasts for The Agile Revolution and Coding By Numbers as well as chat with most of the Agile related speakers. Here are some of my notes from the sessions I got the opportunity to sit in.
Dave Thomas kicked off proceedings with some Lady Java:
Keynote: Top 10 JVM Erroneous Zones
Cameron Purdy from Oracle presented this session. Whilst it is good to see management levels talking about and understanding the core business, I found this keynote rather average. The presentation is available here.
immutability – no concept in Java, introducing would be good for thread safety but would also improve garbage collection (stop the stop -the-world clauses)
primitive types – binding between interface and implementation, improving would simplify and fix auto-boxing and generics, would need to make sure code compiles the same way
interface vs implementation – they are all the same thing, a problem that we all inherit from the same parent
properties – very fixed contract currently, need to loosen this up
obvious intrinsic types – Decimal needs to follow IEEE standard 754-2008 (754r), need to upgrade to a 128- bit world
real runtime model – JVM must provide predictability, need more access at code level
constants – no constants for intrinsics or other similar types
alternate class file format – limited to 64KB in methods, hierarchies make no sense like inner and anonymous classes
Getting the opportunity to see Mary Poppendieck speak is always a pleasure, for this conference she delivered her talk on Continuous Design. As the program host for the Lean and Agile track, I also had the pleasure of introducing Mary. Her presentation is available here.
continuous delivery misses design and feedback – how do we know what to develop if we are thinking about continuous delivery, has created a need
continuous delivery uptake is increasing, takes about a year to get going
need to assemble a diverse team – frame, ideaton, experimentation then iterate
3M – make a little, sell a little, learn a little (repeat) – the fastest through this loop is the winner – fastest can be four times faster
need good people (pay attention to hiring) and a whole team (need all the functions which can break the agile 7 +/- 2 model), measure success in customer satisfaction
start with customers – Amazon (working backwards – write a press release, write FAQ, describe customer experience, write user manual)
disruptive design – companies like GE are starting to design products for different markets like China and India rather than USA and Europe – resulted in different design , thinking, price point
need to decide when it is time for people to see it – it’s hard to refactor books, hardware and first impressions but you need to take a chance and find out that you are wrong – a balance trade-off
minimum viable product – biggest waste is building the wrong thing followed by complexity – build it and measure the response (learn)
implement a show me more button and forward to to an under construction page and measure the clicks
avoid vanity metrics, need actionable metrics, use innovation accounting – start with a hypothesis, build MVP, target initiatives at improving a growth metric in your hypothesis, measure done as adding value
use A/B tests to change your conversion rate
test early – don’t waste your time arguing
cohort metrics – operate on data, as people run into my product how do they behave
feature toggles – switch features on/off on demand, wrap entrance to feature with toggle code, control via configuration file – customers love it
canary releasing – take a small amount of users and give them a new version, need to be able to tell a good change from a bad change very fast – monitor key thresholds and roll back fast if required – make sure when something goes wrong it never goes wrong again
Apple – ” it’s not about money” – understand customer problem and the revenue will turn up
Google – “it’s best to do one thing really, really well” – stay focussed
Amazon – “think long term” – you don’t want make a lot of money off your best customers, some things don’t always make financial sense
3M – “hire good people and leave them get on with it”
I also had a great half hour chat with Mary on the second day of the conference where we talked in-depth about continuous design as well as size of the product team. She believes the key is to enable the complete development cycle and discover good engineering products. We should stop using software words, including Agile, and start using system level engineering. As for the team size debate, we should use system engineering and break our teams into appropriate sub-components.
60 Years of Innovative and Agile Work Practices
Nigel Dalton led this entertaining and informative trip down memory lane, and as the program host for the Lean and Agile track I also had the pleasure of introducing him. The presentation is available here.
people who pay your wages don’t know your stuff, this is a heavy duty approach that has been used for the last 100 years
1930’s Cabinet War Room – as close to an agile room design as you can get, war is a fairly big project!, agile does scale (WWII), lucky it did or this presentation would have been in German!, military and politicians were in the same room, no battle plan survives contact with the enemy
1950’s U2 and SR71 – if you do good engineering, you will be amazed how long it lasts
1960’s moon race – iteratively learning through doing, working rockets are the primary measure of focus
1970’s Luna Tractor – Russians were striving for a different question, what is on the moon?, different question and cost a lot less money, Apollo 13 is the greatest example of an agile project, ask the right question…
1980’s cold war fears – madness of strategic parity, Russians learnt a space shuttle program cost a lot of money after duplicating it, took the USA 30 years to learn it
product engineering is overarching, top down and empathetic
think about what you are going to do before you do it…
million dollar idea – ideas don’t matter and are usually terrible, originality does not matter, it is quality
ideas – it’s like a blank but with blank…
consider your customers – start at the end by making a commercial (30 – 90 seconds on the problem you are going to solve and how you are going to solve it)
your best product tester is your arch nemesis
in user interface – it is much more important to be consistent than correct
real artists ship – plan, design, ship on time!
don’t ship the rough draft
fear social debt much or more than technical debt – you can fix technical debt (you can but you won’t!)
shipping a product is like giving birth to a kid – there is a heck of a lot more work to come
endeavor to kill your own, you are never done, when people are raving about the first one, you are already finishing the second, you want an army of evangelists
Appsterdam – the most important thing we have is the community
the hook is the difference to a defining product, but need to keep being innovative
Better Testing With Less Work: QuickCheck Testing in Practice
no scientific experiments that show agile is any better
we need sleep – but average time is dropping, naps are good too…
we are hardwired to look at the horizon, so lift your eyes and look around and blink
lying down improves your cognitive performance
research from University of Queensland – the longer you sit the sooner you will die
the startling ideas come at a time when you are doing nothing
eat before you’re hungry, drink before you’re thirsty – when the brain is lacking energy, the default is to say no
we are hardwired to be close to nature – we do better with natural light and real plants around us, take 5 minutes outside in a natural environment
explain the problem to your dog or a stuffed toy
in meetings, when at an impasse, get each person to explain each others version of the problem
fearless change experiments – test the waters, reflect, small success, step by step
I also had the opportunity to sit in on a very interesting interview with Linda Rising on the Coding By Numbers podcast with Craig Aspinall and Steve Dalton.
Domain-Driven Design for RESTful Systems
Jim Webber delivered this entertaining session, perhaps the most entertaining part was when he tried to explain a cassette tape to a young audience member (I remember loading Commodore 64 games off tape…). His slides are available here.
continuous deployment – eliminate the fear around doing deployment
tests – a version of feedback, need confidence
automated deployment strategy – need to be repeatable using tools, need to be able to do quickly
need architecture that can handle inconsistencies in the system at any one time – different versions of API’s, etc. in the system at the one time
feature toggles – need on the technical and business side, toggles for beta users, power users, need to be able to work on one code stream all the time for it to work
traffic – need traffic for this to be successful, especially to get useful metrics
monitoring and feedback – what characteristics are being used, monitoring and qa are the same thing (see Steven Yegge’s rant on big SOA)
Apollo program was basically Agile and continuous deployment in the 1960’s – 61 launches until they landed on the moon – only way they made progress was because they were monitoring everything
record all the values all the time
pay attention to long term metrics, not just instantaneous
should use the word anomoly more (not bug) – use feedback to understand and fix our anomalies
Other Stuff
Joshua Kerievsky gave two talks at the conference that I unfortunately did not get to see live (Lean Startup and The Limited Red Society), but I did get the opportunity to speak to him in-depth with Renee Troughton for the Agile Revolution podcast.
Renee and I also did a wrap-up podcast.
I have also published a news article for InfoQ where I asked all of the Agile speakers at the conference what the Agile community needs to embrace in 2012.
Craig and Tony are at YOW! Conference in Brisbane and wander around the hallways talking to different speakers, hosts and attendees:
You must be logged in to post a comment.