« Relive the best JAOO Moments | Main | Michael Koziarski (Rails core team) interview »
Impressions from JAOO 2008 (3)
By Jan Reher | October 4, 2008
By Jan Reher, Senior Developer, Systematic Software Engineering A/S. jan.reher@systematic.com.
Wednesday, October 1, 2008
Guy Steele and Richard Gabriel: 50 in 50
It was theatre. It was beautiful. I will not attempt to give a summary.
For those open to the message, it should serve to remind us of our place in history.
Kevlin Henney and Frank Buschmann: Five considerations for software developers
It was kind of fun to watch these two seasoned performers on stage together. I think they tried hard not to upstage each other, and it worked most of the time. But I’m not sure why the presentation had to be performed as a duet. I would have preferred a sequence of solo arias.
Despite the occasional shouting matches, the message was clear. Kevlin and Frank presented 5 subjects they were very careful to present as considerations. Not rules. Not measures. They were meant as starting points for discussions, not conclusions. I like this approach to giving other people advise, and I like that it is stated explicitly. But, a small doubt: If this is the preferred form for presenting advice to an intelligent and well-educated audience, why didn’t Frank use the same form yesterday when he told us how to do architectural reviews, and why didn’t Kevlin do the same in his next talk? Perhaps simply because this form was appropriate for presenting this topic.
But back to the contents of the talk. To put it shortly, developers should aim for economy and elegance in the solutions we produce. “It works” is not enough.
Economy. Be direct. Be simplistic. Don’t be clever. Reduce clutter.
Design for use, and then, perhaps, later design for re-use. Consider Ward Cunningham’s question “What is the simplest thing that could possibly work?” Note that Cunningham did not phrase this as “Do the simplest thing that could possibly work”. The question is a far more subtle and useful (and difficult) piece of advice than the precept. By virtue of it being a question, it can start a process. I have myself committed the sin of blindly following the precept, thinking that that was what Cunningham said, and have even taught others to do the same. That will have to stop now. Thanks, gents.
Visibility. Aim for expressiveness in your code. Make your code read as literature (A point made by other presenters at this conference, most eloquently by Sam Aaron. Oh, and by Donald Knuth. No, he was not at JAOO. Maybe next year?) Focus on roles, not implementation. Make the code express “what it is for”, not “what it does”.
The domain model should be 1-1 with the program. Make your mental model visible in the code (I was taught this at university. Some teachers told us that this is the Scandinavian approach to object-orientation. Apparently that no longer holds true, if it ever did.)
Use types that represent real-world concepts, not strings and integers. Hide these, and use them only as means of representing real-world concepts in programming language text.
Spacing. Separate concepts. Decouple. Prefer composition to inheritance. Introduce locality so that the reader (literature, again) can understand things locally.
There are several dimensions of locality. One is frequency of change. So isolate those bits that change frequently from those that are relatively stable. (See also presentations by Coplien and Aaron)
Symmetry. This topic mostly focused on a criticism of the Abstract Factory pattern as popularised by Gamma et al. I missed a broader perspective on symmetry. But the criticism is worth repeating: Abstract Factory is asymmetric, and therefore it is flawed. The client is relieved of the burden of creating an object but gets no help when it comes to disposing of it. And garbage collection is not the solution since it only deals with memory. It is not so trivial. It is about resources and life-cycle management.
Emergence. (Ah, one of my favourite concepts) Emergent solutions are elegant. Think of workflow patterns like Pipes and Filters, or Leaders and Followers. They solve complex scheduling and resource allocation problems without having any explicit overall coordinating agent. Coordination and optimisation are emergent properties of the way components interact in these patterns.
As a simpler example, polymorphism is usually preferable to using explicit if-statements. Coplien’s talk took this theme one step further and argued for compile-time polymorphism (also called metaprogramming) over run-time polymorphism.
Conclusion: I got no surprises from this presentation. That does not make it irrelevant or trivial to me. It reinforced some themes I have already learned to appreciate, and gave me new perspectives on others.
The five considerations are in tension and in support of each other. (Is there a scent of patterns here?) And if they do not fit your needs, you are encouraged to roll your own. It’s a process, not a final form.
Kevlin Henney: A programmer’s dozen
13 concrete recommendations from a seasoned programmer. I suppose that’s reason enough for the rest of us to have a go at them. Here they are:
0. Prefer code to comments. Compilers and programmers tend to ignore comments
- Follow a consistent form. Strunk and White’ guidelines also apply to code. Avoid implementation-based naming, use role-based naming.
- Contract by example. A unit test is a contract by example at the unit (usually class) level. You cannot test member functions in isolation. If you insist regardless, your test will not reflect any realistic usage of the class under test. Instead, driven by requirements, write unit tests that enumerate the requirements.
- Express independent ideas independently. One class, one responsibility.
- Encapsulate. This is not just “make data private”, which is trivial. Consider usage: Provide an interface that allows or simplifies usage on the client’s terms. Do not expose implementation. Maintain the invariant.
- Parametrise from above. Beware of hardwiring from below, e.g. by exposing constants in lower layers for upper layers to use or, worse, depend upon. This rule is a superset of the dependency injection principle.
- Restrict mutability of state. Most bugs result from incorrect state change. Return new objects instead of mutating existing ones.
- Prefer symmetry. “When in doubt, make it symmetrical”, quoth Cristopher Alexander.
- Sharpen fuzzy logic. Know your predicate calculus and your Boolean operators.
- Go with the flow. Block structure favours the folding-away of code, mentally or using a tool. It also makes refactoring doable.
- Let the code decide. Deal away with explicit control primitives: if, switch, for, etc. Use polymorphisms and visitor patterns.
- Omit needles code. Having a “getter” does not imply that you must have a “setter” (The symmetry rule above said “prefer symmetry”, not “insist on symmetry”). Remove things that go out of use.
- Unify duplicate code. Reduce clutter. Clean up. Refactor.
Petri Haapio: NokiaSiemens Network and agile development
This was an experience report from one of the people who was key to moving (parts of) the 50.000-strong organisation of NokiaSiemens Network (NSN) towards agile development. Agile is a process, not a thing, and they are still on the way.
So the talk was yet another gem of empirical knowledge. It did not tell us how go agile; it told us how somebody went agile.
I had heard about the Nokia Scrum test before, so it was interesting to hear the story from a man who was deeply involved with the process improvement work that originated this test.
So suppose your organisation want to embark on this “agile” thing. Petri gave us a long list of tricks and tips that might help on the way. I will repeat some of them:
First, a top-down approach would never work in an organisation of 50.000 people. Bottom-up is the way. Start locally, get some experience, share it, invite others to join but make it VOLUNTARILY. Early on they adopted a rule of no enforcement of adaption.
And keep the focus. Change is possible but it takes time.
Share information as you progress. Wikis are one useful tool.
NSN set up a ten-person change team. These went out and helped projects in their own contexts. External consultants were added where applicable.
The team worked agily itself. Every Monday morning they held a three hour meeting (kinda long, isn’t it 
with this agenda:
- Report what you learned last week
- Collective reflection on that
- Conclude and plan for the next week
Once you decide to be able to deliver functionality every four weeks, it changes everything for a team. And then the team needs help, and new techniques, and new tools.
Office layout matters. The team needs to be co-located to become a team.
Visualisations become vital. Information radiators must be present and up-to-date. You must accept putting your dirty laundry out for everyone to see. Task boards and burn-downs were constructed using paper, pens and glue. The build server state must be visible at all times.
Measurements become more important than ever. But the old measurements that NSN’s various departments were used to getting from projects made no sense any more. This confused said departments.
In the early stages they faced some problems with some middle-level managers. There were those who were hostile towards the initiative; these had to be facaded away so that all the information they saw coming from the agile projects looked the same as ever. And some managers basically said “Oh, go and play with this for a while, if you must. It will fail anyway.”
Robert Pickering: F#
One of the nice things about .NET is that it from the outset was designed as a language-independent platform, unlike the Java platform where until recently you could only write code to it in Java. But then again. C# was designed along with the .NET platform and promoted by Microsoft as the preferable .NET language, and VB is really just a subset of C# rendered in an ugly syntax. And C++ on .NET has an ill-deserved bad reputation as being only suitable for writing adapters for legacy code. So outside the research lab, the seeming freedom of language choice has mostly been that—a seeming.
Perhaps F# will stir things up a bit. F# is a relatively new programming language for .NET originating in Microsoft’s research labs. From the next version of Visual Studio, it will become a full member of the official set of languages Microsoft provides for the .NET platform along with C#, C++, and Visual Basic.
F# is intended to amalgamate object-orientated and functional programming. Other languages have done this before. Even on .NET. Nothing New here.
F# is a bridge. It has the same core syntax as Ocaml, meaning it harks back to ML, and it has the same object model at the .NET CRT, meaning that the full power of .NET and the .NET libraries (written in any .NET language) are available to programs written in F#. That’s two Old Things, combined together. That does not make it New. But it may make it Useful.
It is also interactive, meaning that the programmer can dispose of the write-compile-run drudgery, and just throw code snippets at the computer, which will execute them immediately. This is Old Thing too, but I have missed it.
I think F# is the next programming language I will have to learn.
