I was fortunate to get to go to Øredev 2009 last week, and wanted to share a couple of impressions with you. The picture on the left is me with my Øredev passport, after a very large espresso from one of the Oracle-sponsored baristas.
Øredev is a developer conference held each year in Malmö. This years’ event took place between November 4th and 6th. It is not a technology-specific event, but covers a wide range of topics such as .Net, Java, Agile ways, testing, project management, and web/cloud/mobile development. Talks range from concrete hands-on topics such as how to work with a specific technology, to more theoretical subjects on software development and computer science. Speakers are brought in from around the world, and include prominent figures such as Jeff Sutherland (“father” of Scrum), Cameron Purdy (Vice President of Development at Oracle), Dan North (agile thinker and consultant at ThoughtWorks), James Coplien (agile development and consulting guru) and Trygve Reenskaug (OO guru and “father” of the MVC pattern).
I think this mix is what makes the conference so interesting – you can discuss the nitty gritty details of your favorite framework with likeminded peers over a cup of coffee in the morning and discuss paradigms of software development with someone else with your afternoon tea, regardless of what technology they usually work with.
Over the course of 3 days I attended 18 talks and 4 keynotes, which again was only a small part of what the conference offered. The following are some of the things that caught my attention, in words and images, and admittedly not an attempt at “fair” coverage. If your favorite topic is missing, wait for the videos to come online at http://www.oredev.org/, or even better – go see for yourself next year!
The theme this year was efficiency, and several of the keynotes and talks pointed out why it’s important to differentiate between efficiency and effectiveness. While efficiency is concerned with how fast or well you can perform any specific task or sub-goal, effectiveness is concerned with how that contributes to reaching an overall goal. They argued that while many of the practices used in agile methods such as Scrum and XP can make us good at “local” efficiency, it doesn’t help if we’re busy building the wrong things, or have a bottleneck somewhere else in the value chain.
It seems part of the current trend among agile thinkers is finding ways to supplement the software development practices from Scrum, XP and other agile methods with core concepts from Lean development, thereby emphasizing not just doing, but also thinking, and not just local efficiency but effectiveness towards the overall goal and value chain. As part of his “Why your agile rollout is failing”, Dan North from ThoughtWorks had a really good phrase summarizing why we need to introduce some systems thinking/theory into software development to create lasting change, instead of focusing narrowly on individual practices: “A bad system will beat a good person every time”, meaning that no matter how much any single person tries, he will always fail if the system around him is bad. So much to learn – so few hours in the day
One of the most interesting sessions at the conference, was what may turn out to be the biggest change in the foundations of software development since OOP (object oriented programming) was introduced. It was a series of talks by Trygve Reenskaug and James O. Coplien, discussing a concept they call DCI Architecture (DCI stands for Data-Context-Interaction, but we’ll get back to that in a minute). I will try to explain it as well as I can, but if you’re interested, or just don’t understand what all the fuss is about, I suggest you read a couple of the articles I link to in the end of this section.
Trygve Reenskaug, from the University of Oslo, is a veteran in software development. As visiting scientist at the Xerox Palo Alto Research Laboratory, he was involved in the development of the Smalltalk programming language, and among other things coined the Model-View-Controller (MVC) pattern in 1978. He has spent the last several years trying to change the way we do model and program software.
Trygve Reenskaug and James Coplien argue that what we have come to know as OOP is not actually object oriented programming, but class oriented programming (a distinction you may start hearing around the Internet), and that it is a poor way to model the users’ mental model of the domain.
Classic OOP is all about objects, but what we’re actually writing are classes. Classes are good at describing the structure of data, but this is not the only thing interesting to the users of the software services we develop: We’re also interested in interactions, such as algorithms and business rules.
Most main-stream programming languages offer no special language construct for interactions, that is, collaborations between objects. They don’t capture algorithms that flow over those collaborations. Instead the interactions of a “use case” or algorithm often get spread across a number of classes, so that you cannot find a cohesive representation of them in code. There is no natural place for the algorithms and business rules to “live” – they are not a first-class citizen – and so they easily become fragmented, and hard to communicate, review and verify.
It turns out that the inability to express interactions severely hinders our ability to reason about the quality and effectiveness of the software we develop:
“Back in the 1960s, we could take the behavioral requirements for a program, and the FORTRAN code that implemented them, and give both of them to an office mate—together with a big red pen—to review whether the code matched the requirements. The overall form of the code reflected the form of the requirements. In 1967, software engineering took away my ability to do this: the algorithm had to be distributed across the objects, because to have a large method that represented an entire algorithm was believed to not be a “pure” object-oriented design. […] That works fine when an algorithm lives within a single object, as might be true for changing the color of a circle on the screen, or adding a typed character to a word processor’s text buffer. However, interesting business functionality often cuts across objects. […] Object-orientation pushed us into a world where we had to split up the algorithm and distribute it across several objects, doing the best piecemeal job that we could.” (from http://www.artima.com/articles/dci_vision.html)
So in order to better express and communicate interactions in code, DCI aims to make interactions a first-class citizen, just like classes. Like the MVC pattern separates concerns between components when building applications with user interfaces, the DCI architecture separates concerns between data and business rules. Another way to describe it is that DCI tries to close the gap between the end users mental model and the way the programmer describes it in code, in order to more easily build the software services that the users need, and facilitate communication and reasoning about them.
The key concepts in DCI are:
Data – this is expressed in terms of classes, but these classes should be dumb. They should express structure, but not behavior. Classes capture what objects are.
Context – can be thought of as a use case. It sets up the pieces we need for the interaction, meaning live objects based on our classes, and assigns them the roles (behavior) that we want them to perform. The roles are assigned on a per-use-case basis, so the same object can participate in different roles and use cases during its lifetime.
Interaction – describes end-user algorithms in terms of roles. Roles capture what objects do. At runtime, classes and roles are combined into objects as needed by the context (use cases). This idea takes a little getting used to, because most mainstream programming languages today are not good at expressing roles separately from classes.
The important thing is that the roles objects “play” are expressed separately from the classes defining data. This makes it easier to reason about an algorithm or interaction, because it is expressed as a unit, separate from the classes of participating objects, and separate from other interactions that the objects may take part in. In other words: Interactions are expressed cohesively, not fragmented across a number of classes.
As mentioned, most mainstream programming languages do not make it easy to express roles, and inject them into objects at runtime. In some languages such as Ruby and Scala, however, it is straightforward. Check out the references for examples in C++, Scala and Smalltalk.
Trygve Reenskaug and James Coplien can explain the concepts better than me, so if you think this was interesting, I encourage you to read more. These links should be a good start:
There were a lot of talks on the .Net track about Microsoft’s newest web-framework “ASP.NET MVC”. ASP.NET MVC is a fully-supported alternative to ASP.NET WebForms (what people typically think of when they say .Net), and have generated a lot of interest in the developer community from people who didn’t like the programming model that WebForms built on top of the basic web application technologies such as HTTP and HTML. The framework is built on the model-view-controller pattern, and Microsoft makes no attempt to hide that it is heavily inspired by Ruby on Rails.
I’ve had the opportunity to work with ASP.NET MVC for the past 4-5 months, and I much prefer it to WebForms for a number of reasons: It is much easier to test, it provides clear separation of concerns (courtesy of the MVC pattern), and instead of abstracting away the details of HTML and HTTP that a developer needs to build modern web apps with AJAX, it provides a set of useful conventions, but with full developer control over page flow and markup.
Microsoft is working hard on the next version of their MVC framework, version 2, and appears to be really committed to it. What’s interesting is also that the next version of ASP.NET, ASP.NET 4, will include a number of changes to WebForms inspired by the feedback they have gotten on MVC. It will now be possible to regain full control over the markup and element id’s generated by WebForms (finally!), and it will be possible to disable ViewState on a page-wide basis. ViewState genocide is now an attainable option… ready….set….GO!
Neal Ford, author of The Productive Programmer had a lot of good tips for individual-developer-level-productivity. If you’re interested in that kind of stuff, you can check out his website where there are a lot of slides, tools and links. On a similar note, Scott Hanselman, Principal Program Manager at Microsoft, gave a talk about personal effectiveness, and recommended a couple of tools including Evernote for keeping notes synchronized across multiple platforms and with the ability to search within images files (it works!). He also mentioned a tool for knowledge workers called RescueTime, which automatically monitors what you do on your computer, allowing you to see when you are spending time on distracting activities. You can find more info on Scott’s blog.
Neal Ford also gave a talk comparing JRuby (a Ruby interpreter running on the JVM) and Groovy (a dynamic language similar to Ruby but with stronger ties to Java). His main message was that they were more similar than different, and that the community should try to avoid another unconstructive “Emacs vs. vi”-style war.
Well, that’s it. Hope you found it interesting. Sharing is caring