Keynote :- Scaling Lean & Agile: Multisite or Offshore Delivery, Craig Larman
Being QCon, the keynote wasn’t a presentation by a sponsoring company. Instead it was a talk along the theme of one of the day’s conference tracks. Craig discussed his experiences in guiding some of the world’s larger IT companies in transforming their operations into large-scale scrum.
The talk revealed a couple of interesting ideas that rang true with my experiences from earlier in my career when I worked for much larger companies than my current employer. Larger companies tend to form component-based software teams, and once assigned to a team, the developer then tends to only work on that area of of the code. As a result, the team becomes very familiar with that code and so it tends to be very poor quality. What’s the point of spending time improving it, when everyone already understands it? This is the normal thinking in such teams. Agile shakes up both of these undesirable affects of component-based teams.
For agile to work in large corporations, Craig has found that first the component teams must be broken up. They are then replaced with customer-centric-feature teams. By their nature, these teams will be both transitory (feature requirements change per project) and multi-component based. Because developers now have to deal with much larger amounts of code, there is now pressure for that code to improve in order to make it easier for less experienced developers to work with it.
There was one great line from the talk that really resonated with me. That is that all organisations should treat their code as internally open source. In other words, no one person or part of the organisation should own the code. Everyone should be free to improve upon it and it should be structured and documented accordingly. This rings true with my “use protected; not private” bee in my bonnet that I’ve had for the last year or so.
From Minutes to Months, Dan North
The next talk was a last-minute stand in talk by Dan North. He used a mind-map to trace his experiences over the last year of going from being an agile coach to a proper code-writing developer once more. What he learned was the classic theory versus practice lessons. Many of agile software practice’s ideas are great in theory, but one must often be pragmatic and adapt them to work in reality. A case in point was his company’s approach to a prioritised backlog. Agile says you must have a prioritised backlog. The company he now worked for used a white board. Ideas are added, they are marked with a dot if they are being worked on, and they are removed if no one starts work on them after a couple of days. The whole board is wiped clean each week. And that’s it. They are a small team of six developers, working on short incremental changes, so this works for them.
Likewise he questioned whether the mantras of “Mocks are useful”, “Code should be test-driven” and “Never copy and paste” ought to be viewed as best practice to be adopted by all. Or whether they are just good advice to beginners to help prevent them hanging themselves with too much code rope. An example of “patterns for grown ups” was the use of the “Spike and stabilise” development pattern. Here one writes potentially junk code at high speed to test ideas, then throws much of it away, improves what’s left and writes tests for it. As this is my preferred method of code writing, it’s nice to have a name for it as it seems to legitimise it suddenly, rather than it being just me hacking. 🙂
Something that struck me as odd from what he presented was the use of the term “release”. Basically if you have an automated continuous integration and release process, then every commit is a release. So one can be truly agile and release many times a day. The downside of this approach of course is that you either you thoroughly test each commit or you risk releasing rubbish at times. I’m still unsure whether this is just me “getting” agile, or whether it’s an odd definition of release.
Software Quality – You know it when you see it, Eric Dornenburg
Eric’s talk was related to software metrics and the use of data visualisation to present those metrics in ways which people can easily understand. Most people find it hard, if not impossible, to look at rows of numbers and make sense of them. We are however very good at spotting patterns and oddities in those numbers if they are presented in graph form. He showed some great cityscape-like 3D tree maps that could show for example classes in packages, size of the classes, their cyclomatic complexity and number of methods per class all in one 3D map.
Eric made the good point that the use of such visualisations tended to provide a quick reliable way of sifting good code from bad. There is a strong correlation between bad code and ugly disordered visualisations as well as good code and ordered visualisations that are pleasing to the eye. I don’t know for sure whether such an assertion is true, but it sounds believable.
Learning and Perverse Incentives: “The evil hat”, Liz Keogh
This was a fascinating talk as it almost didn’t work, but came together at the end brilliantly. Liz talked about how as most people are scared of failure or of being told they did something wrong, we tend to fixate on the negatives. Companies build metrics, incentives and reward schemes around identifying the negatives and trying to fix them. Because the rewards tend to come from fixing failure, whole cultures of encouraging, or watching for, failure spring up as that is the only path to reward. It is much better to focus on the positives.
The talk almost didn’t work in my view as Liz spent the first two thirds of the talk citing negative examples and so seemed to be fulfilling her own prophecy. The last third though then brought the whole thing together. The upshot was that it is better to focus on the positives. If something goes well, thank those that facilitated it, look at what they did and try to replicate it and so on. The “evil hat” can be used to gauge whether a metric or incentive is a positive or negative one. Put on your evil hat and ask yourself “can I game this?” For example, if you measure your team’s performance on the number of bugs cleared each week, how might you game that? As there are many answers, eg by avoiding the important but difficult to fix bugs and cherry picking the easy ones, then this is a negative metric that is easy to game. So it should be avoided as a measure of performance. Instead such a metric might be used to gauge how fast your team can fix bugs on average in order to better estimate future bug fixing sessions.
The key point from the talk for me is that metrics are useful, but only as a source of information. Never use a metric as a target, otherwise your team will game it and you’ll be the biggest loser.
Agile Operations, Chris Read & Dan North
This was the weakest talk of the day for me and by the end of the talk I was left wondering quite what the point of it had been. Chris and Dan presented a series of examples of using configuration management, scripts and automation to simplify tasks such as deployment or machine setup. I – and no doubt many other developers – have been using such ideas to save time and improve system robustness for decades, yet they dressed the ideas up with modern trendy terms like “DevOps” and “Agile Operations” and presented them as a new idea. This was a very disappointing talk and the only one of the day that I didn’t think was interesting or useful.
Java without GC pauses, Gil Tene
This first day of QCon was a struggle for me. I’d managed to go down with a bad cold the day before and spent the day with a raging temperature; coughing, sneezing and wanting to go to sleep. It is a testament to the quality of most of the talks that I really enjoyed the day therefore. By the end though, I couldn’t face one of the smaller hot rooms of the other tracks so wandered into Gil’s talk as it was in the large hall next to the exhibitor’s hall. I expected to doze through a dull JVM talk. I was pleasantly surprised to find it was nothing of the sort.
Java, and all other managed-code systems such as .Net, ruby, python, flash etc, have a problem. The length of time taken to garbage-collect is directly proportional to the heap size. Once that heap size reaches the 2-4GB stage, garbage collection (GC) can take many seconds, during which the system locks up. Once the heap size increases to 100GB or more, the lock-up lasts for minutes. In situations where timely human interaction with the system is required, such delays are unacceptable. Therefore GC has become a true bottleneck to the growth of managed memory solutions. Unless we are all to abandon it and return to the hideously bad old days of C/ C++ and unmanaged code, a solution is required.
Whilst numerous semi-solutions have been found that delay “stop the world” phase for as long as possible, compacting the heap and adjusting all the living objects’ pointers still takes a long time and has to occur eventually. Everything still has to stop for this phase.
Gil’s company – Azul Systems – has come up with an ingenuous and “obvious, once explained” solution: use virtualization. By using a virtualizer, their C4 garbage collector can use virtual pointers. This means that memory can be compacted without having to change the pointers within objects. Instead indirection vectors get changed in the middle. These are fast to find and change. This results in the GC need never stop the VM from running.
Whilst C4 is available in a VM – Zing – that sits atop VMWare and like, what Azul are really pushing for is for operating systems to directly support virtual pointers. This is definitely a technology to keep an eye on in my view and was a brilliant end to the day for me.