Day 2 of QCon opened with Ralph Johnson on “Living and working with Aging Software”. The key takeaway was that as software ages, it gets brittle (hard to change as well as hard to understand) but that even though evolution occurs, there are likely some key nuggets which remain in the source for a long time to come. He cited the history of Word, in which it evolved from 1983 to today's Word 2010; there's a good chance that a number of users are younger than the source code of the application's key components.
As a result, there's a lot of “maintenance work” on software – he argued, anything since the first release is maintenance – but that the stigma of maintenance means that most don't consider themselves to be software maintainers. He did point out that as software ages, so does the knowledge base of what that software does; and expertise in the software tends to wane over time as turnover and lack of documentation occurs. His takeaways were to focus on the investment made in older software by continuing to employ older developers, as well as documentation and reverse engineering skills.
His hypothesis – that the average age of code gets older – doesn't match up with Kirk Knoernschild's observation that source code doubles every seven years; if true, that would argue that the average age is in fact getting younger. However, the base premise – that there exists code which is getting more ancient over time – certainly holds true.
He also referred to refactoring, and a short history of where it came from, as a means to keep software 'live'; though his comments on “what you wish your editor would do for you” seems to bely an ignorance of the state of most modern IDEs which, in fact, do that for you.
Next up was Jim Coplien's talk on DCI, which he's talked about on Artima before. He was certainly entertaining (if slightly provocative). He started by defining architecture as the essence of structure, or “form”, but noted that structure obfuscates form. He noted that the object orientation paradigm is just a way of thinking about form that captures the user's mental models in code; citing the Model-View-Controller as the vision of object orientation.
However, his thesis is that architecture is more than that; it includes the form of the business domain (what the programmer cares about, domain model in MVC) as well as the form of the system interactions (what the system does, what the end user cares about). His argument states that object oriented developers focus on the first more than the second, and expect it to evolve like the 'game of life' from the state of the system.
He used as an example the classic 'bank transfer', in which he argued that a user doesn't think about the objects, but the roles in which the objects play. In other words, a user may have many kinds of accounts (bank account, savings account, credit card, telephone bill, mobile phone credit ...) and rather than multiple objects, the user considers one to be a 'source account' and one to be a 'destination account', but which may change over time (or even reverse roles for the same objects).
His argument stated that this requires a new architecture; classes, interfaces, and “methodful roles” (also known as “traits” and similar to Spring Roo's use of aspects). The argument goes that a class may represent the object itself, but that it may be extended with a trait or aspect to fulfil different roles through the object's lifetime.
He stated that “Java is a toy scripting language; you cannot program object-oriented code in Java” – though this was a semantic sleight of hand. With other languages (C++, JavaScript etc.) it's possible to alter the state of the object at runtime; so one can have “BankAccount with SourceAccountTrait” on a single instance (rather than all instances statically). He argued that this implied Java was a class-oriented language.
The summary of the DCI architectuer was that it's possible to think about the objects/classes (BankAccount) separately from the roles that they play (SourceAccount). Furthermore, this implies that future roles can be added onto existing objects afterwards; although dynamic languages like JavaScript will permit such changes on an instance-by-instance basis, compiled languages like Java make it more difficult to change things at run-time (though arguably aspect-oriented compilation is a way of extending Java's classes with this).
He ultimately argued that this was the true agile architecture, since it could be used to share customer vocabulary, whilst exposing the parts that change as a way of allowing items to be amended over time. There's more information on The DCI Architecture, as well as a PDF on the subject, and a Baby IDE embracing the change. Whether you agree with his conclusions or not (and, I hasten to point out, I have tried to reflect his points here in a detached way; not that I necessarily concur with all of his observations), it was certainly a thought-provoking talk. And isn't that what we all attend QCon for?
I next went to Rebecca Parsons talk on “How to avoid "We never thought of that"” on multi-disciplinary teams and innovation of the same. One trap is the common vocabulary in which an existing team talks of acronyms which can be completely incomprehensible to new joiners or members of other interdisciplinary teams.
The argument is a good one; if you have people from different teams then not only is it more likely you'll have different kinds of team players, but also you will have people that don't have the same built-in assumptions about how the world should work. It's very easy to have a fixed definition and set of assumptions (e.g. the way that Java's object-orientation works implies a certain must-be behaviour for other languages; otherwise, where would Scala's traits have come from?) and that diverse teams can have this.
The other point made was that even expert opinions can be wrong. For example, using genetic algorithms to evolve a wing design resulted in things which would never have been invented directly, and in some cases, couldn't initially be explained either. So expert-guided solutions may lead to minima, but only optimal locally; there may be other solutions further afield that are more efficient which, unconstrained by assumptions, may result in a better solution.
Alex Buckley delivered an interesting talk on The Universal Virtual Machine in which he described how optimisations in the VM over the last decade have resulted in programs that are almost as fast as, or in some cases faster than, their natively-compiled counterparts. Ironically, the very reason for Java's perceived slowness was due to it's VM; but now, the very use of the same VM structure has resulted in Java's gains over the years.
He showed how the JIT can in-line a method if statically the types are known, and that dynamic knowledge can show certain optimisations are safe (but can be backed out later if needed). Most of the speed increase, he argued, is due to method-based in-lining which the other optimisations can support.
He also talked about the new invokedynamic instruction, which promises to give a real speed boost to languages like JPyton and JRuby. Furthermore, this potentially adds the ability to extend a runtime's type with new information after the fact (though still in a class-based, rather than instance-based way). It could also be used to define optional and default parameters to methods. The way that the invokedynamic is wired is by consulting a language oracle that says whether the transformation is good for future uses. If it is, the JIT can get to work and use that information to implement further calls. The language can implement hooks to break or replace existing methods to support further evolution.
Although there's still no timeframe for whether (or what) will be part of Java 7, the invoke dynamic is part of the OpenJDK experimental builds.
Dave Farley and Martin Thompson gave a talk on LMAX, which included how they got their application to process 100k transactions per second with < 1ms latency. Their argument was that Java, by its abstract nature, can hide the implementation details of the underlying processor; and that by paying attention to those details (and being hardware friendly) one can get insane rates of transactions. The biggest cost is a cache miss; so by optimising the data structures and algorithms to be cache-line friendly (e.g. padding to 64 bytes to fit in one cache line) and reducing the amount of garbage created (e.g. reading from a stream into a constant buffer, then using a ring-based buffer to write data into fixed sized arrays, instead of having to re-create or cycle new byte array buffers), one can go at the native speed of the processor. Their architecture involved entirely asynchronous processing threads (so no synchronous delays) and a single 'master' thread reading through completed jobs in order to send to downstream systems. Because single threads were being used, no locks were needed, and because the majority of the data fits into the L1 and L2 caches of the processor, main memory did not need to be consulted (for reading purposes). They also observed that if writing data to disks in a streaming format (i.e not random access) then it's possible for large rates of writes to occur; disk is the new tape. Unfortunately, their slides are not available for download, but their room was packed to standing room only and the event was videod for subsequent production on InfoQ.
The day finished with a panel by the JavaWUG user group, in which three panelists talked about the future of Java. The event was streamed over the internet, but it's not clear whether the recording is available for off-line use yet.
If you're in early enough, there's the