Jørn Ølmheims Weblog

JAOO 2009 Sunday tutorials

2009-10-05T09:13:00.003+02:00

The first day of JAOO traditionally is set aside for tutorials. This was also true this year. When I was here two years ago they had the tutorials at the SAS Radisson, but this year the tutorials were held at Triforks new offices and in Musikkhuset.

I had picked out two tutorials, the first was with Dan North on BDD and the other was an introduction to Groovy and Grails with Graeme Rocher. Now I know both Dan and BDD already, and was looking forward to a more indepth look at BDD, while the Groovy and Grails tutorial was a last minute change as my original tutorial with Steve Freeman was cancelled.

Dan started out introducing agile and Domain Driven Design and then went on to describe his particular approach to the agile development process.

Dan stresses that it is important to do enough planning and design, and BDD integrates not just developers but also business analysts and testers in the development process. So what is enough? This will vary from project to project, and this is a key skill to develop for an architect and software developer. Combining analysis and design with agile and lean concepts like "latest responsible moment" and "pull" is the key to making this work. So, doing enough work when you need it, not before and not after.

It is also important to consider all the stakeholders in your project. Everyone who has an interest in your project is a stakeholder, and this will include many other than your sponsor, product manager and your users. Dan splits it into Core stakeholders which are the primary parties mentioned above, and the incidental stakeholders which could include security people, infrastructure people, the people responsible for maintenance of your application and so on. We had a little discussion about users, questioning whether they also most of the time are incidental stakeholders when they themselves had not asked for an application that changes the way they work.

There is of course a lot more to this, and I will do another blogpost on this topic when I get back from the conference. All in all this tutorial was very interesting, and I look forward to sharing this with my colleagues when I get home.

I must say I was a little disappointed with the Groovy and Grails tutorial. As I said I changed to this in the last minute, and I don't know what I expected, but I found out that the couple of hours I'd spent preparing in the hotel room the night before covered most of the tutorial. Especially with my prior knowledge of Ruby and Rails, which Groovy and Grails is quite similar with.

That said, Graeme Rocher comes across as a very engaged and competent guy, and even with the introductory level, there was a couple of cool things to see. The key takeaway for me was to see how Groovy for better or worse is integrated with Java. This makes it less suitable as a pure scripting language due to the increased startup time of the JVM, and more suitable as a supplement to Java for building web application or doing testing or other scripting tasks related to your Java projects. We also manged to get an interesting discussion about metaprogramming going. I really enjoyed that.

Well that is it for day zero. Watch out for more on the next couple of days as the conference progresses.

JAOO 2009

2009-10-04T21:33:00.003+02:00

Finally, the JAOO conference 2009 has started. Been through a day of tutorials as we are warming up to the conference proper, that is starting tomorrow.

The program is looking good as usual, and the quality of the tutorials today has been excellent. More on that in a later post.

The next days promises to be filled with interesting talks and good conversation. Really looking forward to it.

SEAS / DTC conference dinner

2008-06-25T12:30:00.003+02:00

Last night was the conference dinner, and before you ask, yes I feel that today. It was held in an old church in Edinburgh called Mansfield Traquair, which is a really beautiful old building that has been refurbished into a social venue.

We started out with a "wee" glass of champagne as the Scots would say, and then were guided to our tables in the main hall of the church. The food was excellent and the wine was good, but I must say that the entertainment was not quite my cup of tea, with musical numbers between each course performed by "Stars of the West End". Mind you, they were all great performers, but I'm not very keen on all those musical songs. They even managed to mangle Queen's "We are the champions" at the end...

Fortunately, due to great company at the table by Simon Roberts and others, the evening was not a total loss. Thanks guys.

SEAS / DTC conference

2008-06-24T13:01:00.003+02:00

Today and tomorrow I'm in Edinburgh for the Systems Engineering for Autonomous Systems conference. This is a conference on autonomous systems put on by the British Ministry of Defense, presenting the results of research done for mostly military purpose.

Then why am I here? The short answer is that we try to learn what we can about buiding autonomous systems in our own domain (oil and gas operations), and the research has come furthest in the military domain. We were first turned on to this conference last year by our good friends at AOS last year, and have been participating ever since. This year it is my turn.

I hope to learn as much as I can about the wast range of topics presented, ranging from architecture of autonomous systems to sensor utilization and communication.

I really think this could be relevant for our work in the coming years.

Also very interested to hear in the opening session this morning the focus on agility and agile concepts in wast research projects such as these. It is good to see that even though they talk about systems engineering, the focus of analysis and specification has been turned down in favor of capabilities and demonstration.

The beautiful city of Edinburgh

2008-06-23T23:14:00.000+02:00

I'm here in Edinburgh for the SEAS/DTC conference (more on this later), and I must say that this is a very beautiful city. I'm especially taken by the location of the castle on the hill in the middle of the city.

I went for a walk tonight after settling in at the hotel, and got to see the sun set on the parapets of the castle. Very beautiful indeed. You should definitely come here if you get the chance.

ScalaLiftOff

2008-05-24T12:37:00.000+02:00

This has been a most excellent day. Just being in the company of so many great developers is inspiring. If you have a look at the list of participants at the site, you'll understand what I mean. Also, since this was the first community conference on Scala, I'm glad to have been present.

Martin Odersky had a couple of interesting sessions himself, in particular the one where he demonstrated the building of a fully functional spreadsheet in Scala. In fact this is the example from the upcoming book. Following this lead, David Pollack (creator of Lift), show how we could take this spreadsheet app into lift and make it web based. Very cool.

I also participated in an interesting session with Bill Venners on testing in Scala. As you know I'm bordering on obsessed on testing, so it was good to have an overview of what approaches are most common in the community.

Also we had a great discussion about what we can do about object persistence in Scala. As you may know, I'm not very happy with the state of the current tools in Java, and in particular I want to have more of a disconnect between the object layer and the persistence layer, enabling a varied choice of persistence mechanisms underneath a standard api. A number of interesting people was involved in this discussion, including Paul Snively from Lambda the ultimate.

So what did we get out of this first conference on Scala? The answer I feel is in two parts. Personally I got to learn a lot about Scala, and see who was interested in it, as I'm quite new to it. As a community, it was great to see people from so many different backgrounds getting together in support of a great new language. There were language theory guys, like the guys from LambdaTheUltimate, Ted Leung from the Python community, a bunch of guys from the Java community, and I even saw a couple of the Twitter guys there. I guess they are looking for a new paradigm to help with their scalability problems.

All in all a most excellent day. I certainly learned a lot.

Java SE 7 - New language features

2008-05-13T10:18:00.003+02:00

There are a number of new features that has been proposed for future Java releases, and when the spec lead for the new Java 7 release, Alex Buckley set up this talk, I was naturally interested in finding out what had been chosen.

Alex cleverly avoided talking about many of the controversial issues, like closures or no closures, and instead focused on what is good language design and how to grow a language, as well as some of the smaller uncontested features that are almost certain to be included. All in all I thought it was a good approach, and a discusson on closures was done in other talks later in the week.

So, to the language features he presented as almost certain to be included in the next version. The first thing he mentioned was that they were adding the possibility to switch on strings. Today this is not possible (only works with enums, byte, short, char and int), and is really a nice addition to the language.

Next up was the possibility of multi-catch of exceptions. This will be very useful when you have to catch several exception and perform the same task. Today the solution would be to have repeated separate catch blocks and then call the same method for each catch block, while the new proposal allows catching multiple types in the same block.

This code:


try {...}
catch (X1 e) {foo();}
catch (X2 e) {foo();}
catch (X3 e) {foo();}

will turn into this


try {...}
catch (X1,X2 e) {foo();}
catch (X3       e) {bar();}

Connected with this, is the possibility for safe re-throw, where the catch block will now allow re-throw of the same type that was caught. For example

catch(final Throwable e)

that is really NullPointerException for instance will rethrow NullPointerException. Today, the rethrown exception will be Throwable, which is not good.

Modularity in the language is another big thing. JSR 277 proposes a module system that is included in the language to provide similar functionality to what you can get with OSGi today. A core package like com.statoil.jef.core can be a module, and introduces an accessibility level of classes and methods within a module. Will enable both package private and module private. Adding annontations for metadata like versioning of modules. The main advantage over OSGi is that it is in the languague and things like javadoc and javap will understand the module concept. It has unfortunately many disadvantages over OSGi, and the JSR 277 work is only meant as a starting point. More of the features of OSGi are planned to be included in later versions.

Then a demo was given about some of the additions to the Java annotation system. JSR-308 proposes several extensions to the annotation system ment to provide better compile-time type checking.

Allow annontations in other places than declarations.
Pluggable type systems, that you can define to your specific needs, plug into the compiler, and use.

The focus here is very much compile-time verification of the code, and some of this seems like a good idea, but in my experience, this problem has never been so big as to warrant this level of effort. I'm sure that there are systems out there that can benefit from this extra type checking, but to me this seems like too much for too little benefit. Makes the code more unreadable just for catching bugs that might not be there. I certainly prefer to use tools like Findbugs and unit testing instead. My main problem with the presentation was that they never mentioned these alternatives even with a single word.

Alex then rounded off the talk with a discussion about the long term evolution of Java, areas of interest and of non-interest. This is a very interesting part, since it hits at what will be considered for future versions. The main message was (as I understood it), that even if something is not included in the Java language, it doesn't mean it is not on the platform (JVM), with a reference to other languages on the JVM like Groovy, Ruby, Python, Fortress and Scala.

All in all a very enlightening talk.

JavaOne Day Two

2008-05-07T21:33:00.000+02:00

The second day of JavaOne started with a refreshing jog towards the Golden Gate bridge. Thanks to Rune for dragging me out at 0630 for this, it was truly worth it.

We decided to skip the Oracle general session in favor of some breakfast, but the jog ended up making us so late, we barely made the first sessions after the general session.

I was lucky enough to get some fruit and a croissant at Moscone Center just in time to catch teh Script Bowl. This was a wonderfully exiting contest between some of the main developers of the different scripting languages that run on the Java Platform, namely Groovy, JRuby, Jython and Scala. Scala as you may know is not really a scripting language, but it can be used for this type of rapid development all the same.

The contest was divided into three rounds where the first task was to develop a twitter client as a desktop app, the second app was to create a web app, and the third was free-form development. The whole contest was judged by the audience via SMS, with the overall victory going to the JRuby guys. Way to go! Part of the reason for their success was that they had used their community to get the apps done, as well as bringing a very flashy app for the free-form round.

After this session I ended up getting Tom Enebo to sit down with me to do some development on JRuby. We couldn't really find anywhere good to sit down, and ended up sitting in one of the lounging areas with less than perfect wireless access, and thus did not get much done apart from downloading and setting up the latest JRuby trunk on my computer. I guess I'll have to get by on my own when I get home. Hopefully I'll have some time to contribute in the coming weeks. Tom (as well as the rest of the JRuby guys) is a very easygoing guy, and I enjoyed spending some time with him and the rest of the guys throughout JavaOne.

After our little coding session, we went to see Ola Bini's talk entitled JRuby on rails. It was nice for me to see how rails apps could be ran on the JVM with for instance the Glassfish server. Gives an idea of a good way to make use of JRuby.

The final session I attended was a session with Ben Galbraith and Dion Almeir on What's new in AJAX. It was a nice little history lesson in the development of JavaScript and the different frameworks based on it over the years. These two guys are a couple of masters of the art of presentations, and just for that is worth the time to show up.

After the AJAX talk I walked around the pavilion for a bit, and actually bumped into the JavaPosse guys (minus Tor), while I was talking to Pete Moore of Atlassian. They were there to talk to Pete too, so they didn't have too much time for me, but I did manage to discuss some Scala stuff with Dick and Carl. Turns out we are all going to the ScalaLiftOff unconference on Saturday.

Well that was it for the JavaOne stuff, and I joined Rune and Paul and a couple of other guys at a great steakhouse off Union Square for a big steak meal. Very nice.

JavaOne - Day One

2008-05-06T23:21:00.001+02:00

Day one of JavaOne always starts with the Opening General session. This is Sun's showcase for new Java technology. This year there was a JavaFX theme. JavaFX was launched last year at JavaOne, and is supposed to be the answer to Adobe Flex and Microsoft Silverlight on the Java platform. This year they show a whole lot of apps created with JavaFX, and it was a lot of nice looking webapps. For closing, they brought out Neil Young and the announcement of his "collected works" on BlueRay disks using advanced java features.

After the general session I went to the JRuby talk. Not much new for me in the talk, since I've been following the project, but they had some very nice demos of what you can do with Ruby on the JVM.

After lunch I attended Joshua Blochs talk about More Effective Java, containing material from his second edition of the Effective Java Book. He launched a mnemonic for helping to remember when to use extends and super with generic wildcards: PECS (Producer Extends, Consumer Super) which reduces the problem to figuring out which is producing and which is consuming, and that's kind of the hard part anyway. It's a bandaid on a gushing cut. Generics are just not easy. The rest of the talk he spent on how to make effective use of enums, which was good, but didn't really seem that useful to me.

For the final session of the day I chose a session about the new Java 7 language features. There were some interesting things here that I'll make a separate post about later, but one interesting thing that they did not talk about was the closures debate. In stead the Java SE 7 spec lead Alex Buckley talked about the principles and considerations of language design, and at the end there was a long session about adding more annotation for better type safety. Like I say, I'll talk about that in another post.

After this I wandered around the pavilion for a while, looking at the different stands.

Blogging at JavaOne

2008-05-06T11:09:00.001+02:00

I will try to put out the most of the news from JavaOne as the conference proceeds, but this is a very fast paced conference, and I must say that after the conference started today, it looks like I'm going to be very busy.

There are a lot of sessions, a lot of people, and very little wireless access, so I doubt that I'll be able to post my blog-entries until after the conference is done on Friday. Please bear with me.

CommunityOne

2008-05-05T22:36:00.000+02:00

The week of intensive conferencing started today with the CommunityOne conference. CommunityOne is a free pre JavaOne conference organized by Sun. The conference includes several open source topics such as Linux, programming languages, NetBeans and others.

When I was going to the general session, I bumped into Tor Norbye and Dick Wall from the JavaPosse, and finally got to meet them. While we were talking, Ola Bini from the JRuby core team came by, and so I got to meet him too. This was a great start of the day.

The general session was dominated by talk about open source communities and their importance, and finally Sun launched the new OpenSolaris version with the new logo. Also the demonstration of OpenSolaris included a cool demo of the raid capabilities of ZFS (included with OpenSolaris). They had a raid with seven disks running live, and there on the stage put a sledgehammer to one of the disk, litterally turning it into a cupholder. For good measure they also kelled a second disk by putting a drillbit thorugh it. Of course the disks died, but ZFS were able to keep running and when new disks were plugged in, it also rebuilt the content. Very impressive.

After the general session I went to the NetBeans session to check out what were the new stuff in NetBeans 6.1. I have been using NetBeans 6.0 for my Ruby development, but since my experience before this has mostly been with Eclipse, it has seemed a little awkward to me. Now, this new version really seems to be a lot more polished, and I really like the fact that there is much more support for different dynamic languages like Ruby, Scala, Python and JavaScript in NetBeans. I'm definitely going to have a closer look at the new version over the next couple of days.

At lunchtime there was a quick performance by the JavaPosse, where they recorded a live podcast. It was fun to be there for the first time at a podcast that I listen to regularily these days. I really think this is a good group of guys, and they are able to gather all or at least the most important news and then discuss it in a meaningful fashion. I strongly recommend that you have a listen if you haven't already.

After lunch I wandered around a bit and got some coffee, and then it was time to listen to a panel about Ruby. What ruby is doing in a Java related conference, you say? Well, Sun hired the JRuby guys about a year and a half ago, and are now committed to getting Ruby on the Java VM, and I think there is a growing interest in dynamic languages in general and Ruby in particular in the Java community. I'm certainly one of the followers, and I believe that the JVM is a great way to run Ruby in the enterprise, getting imporoved performance and deployability. I will certainly be talking more about the benefits of JRuby later.

Arriving for JavaOne 2008

2008-05-04T23:00:00.000+02:00

So, I'm finally here at JavaOne 2008. I've been lucky enough to get to participate in this years conference, and I will do my best to relay my experiences to you. It was a long trip getting here. I only arrived yesterday, having spent last week in Paris on vacation with my family. I only got back home on Saturday evening, and had to unpack and repack for my trip to San Francisco.

I got to San Francisco yesterday after a gruelling 11 hour flight from Frankfurt. My flight coming in to Frankfurt was late, so several of us had to be ushered through the airport in order to make our flight, but we made it in the end. The flight was uneventful, but too long, and when we finally got to SF, and got through immigration and I got my bags, I boarded the BART train to the city center. Finding the hotel was not a problem as it is right on Union Square, smack in the middle of San Francisco, and when I got to my room, it was already ten in the evening (local time).

I went out for a little walk to clear my head and get some water, and as I returned to the hotel I ran into Rune and Paul in front of the hotel, and we agreed to meet the next day for breakfast. And with that, I was ready for bed.

Architectural decisions

2007-09-28T23:29:00.000+02:00

Yesterdays tutorial really got me thinking about this subject. I firmly believe that the most important thing to document about a software system is the decisions made. A couple of years ago there was a seminal article published in IEEE Computer, called "Architectural Decisions: Architecture Demystified" that argued this exact point.

We have been trying to follow this advice, but we haven't really made much headway, and so when I listen to the tutorial yesterday, some of these old thoughs came back to me, and I started to think that maybe patterns and pattern languages could be a good solution to this problem. The more I think about it the more I see a good fit to the problem.

As it happens, I left JAOO yesterday to go to Oslo for a meeting, and I didn't know, but the topic of this meeting was Architectural Decisions and how we can capture and use them. Talk about coincidence. I cannot really talk more about this at this stage, but suffice it to say that I think we have something here that we can really use that will help us in this endevour. I promise to come back to this when I can.

Patterns-Oriented Software Architecture - JAOO Tutorial

2007-09-27T18:19:00.000+02:00

The final part of this years JAOO for me was a tutorial on Patterns-Oriented Software Architecture held by Frank Buschmann and Kevlin Henney.

To make a long story short this is all about how to design a system by using pattern languages (catalogs of interconnected patterns), and creating a narrative of the different choices made in the process to serve as a documentation of the finished system.

This is an interesting approch to system design. Now, as it happens, Kevlin is sitting next to me as I write this, waiting for our fight to Copenhagen, and so I got the chance to discuss a little bit with him about the background of the material. The two main purposes of pattern languages in software architecture is to aid in design by showing which solution exists to a specific problem in a specific context, and what the trade-offs are, and second to serve as a documentation of the architectural decisions made during the evolution of the system.

I think that patterns and especially pattern languages are an overlooked design tool that we need to start using more.

Both Kevlin and Frank has extensive experience in creating complex systems, and todays tutorial was all about distributed systems, which we also deal extensively with.

Thanks guys, for some real helpful tips and tools.

Almost meeting Joe Armstrong

2007-09-27T17:53:00.000+02:00

I'm really kicking myself. I had multiple oportunities to meet with Joe Armstrong during this years JAOO. When I came in on Saturday, he was actually on my flight. When I got my bags and got outside, there was this guy standing in line waiting for the bus. There was something about him, and he looked at me, and generally seem open to contact, but I was just anxious to get to my hotel, and didn't initiate contact.

Several times over the next couple of days, I kept seing this guy, and thinking that there is something familiar about him, not making the connection. Then on the last day there was an article in the JAOO daily newsletter about Joe Armstrong, and a picture. Of course, then I realised that this guy that I hadn't talked to was Joe Armstrong, one of the creators of Erlang, and that the reason he looked so familiar was that I had seen a much younger version of him in the Erlang video that is available online. This is when I started to kick myself. I managed to miss his talk and his book Programming Erlang was sold out, and now I couldn't see him anywhere. Typical. Oh well, at least I know what he looks like now.

JAOO Day 3 - summary

2007-09-26T21:12:00.000+02:00

Today was the last day of the conference part of JAOO. It's not over, though, as there will be tutorials tomorrow and Friday.

I spent most of the day in the track called Professional Developer. This track was hosted by Bob Martin, and featured a lot of interesting talks. First up was Kevlin Henney, who did a talk called With Economy and Elegance. I always find Kevlin to be an intersting speaker, and this was no different. The only "problem" with Kevlin is that he is so smart and such a fast thinker, that it is really hard to keep up with his ideas. I hadn't seen Kevlin until today, and was wondering where he had got to this year, and I was pleasantly surprised when he came up to me before the talk and said hello and chatted for a while. He told med that he had been travelling alot lately, amongst other places, to Trondheim !!!, and therefore couldn't justify spending the whole week in Aarhus.

Following Kevlin was a talk by Laurent Bossavit that describe the old craftsman societies of France and Europe and how they were structured and how they handled passing on the craft. There is a resurgence of such societies that also include software professionals, and the ideas of craftsmen and their apprentices and journeymen are an intersting way of dealing with training in the software profession.

The third talk of the day, was a chance for me to see and hear Michael Feather speak for the first time. Michael has written many influential articles and books, from the humble dialog, through rules for unit tests to the book "Working Effectively with legacy code". He did a really interesting talk on error prevention, listing several techniques for preventing bugs in code including inspection, design-by-contract, formal notation for specification and test driven development. His point was that we are not using these techniques to the extent we should, and that they all have value and we should use at least one of them. As you may know, I'm a real fan of Test-Driven Development, and prefer that, but I see that something like design-by-contract can have its benefits as well.

The final talk was by Pete McBreen on Software Craftsmanship. Pete has written a book by the same name that I really enjoyed, and I think that looking at software development as a craft has real benefits.

I took the last session off, and just wandered around for a bit, trying to let my impressions sink in a bit. During this time I finally also caught up with Dave Thomas (Smalltalk Dave or Big Dave, not Prag Dave), who I also hadn't seen earlier at this conference. I thought that was strange because he is on the program comittee, and he told me that he too came in only last night, having spent the last couple of weeks on safari in Afrika. Then I ran into Charlie Nutter and Thomas Enebo (the JRuby guys), and ended up hanging out with them looking at the JRuby code. I'll talk more about that in another post, but the thing that really surprised me was that I was able to download their trunk from subversion, load it up into Netbeans, and successfully run the JUnit tests without failures. That shows great dedication on their part.

We all went together to listen to the final panel, where Erik Meijer, Eric Evans, Erik Dörenburg (Thoughtworks) and Diana Larsen (Agile coach) debated about key things they had learned at the conference. The panel was led by Martin Fowler. Interestingly one of their main points was Glenn Vanderburg's talk on The overlooked power of JavaScript, and this really got an interesting discussion going in the audience.

Charlie and Thomas were going to the speakers dinner, and the bus was leaving from my hotel, so we went back there and had a quick beer together before they had to leave. Those two are really interesting individuals, and clearly were commited to making a Java implementation for Ruby so that the rest of us can enjoy Ruby on the JVM. I'm going to look into ways to help them with this. This is something I would like to contribute to if I'm able. We'll see.

So the final day is over. Now only the tutorial tomorrow remains. That promises to be interesting, and I'll let you know how that went tomorrow afternoon.

JAOO Day 2 - summary

2007-09-25T21:10:00.000+02:00

So another intersting day here at JAOO is over. Today I spent most of my time in the Enterprise frameworks track, which at JAOO is not about J2EE or .Net, but rather things like Castle ActiveRecord for Mono (.Net on Linux), Rails ActiveRecord and Grails (Rails imitator written in Groovy).

The morning keynote was held by Erik Meijer. He is currently working for Microsoft, and has brought many influences from more academic languages like Haskell to Visal Basic. He was talking about how he would like the future progress not to require anything new on part of the user. I think he has a good point in that we really should try to make the user experience as hassle free as possible. He referred to a formula for success that says that the chance of success is the perceived problem to solve diveded by the perceived hassel of adoption of the solution.

After that I listened to a couple of presentations on a few different options for persistance that try to break away from the "truth" that OR-mapping is the way and the light. I think it's interesting to look at things like Rails ActiveRecord as an alternative to Hibernate. Granted, ActiveRecord does not nearly provide the same flexibility and power as Hibernate or TopLink and EJB 3, but if it fits your problem, you end up with a much simpler persistance layer due to the convention over configuration principle. Especially with the rise of JRuby, this will be interesting for us. I promise to come back to that in a later post.

I also got to see Eric Evans doing his talk on strategic design, and while I've seen this many times now, it is always good with a refresher. We always seem to forget the bigger picture when developing software. For some reason it is always more tempting to work with some technically challenging problem that with the domain of the users. Eric argues (and I very much agree with him) that our greatest efforts should be spent where it generates the most benefit, and that is the core domain, the main reason why we create the software in the first place.

The final talk that I got to go to (I had to skip the Sun keynote because of the IT run), was a real treat. Glenn Vanderburg talked about the overlooked power of JavaScript. I'm certainly guilty of of underestimating JavaScript as a programming language. Glenn made the argument that this is largely due to it's missbegotten name that kind of leads you to think that it is related to Java. It's not. That's what we've always said, but then we made the misstake of dismissing it on those grounds. I'll summarize Glenn's talk in another post.

So. This day is over. Time is really moving fast here at JAOO. One of the major problems is that there are always at least two, sometimes three sessions you want to go to, then you also want to stay in the halls and hallways and talk to all the interesting people. There is just not enough time. I know I say this every year, but it is true. So frustrating...

Well. Tomorrow is another day.

JAOO Conference party

2007-09-25T09:07:00.000+02:00

Monday night is really the highlight of the JAOO conference for me. I talked about this last year as well, and the first day of JAOO I allways feel a little strange. Then after the Monday night party the mood of the conference totally changes.

I was lucky enough to end up on next to Thomas Enebo and Charles Nutter (JRuby). And as if that wasn't enough. Martin Fowler had decided that he would like to meet them too, and ended up between me and Charles. On my other side I had Jonas Bonér (Terracotta) and across the table was Floyd Marinescu (InfoQ, formerly TheServerSide). As you can imagine it was not booring...

I actually managed to talk som sense and actually got a smile or two (and something I like to interpret as a nod of approval) from Martin Fowler. I talked a lot with Floyd as well, and got a chance to tell him that I enjoy his site.

Charles and Thomas are really interesting guys. They are the lead developers of JRuby, the Ruby implementation on the JVM. In order to do this you have to know both the Ruby language and the JVM really well. I particularly talked alot with Thomas, and found out that he actually has ancestry in Norway.

A great evening.

JAOO 2007 - Day 1

2007-09-24T20:07:00.000+02:00

I'm just taking the time to catch my breath a little after the sessions of day 1 here at JAOO.

It's been a day packed with interesting talks, and when I have the proper time, I will do more detailed writeups of my thoughts, but for now a summary is the only thing I have time for.

The day started with a keynote from Robert Martin, talking about craftsmanship and professonalism in software development. I very much adopt Bob's views, and I will do a detailed post about the points in his keynote. The main message however is that we need to take our craft seriously, and be professional when we develop code. Don't write bad code and write your tests.

After this I went to the Real-world Ruby track, and there were quite a few interesting talks there. First up were the JRuby guys - Charles Nutter and Thomas Enebo. They talked about the possibilities created by a Ruby implementation on the JVM. Quite a few things there really struck a chord with me, and I'll be sharing my thoughs on this in a later post.

After this, Marcel Molena, who is on the Rails core team, talked about beauty in code and what that means. Not really about ruby or rails, but it demonstrates an attitude of the ruby and rails communities which I really like.

Then I went out of the Ruby track and into the languages track for a talk about Scala. I haven't done a post about Scala, but I've fiddled around with it a little bit. In this talk, however, I realized how little I've really understood about the language. Again, a topic for a later post. Brace yourselves, this is only day one.

After this, Rich Kilmer, back in the ruby track, did a talk on domain specific languages and ruby, showing how well ruby lends itself to creating domain languages, in the sense of programs that are readable to domain experts.

The final touch of the day was a chance to listen to Charles Simonyi talking about his experience as a space turist. Charles is a remarkable man, and the father of Word and Excel. He is now a multi billionaire, who lives on his yacht with a crew, and the developers of his company, Intentional Software. His is the origin of the language workbench concept that Martin Fowler is talking so much about these days. Anyway, the talk was about space travel, and it was really great to see, first of all a man who has lived his dream, but also the process of how it all came together. He showed many pictures spanning from the start of the training to the actual mission itself. Great stuff.

Well, thats day one. I'll be back tomorrow with more great stuff. Stay tuned...

Ruby and Rails tutorial

2007-09-23T20:29:00.000+02:00

As I mentioned in the last post, I was in a Ruby and Rails tutorial today. If you read it, you may recall that I said that I probably didn't need it.

Boy, was I wrong...

While I have been using ruby and rails for quite some time, it has primarily been small stuff. A script here, and a small rails app there. Not really enough to get the full grip of the power of ruby. I feel that the tutorial today really opened my eyes to some of the potential of ruby that I really did not understand before.

I've mentioned the meta programming in ruby before, but I haven't really understood it. This opens up a world of possibilities. I really look forward to playing with it.

I also got to talk a little with Glenn Vanderburg in the breaks, and that was very interesting.

The main thing that this brought back to me was really how much I love Ruby as a programming language. And I haven't really understood why I prefer ruby to for instance a language like Python. I realise now that it boils down to the differences in philosophy of the creators of the languages. The philosophy of Guido Van Rossum (creator and benevolent dictator of Python) is that there should be only one way of doing things in the language. Matz (creator of Ruby) has the oposite philosophy that more ways of doing things is a good thing in a language. This is really the key for me. I wan't that flexibility. This is what I love about ruby.

An effect of this is that it attracts a great community, and this community is very focused on producing clear and beautiful code, which Ruby helps you do.

Thanks, Glenn for making this clear to me.

Ready for JAOO 2007

2007-09-22T20:01:00.000+02:00

I've just arrived in Aarhus for this years JAOO conference. I've written before about how much I love this conference, and I hope it's going to be the same this year. There is certainly no shortage of brilliant speakers and interesting talks.

Tomorrow (Sunday), I'll be in a tutorial on Ruby on Rails, which I don't really need, but it'll be good to meet Glen Vanderburg, and on Monday the conference starts proper. Finally I'll participate in a tutorial on Pattern-Oriented Software Architeture

I will try to post my experiences and reflections over the next few days. Hopefully I'll have as good a time this year as I've had the previous years.

Stay tuned...

Documenting conference experiences

2007-09-22T19:51:00.000+02:00

There is a pattern emerging in this blog, and that is that all activity is centered around the conferences I attend.

It shouldn't be surprising, as the primary reason for establishing this blog was to document my experiences at conferences, and a way of conveying some of the experience to my colleagues and friends back home.

The other primary reason is that it's when I'm at a conference that I have the time to reflect on things, get new inspiation by talking to interessting people and last but not least have the time to write it down in this blog.

Well, it's that time again... Hold on for this years batch of posts...

Behaviour-Driven Design

2006-10-09T22:07:00.000+02:00

Finally some time to talk about my most recent pet pieve. Rest assured, the message is just the same as with my rants on Test-Driven Development. But as Dan says: It's all about getting the words right. Dan has gotten this impulse from Domain Driven Design, and you all should know how I feel about that.

So what is the core message: TDD is not about testing, it's all about behaviour!!! Behaviour-Driven Design helps us put the right focus on unit testing. Is this really any different from TDD? Well, not if you do it right. The problem is that the right way to do TDD is often hidden by the word Test. Many people think the main benefit of Test-Driven Design is testing your code, which is natural with this name.

WRONG!

The most important benefit of TDD is that it drives the design, the behaviour of your code. This is what BDD helps point out. BDD is an extension of TDD and Acceptance-Test Driven Planning. Basically it gives a template to use when defining User stories, that includes a context for the story, a benefit that the feature will give and a set of scenarios that can be used for acceptance tests.

For me this puts a required frame around the whole concept of developing quality code. There needs to be a connection between the story with its acceptance criteria, and the tests that we write for the code.

JBehave is a testing framwork that tries to make it easier to write tests the way the should be written. Its Ruby cousin is rBehave (the site is not operational yet, coming soon). I haven't had the chance to try them out yet, so the code will have to wait until another time. Be sure to check it out.

MEGO

2006-10-05T18:36:00.000+02:00

Kevlin Henney tought me a new expression in his talk, that I think it is worth to share:

MEGO - My Eyes Glace Over...

which refers to the effect you see when people are just not getting what you talk about.

People I didn't get the chance to meet

2006-10-05T11:56:00.000+02:00

The problem with a big conference like JAOO has become, is that it is just impossible to get around to talking to all the people you would like to. There were a couple of the speakers I would have liked to talked to. Karsten Lentzsch was here, you know, the JGoodies guy. I also would have liked to catch up with Patrick Linskey from BEA. We have some outstanding questions with them. Still I'm only one person.

The biggest regret though, is not being able to talk to more of the other developers that are here. It is a great chance to meet other people with the same interests. I think one of the problems is that the conference has gotten so big, and being split across the SAS hotel and the Musikkhuset Concert Hall, it gets harder to meet people.

JAOO Day Three - Wednesday

2006-10-04T22:58:00.000+02:00

There was an especially interesting track today, and thats the track called "Back to the Future". This is one of Dave Thomas' brainchild, which allows him to present the things that have been done before. One of his pet pieves is that we need to study the past in order to develop the right technology the right way for the future. And I totally agree with him. That's why I spent most of my time in that track today.

The first session was the introduction to the track by Dave Thomas, a talk he calles "Hot old ideas". In this talk he goes through much of the history of computing and programming languages, basically listing all the languages and given a brief description. You'll have to look at the presentation. The message is: It is dangerous to live in a monoculture! Learn about other languages and technologies to find out what was done in the past, what worked, what didn't and most importantly: WHY!!!

The second talk was done by Guy Steele (father of the Scheme language, together with Gerald Sussman). His talk was about "The history of Scheme". He explained the tradition at MIT that led up to the creation of Scheme, as well as some of the other languages that was created at MIT prior to Scheme. This was very interesting, especially after having studied the Abelson/Sussman lectures, which use lisp (of which Scheme is a dialect).

After lunch I went to a presentation by Dan North and Niclas Nilsson about "Behaviour -Driven Development". As I have mentioned earlier, I have spent some time talking to these guys over the last couple of days, and I must say that BDD really interests me. In fact I think it is a key to doing software development right!! Wow. That's a big statement. I think that deserves a separate blog entry. To be continued.

The last session of the day was a brilliant talk by Kevlin Henney called "The five considerations of Software Architecture". In this talk Kevlin lists five considerations that should be in the back of our minds when we are dealing with software development. The considerations are:

Economy
Visibility
Spacing
Symmetry
Emergence

These are not rules, simply considerations that needs to be taken into account when we are making the decisions that make up the architecture and design of our systems. After the talk, Kevlin told me that he really has a four hour talk on this subject that shows how these considerations really are applicable to any level of development from the business analysis to the coding itself. Since Kevlin is such a brilliant speaker, I'm considering brining him to Stavanger to do this talk for Statoil. I think it would do us good.

The day ended with a panel of selected speaker talking about the future of programming, more specifically how will we be programming in 2016 (ten years from now). Dave Thomas moderated the panel, which consisted of Guy Steele, Ole Lehrmann Madsen, Steve Vinoski, Kevlin Henney and Erik Meijer. In my opinion, the panel really didn't take the subject far enough, and ended up talking about how concurrency will influence future programming. There was also some discussion about how tools and programming languages will evolve. All in all pretty interesting.

After this event I would up in the hotel bar for a couple of hours with Dan North, Niclas Nilsson and a couple of other guys, one of them was a thoughtworker called Ian Cartwright. He's a young guy, but as all thoughtworkers, pretty smart, and actually the substitute for Martin Fowler. Turns out he has co-presented with Martin on a number of occations. This was an enjoyable couple of hours, and we got to talk a little bit about our situation in Statoil, and the thoughtworkers shared a couple of tips with me. They all offered to help us out if we wanted, which is good to know. We also spent some time discussion Aspect oriented programming, and a seed for a new article was sawn. I think it is time to give some counter examples to this AOP thing, since all we hear is that it is useful for things like logging and security. I'm considering doing an article on this even if it means I'll have to read up on AOP a bit. We'll see. It's good to know that these guys, who are unbelievably smart guys, are actually interested in the opinions of a guy like me. Cool.

Common pitfals and misconceptions of Agile methods

2006-10-04T12:01:00.000+02:00

I really found that the insights offered by Jutta Eckstein in her talk yesterday deserves a separate post. I'll list the pitfalls she mentioned and describe them a little.

Too much focus on practices

This means that we implement the practices like daily meetings, test-driven development and so on without looking at the values that these practices are supporting. This is a key point! It is the agile values that makes agile methods work. The practices of for instance XP or Scrum are just there to support and enforce the values. Many people doesn't get this.

Missing result orientation

One of the fundamental ideas in agile methods is the goal of producing a product that is useful to a customer. If we loose track of this and start to focus on just delivering without the link to creating business value, there is no overall goal, and the project fails.

Too many interruptions

Not taking sufficient steps to protect the team during an iteration can be fatal to projects. If the team is not working on a fixed task list during an iteration, or the team is not fully allocated to the task at hand. Scrum helps with this by isolating the team for the iteration and removing other impediments.

Repeat the same mistakes

Do retrospectives and learn from it. The mistake many new agile projects make is that they identify the mistakes in retrospectives, but don't do anything to make it better. Point is to adapt to the things that are identified.

Lacking integration of the product

The importance of integration is ignored or underestimated. Frequent build failures or build takes too long is often a problem. This cannot be ignored during an iteration or sprint.

No overall release plan

Most people plan individual iterations or sprints but some forget that it is the product roadmap or release plan that is the most important.

Agile is for developers only

Agile methods affects the entire the whole organization. Jeff Sutherland (Scrum) argues that the entire organization needs to be organized as a set of Scrums in order to reach the hyper-productive states. He has done this, so he knows what he is talking about.

Common misunderstandings

Agility is ...

... a specific methodology only - NO there are many
... defined by practices - NO actually it is the values that matter
... and undiciplined approach - NO it takes a lot of diciplin to do agile

Agility really is:

Value system
Neither chaos nor dogmatism
Joint responsibility
Culture of change
Continuous learning

JAOO Day Two - Tuesday

2006-10-03T22:13:00.000+02:00

The day started with a really interesting keynote by Guy Steele from Sun Microsystems. He is a language designer and the father of Scheme (lisp dialect used in Emacs among other things). The talk was about an interesting new language under development called Fortress. It is supposed to be a language for the scientific community, and as he said "It is supposed to do for Fortran what Java did for C". By which he means remove the possibility for making the most common mistakes, as well as providing platform independance and multithreading. The goal is to make the syntax of the language as close to mathematical notation as possible, plus they want to grow the type system and compiler, which means that they have to have an extendable type system where the types are not built in but specified in libraries (which you can override with your own implementations of course). Very cool stuff.

Most of the rest of the day I spent in the track titled "What makes agile work?". The introduction was by Jutta Eckstein, and she talked about common pitfalls when adopting agile methods especially in large organizations. I'll do a separate post on that, as I think it is especially important for us in Statoil.

Similarly, Roman Pichler talked about a failed attempt of introducing agile in a company, and why that failed. The main reason was that the initiative came from management, and as soon as the going got though, the management backed out and reverted to the "safe" old ways of the gant chart and the project plan.

After lunch I enjoyed a session with Kevlin Henney, where he talks about the "Six faces of Agile Development". This are six different aspects of agile methods that influence how it works and how it can be implemented. The six faces are:

Practices
Organization
Architecture
Tools
Skills
Attitude

These are all aspects that needs to be considered when trying to adopt an agile methodology. Basically his message (as well as others in this talk): When it comes to adopting agile techniques, one size does not fit all. Be agile in becoming agile.

One of the most interesting talks of the day was by Jeff Sutherland (father of Scrum), on "Making good Scrum". The main message here was that Scrum easily gives you a productivity gain of the factor of 2, just by implementing it correctly. That is just by using product backlogs, sprints, daily scrums and so on. The potential, as shown by Toyota, and numerous examples in the IT industry, is a productivity gain in the order of 5-10 times. In order to acchieve this, the first step is to be really agressive in removing impediments for the teams. This attitude has to go all the way up to the top management. The next steps are really just becomming more agressive in the whole scrum implementation. Also the scrum implementation needs to be done throughout the organization, not just in the software development teams. The most successful companies, like PatientKeeper where Jeff now works as CTO, actually organize all levels of management as scrum teams. These are very cool idea that makes me look forward to the Scrum Master training class I'll be taking with him on Thursday and Friday.

Afther this, Esther Derby, author of many books, among others "Behind Closed Doors - Secrets of Great Managers" (which I recommend all should read), had a talk about "Organizational Culture and agile adoptation". This basically had to do with how different organization cultures influence how you can introduce agile methods. Nothing really new here, but it is important that we evaluate the culture when we try to implement agile methods.

For the last session of the day, I chose Eric Evans and his talk on how Domain Driven Design can benefit from Domain Specific Languages. Eric admits to being a little sceptical to DSLs and their use for core business domains. He thinks it might be just too complicated to build domain languages for business domains. Charles Simonyi from Intentional Software (the DSL guys referred to in Martin Fowlers Language Workbenches article) of course disagrees, and there was a little interesting discussion of this after the talk. Erics position is that the DSL are more useful for the generic subdomains, especially the technical ones. He used examples from time and money to show how a DSL could improve that code.

After the talk we had a little discussion between Eric Evans, Dave Thomas and Obie Fernandez (Ruby on Rails guy working for ThoughtWorks in the US) (I was there too, but contributed very little to the discussion ;-) . It started out with Dave commenting on that the stuff Eric is doing in Time and Money has already been done many times by others, for instance the code in Kent Becks TDD book (actually written for Dave by Ward Cunningham !!!), and that "real" languages has these concepts built in. He referred to technology developed as part of financial applications. The discussion went on to discuss quality of libraries for languages, and that there really isn't any market for this as people does not want to pay for them, which leads to questionable quality in many if not most cases. We also touched upon other languages like Ruby and Ruby on Rails, and Obie was saying that with JRuby we would be able to deploy Rails apps on Tomcat, which would be great because then companies hosting Java web apps can host Rails apps. Then Dave said that that will bring the servers down because the Java VM is not resource sharable, which basically means that each session has its own JVM with resources and instances of shared libraries and the whole shebang. My point in relating this is that talking to Dave (or listening to him) always leaves me with a mixed feeling. The guy has been around for so long, and done so many different things, that he more or less knows as everything works (at least that's what it feels like to me), so while I'm excited to learn this stuff, I'm also bummed out by his disillusioned outlook on things. I guess that it comes at time when we all start being more realistic. I certainly allways learn alot from these discussions.

After this I was quite exhausted after a long day, so I went to get some food and went to bed early. Tomorrow is another full day of interesting talks.

JAOO Day One - Monday

2006-10-02T23:25:00.000+02:00

This has been a most interesting day. Usually the first day, and at least the first half of the first day is pretty slow when you're at a conference. You haven't really made much contact with the other participants yet, and you're just adjusting to the conference.

I went to a few sessions in the Modelling and Design track, and some in the SOA track. Martin Fowler was supposed to chair the modelling track, but unfortunately he was unable to come due to back problems (apparently he has cronic back problems), and it was Dave Thomas (the original, not pragmatic), and he was reiterating the theme from last year (see previous blog) that models and modelling is not equivalent to UML and UML diagrams. Model driven development should be all about human communication and alignment of the model in everyones head. Much in the way Eric Evans has preach to us.

After that I was in a presentation that sounded very promising as its title was Resources, Event, Agents. So I was thinking that we might get some of the SJEF ideas here, but it turned out that he was referring to the REA business pattern, so I was quite disappointed, so I left.

I caught a talk by Beat Schwegler of Microsoft about "Architecting Applications for a changing world". His main theme was to make sure that what is implemented can be directly traced to value for the business. The business model must be mapped to the service model which again should be mapped to the technical model. There are two messages here one is that the service model must reflect the business model, and the other is that the service interfaces should be separated from the underlying (or implementing) technology. This last point is just as important, as this will make sure that the service interfaces are not technology driven.

Gregor Hohpe had a talk about conversational patterns in messaging systems. It was very interesting to see the different patterns of message interaction. This is work in progress from Gregor.

Finally I was fortunately enough to catch a talk by Erik Dürenburg of Thoughtworks about Software Vizualization. Basically this was about creating tools to answer the questions you want answered about your systems. Tool creation is a much vider topic (which I will return to), but in this context it is about analysing source code or running systems to provide answers to questions. Visualization can range from tables of metrics (like the ones we get from JDepend) to graphs of class dependencies. He showed that with very limited efforts they were able to analyse jar file dependencies, using a tool called CodeCrawler to visualize them. They also use a small tool like GraphViz Dot for most of the graphics generation. This is definately something we should use. There is a critical need to monitor the runtime jar dependencies of our system. How cool would it be to build a tool that does this for us.

I intentionally missed Eric Evans sessions, as I've been through that a number of times before, but I met up with him after his talk and we had a chat, and we ended up going to the ending keynote together. This was an inspiring talk by Alistair Cockburn on Methodology and the human aspects of agile methodologies. Very interesting stuff.

The day ended with the conference party, and I was fortunate enough to end up at a table next to Alistair Cockburn (so I finally met him), Dan North, Niclas Nilsson and serval other interesting people. We ended up discussing various agile topics. Great guys to talk to. Dan North is the man behind a new concept called Behaviour-Driven Development which is a step beyond Test-Driven Development. He and Niclas has a talk on this on Wednesday, which I look forward to. We ended up talking and drinking beer for most of the evening, and I had a great time.

I also got the chance to speak with Kevlin Henney, Dave Thomas and Gregor Hohpe. After this, the rest of the conference will be much more fun. This is what I mean when I say the first part of the first day is slow. Looking forward to tomorrow.

JAOO Opening keynote: The Amazon.com technical platform

2006-10-02T11:11:00.000+02:00

Werner Vogels held the opening keynote, talking about the technology platform behind the Amazon.com success.

Amazon.com is really a technical platform, not just a web site. This makes it possible to support other sites, not just selling products from other vendors, but also running their sites and fully integrating their e-commerce sites. This is possible due to an architecture with extensive use of webservices to wrap both functionality and data. The services are split into a set of Foundation services and a set of Aggregator services. All of which are available to customers of Amazon.

Very interesting to see how the need for scalability has driven the development of a service oriented architecture using webservices. The resulting architecture is very close to the SJEF principles that we adhere to.

Kick off for JAOO 2006

2006-10-02T01:17:00.000+02:00

I'm now at the JAOO 2006 conference. This year looks very promising with a lot of great speakers like Eric Evans, Martin Fowler, Jeff Sutherland, Alistair Cockburn, Jutta Eckstein, Dave Thomas, Gregor Hophe and the list just goes on and on.

I'll try to attend as many sessions as I can over the next couple of days. My only regret is that I'm alone from Statoil, as there is just too much for one guy to cover.

I'll keep you posted by things that I pick up during the next days, so be sure to keep your eyes (or RSS readers) fixed on this blog for the next couple of days.

SPE Annual Technical Conference and Exhibition

2006-10-02T01:07:00.000+02:00

I just returned from San Antonio, Texas, where a collegue and myself were fortunate enough to be allowed to participate with a paper on software agents and their potential in the upstream oil business.

The conference was a huge success for us. Lots of interest in our paper, and we learned some things about the state of practice as well. And quite frankly we are not impressed.

San Antonio was very nice, as well. It is a very nice city, and we got to se a lot of it. The weather was nice as well with the temperature in the high twenties, low thirties all week (centigrades of course). We enjoyed the riverwalk, the Alamo and the other sights tremendously. Even got some souvenirs...

Does Java 5 Generics give you better code?

2006-01-28T21:00:00.000+01:00

I think I start to understand at least part of the Java 5 Generics now. I'm really not convinced that the benefit is worth the syntax and reduced readability. I'll try to explain why...

I must confess that I see the point for the simple cases. In Java 1.4 the code for finding payments over a certain limit in a list of Payments would look like this:

    public List findAllPaymentsOverLimit(List payments,
                                         int limit)
    {
        List overLimitPayments = new ArrayList();
        for(Iterator each = payments.iterator(); each.hasNext(); ) {
           Payment payment = (Payment) each.next();
           if (payment.amount > limit)
                overLimitPayments.add(payment);
        }
        return overLimitPayments;
    }

And the bad thing is that we've all gotten used to that horrible casting syntax. With Java 5 we could change this function to something like this:

    public List<Payment> findAllPaymentsOverLimit(
                            List<Payment> payments,
                            int limit)
    {
        List<Payment> overLimitPayments 
                = new ArrayList<Payment>();
        for (Payment payment : payments) {
           if (payment.amount > limit)
                overLimitPayments.add(payment);
        }
        return overLimitPayments;
    }

And that's much better, right?

My problem is with the more advanced uses of this new tool. I'll admit that I haven't fully understood this, but if you want to create code that must accept a typed collection or even worse a map, you'll have to learn the more advanced syntax where

List<? extends Class>

List<? super Class>

This is where it gets hairy, and where I start to think it might just not be worth it. On the other hand, I could leave that problem to the framework makers.

What have I been doing?

2006-01-28T20:37:00.000+01:00

As can be seen from the blog it has been quite a while since my last post. I could always say that I've been busy (which is true), or that I haven't had that much to say, but that would just be excuses.

In these past months I've been busy working on getting more agile practices accepted at work. Ever since our sessions with Eric Evens and his guys, I've been convinced that we must change the way we develop software. The full implications of this did not register until I experienced the talk by Robert C. Martin at JAOO last autumn. Since then I've been devouring everything I could find on agile development, and it has been my main focus. I've also tried to speed up the process of change in my company, but as all big corporations it is slow.

I have, however, also found the time for some coding. God forbid I should forget how to do that. At work I've been busy doing some integration work, so it has been a lot of Java and XML. At home I've found just a little time to play a little bit with Ruby and Java 5 (more on that later).

Well, lets hope the next post doesn't delay as long as this one. See you.

Great tutorial / story on development

2005-10-06T13:15:00.000+02:00

I came across "The Craftsman" article series by Robert C. Martin (Uncle Bob), when I was looking for articles on agile development on the ObjectMentor web site.

This is a series written in monthly installments, with the latest installment (#40) published in the October issue of this year. The series is published in the magazine Software Developer and describes the story of a young developer called Alphonse and his transition from apprentice to craftsman programmer. He goes through a set of learning experiences in each of the articles that improves his skills. It is written in a scifi setting, but this shouldn't put anyone off as it only adds to the narrative of the series. It is extremely well written and (I find) entertaining.

Articles 1 through 31 can be found on the ObjectMentor web site, and the remaining can be found in the Software Developer magazine for those that have a subscription. (Installment 31 was published in January 2005.)

You should definitely check out this article series at is will teach you quite a bit, no matter what level of programmer you are.

JAOO wrapup

2005-10-03T23:30:00.000+02:00

I want to summarize my impressions and thoughts from JAOO this year. I've barely had the time to adjust to the ordinary life and spent the weekend not thinking too much about these things.

Besides going to a lot if interesting talks (not to mention the tutorials), and getting a lot of new ideas from that, the main thing has been that I've met a great many interesting people. This is what is good about JAOO, the speakers are very interested in talking to the other participants, and the schedule facilitates this with the parties and other activities.

I already mentioned meeting Robert C. Martin (Uncle Bob), Dave Thomas and Kevlin Henney. Dave also introduced me to Brian Berry who was his co-godfather of Eclipse. I also had a brief chance to speak with Martin Fowler, but he's more like a rock star these days. Steve Freeman and Nat Pryce of jMock and NMock were also two people I had the pleasure to meet. I especially got to spend quite some time with Steve, and we had quite a few discussions on agile development and computer science fundamentals. Another interesting guy was Adam Bien, an independant consultant from Germany. He has some down to earth views on how to develop J2EE applications, and in his talk called Are Java Fat Clients Dead?, he discusses alternatives to the thin client which are very similar to what we're trying to do with TOPS.

Of course I also talked to a lot of other guys too, and all of the different people have something to add to the conversation. This is what makes JAOO such a good conference, this and the extremely good program and set of speakers.

I hope to be back next year.

Model doesn't mean UML

2005-10-01T22:12:00.000+02:00

Everywhere in the software industry today we encounter the notion of model. Certainly the schedule at JAOO was filled with references to it; it even had a separate track on Model Driven Architecture.

I've always been very sceptical to the ideal that of executable UML and the whole "software through pictures" crowd, because I really think it isn't that simple. The thing is that this has given me a very negative association to anything that sounds like "Model Driven Something", because model has to be a set of UML diagrams, right?

Wrong!

When most well-established speakers and software professionals like Martin Fowler, Eric Evans, Dave Thomas, Andy Hunt, Kevlin Henney and the like, talk about models, they are talking about the mental concepts that we build during our investigation of the problem domain.

The main point is that a model is an abstraction of the problem area or domain for which we build the software. Now this can sometimes be represented by UML diagrams, but seldom completely and never in an absolute way.

So remember this: UML is a communication tool, the model is ultimately in your head (and hopefully in the head of your teammates...).

And whenever someone speaks about Model Driven Design or Model Driven Development, take a closer look and don't dismiss it even if you are (rightly) sceptical of Model Driven Architecture.

Domain Specific Languages

2005-09-28T17:09:00.000+02:00

This is the last day of the conference part of JAOO, tomorrow is a full day tutorial.

Today I've been mostly listening to talks about Domain Specific Languages. This is a notion that kind of is the next step from Domain Driven Development, but also requires something more to quite get there. I think the stuff that we're trying to do with DDD is the closest thing we can get to an "internal" DSL in Java (to use Martin Fowlers classification), without actually making a full-blown DSL.

Now, what is a full-blown DSL? A DSL is a specific syntax, typically for a small, well defined domain, aimed at making the software more expressive. For a more through description read Martin Fowlers article on Language Workbenches. Usually, a DSL, whether internal or external, will imply some kind of transformation into executable code, so in that sense what we do directly in Java is not exactly DSL by strict definition. Even so it is possible to make the argument that it is.

Language Oriented Programming is a term used on the style of programming promoted by the Language Workbenches and similar technologies. LOP uses multiple DSLs to create full programs. This is analogous to Eric Evans notion of different domains within an application.

Another topic that propped up towards the end of the DSL track as a side effect is our use of the word Model and what this means to different people. And that will be the subject of my next post.

The fundamentals

2005-09-28T08:25:00.000+02:00

If there is one recurring theme from all the conversations I've had with people at this conference, it is that it is vital to understand the fundamentals of a problem before we throw ourself into the technology discussions.

How can you choose one technology over another if you don't know the fundamental issues that should guide your decision?

Anyone interessted in the fundamentals of programming languages and language design should check out Abelsons and Sussman's lecture series Structure and Interpretation of Computer Programs.

Ivar Jacobson on Software Agents

2005-09-27T21:32:00.000+02:00

Todays keynote by Ivar Jacobson was entitled Beyond Agile: Smart.

Ivar, of course, promotes the unified process, and especially the practice of making knowledge explicit. This is, he says what makes his process better than agile methods. Dave Thomas commented to me that it is easy to arrive at such conclusions when you don't have to do it in practice.

Anyway, the main thing that got my attention (of course) was what Ivar calles the next thing. His idea is that all the information gathered and formalized by (R)UP is a good thing as long as it stays out of our way and is available when we need it. This is an interessting proposition, albeit a bit far fetched. Ivar is actually talking about (and have started developing) intelligent agents to be responsible for this information distribution. He is using software agents as virual pairs to suggest options for you and learn from what you are doing. How about that?

He envisions a set of tools that will let agents play different roles, such as

virtual pair project manager
virtual pair architect
virtual pair designer
virtual pair developer and so on...

If you are more interessted in his work on this have a look at the website of his company JacZone.

As far as I can tell, this is all foilware, but it is interessting that these kinds of things pop up.

What are the key things with patterns?

2005-09-27T13:38:00.000+02:00

A pattern is a description of a solution to a recurring problem in a given context. The format is not important, but it should include the following sections:

Name
Context
Problem description
Forces and tradeoffs
Solution

This gives us the possibility to name recurring solutions and communicate the different aspects of them, which I think is a good thing that we should do more.

This is also a sensible (and perhaps the only usable) way of organizing any technical writing. If you don't cover at least the three last bullets in that order in your writing it will be very difficult to understand what you are trying to say. Providing a context helps and giving it a name adds to the communicativeity of the concept.

I think we should start looking into better ways of communicating across projects and organizational boundaries. Maybe using a common repository of short presise descriptions of our learning. Adding to this repository should be part of the project end life cycle.

Patterns in Software

2005-09-27T08:14:00.000+02:00

I spent the rest of the day yesterday listening to different talks about patterns. Most of them talked about what has happend since the GoF book (Design Patterns, 1995), and what they think will be the future of patterns.

The track started with a talk from Ralph Johnson (one of the Gang of Four). He gave us his personal take on the history of patterns up to today. After him, Dragos Marinescu from ThoughtWorks talked about the new book Pattern-Languages of Program Development volume 5, where a new collection of Pattern Languages will be published later this year.

Markus Völter then talked about Patterns in Modern Software, Klaus Marquardt talked about how to improve the usability of patterns, and finally Kevlin Henney and Frank Buschmann talked about their take on the past, present and future of patterns.

The main trend in the pattern community is the move of focus from single patterns to pattern languages (interconnected patterns). Kevlin and Frank will publish a new book in Frank's series Pattern-Oriented Software Architecture, volume 5, later this year. In this book they will connect patterns from the GoF book, patterns from Fowlers EA Patterns book and other new pattern languages.

Those of you more interessted in patterns can check out the Hillside Group. They are the group that run the PLoP conferences.

To me patterns is a little bit off in my peripheral vision at the moment, especially when I'm still so geared up from the agile stuff on Sunday. I do however think that there are some ideas in the patterns movement that we should embrace in Statoil as well and start to use for better communication both internally and externally.

Opening keynote: Simon Phipps on Open Source

2005-09-26T10:20:00.000+02:00

Simon Phipps is the Chief Officer for Open Source at Sun Microsystems, which makes him a guy to listen to and with power to change stuff in the open source space.

He talked about what he calls the "Participation Age" to describe the era we're in now. In this era open source is the model for building software. But open source is not enough. Standards must be in place to enable the companies to add value to the open source commons. Many business models are possible around open source.

Also interoperability is required for the users to be able to achieve the freedom that open source is all about for them.

A very interessting talk, that for me at least opened some new perspectives on the open source space.

First day of the JAOO conference starting

2005-09-26T08:30:00.000+02:00

Yesterday was the pre-conference tutorial. Today the conference starts in earnest. Multiple tracks with many different interessting speakers. Today I will mostly follow the Patterns track, so we'll see what kind of ideas my head is filled with tonight...

Fundation for adopting agile methods

2005-09-25T21:14:00.000+02:00

Dave Thomas made this point repeatedly: If you don't have an infrastructure for doing continuous integration and automated tests then you can forget about transitioning to agile methods.

This is good news for us, since we're there and have been for some time. I personally think it has been the right way to go, introducing the foundation and gradually maturing towards a better understanding. I think understanding must be there internally before we can bring in someone from the outside to show us the way. I feel that we are ready now to move further with agile methods and start to challenge our document driven ways.

So, what am I advocating here? The death of PROMIT, certainly not, but it needs to be reworked seriously. PROMIT is derived from PROMIS. Why do we have PROMIS? To manage huge, costly oil field development projects with huge amount of infrastrucure costs. The cost distribution of these projects are low in the specification phase and extremely high once the infratructure starts to be implemented. On these projects it makes sense to have the decision gates to control the costs before implementation, but this doesn't translate into software development.

Software development cost distribution is no different in the implementation phase than in any other time of the project. The cost depends on how many people and how long it runs. The best way to control this cost is to set a date (fix the time), set the teams (fix the people) and let the scope vary within reason.

Scaling Agile Development

2005-09-25T19:32:00.000+02:00

Robert C. Martin (aka Uncle Bob) is a carismatic speaker. He is clear and consise in his descriptions and entertaining in his presentations. I've obtained an electronic version of his talk and can provide this to those who are interessted. Just send me an email.

The talk was split into two parts. The first half of the day uncle Bob spent going thorough the different principles and practices of agile development. In the second half, Dave Thomas talked about the management view. If you don't know Dave Thomas (not the pragmatic programmer), he is the one who managed the Eclipse project starting with IBM Visual Age, so you know he knows a thing or two about scaling agile development.

Bob started off by talking about measurements, under the banner in order to manage we need data. I'm a little embarrased to say that this surprised me, because that means that I have bought into the misconceptions that is going around about agile development that it lacks dicipline. Bob uses story points (or function points) to measure what a team can perform in a week, and then accompany this with a chart showing the remaining function points. With this you can estimate your delivery date. We'll come back to how he comes up with these function points.

He then went on to talk about the fact that in most projects the delivery date is what is fixed earliest, and the requirements never are and never should be.

The problem with the waterfall and other document centric approaches (apart its history) is that it lets you spend a lot of time in the start of the project without producing tangible results. Yes, a requirments document is tangible and sometimes even helpful, but if you spend the first seven months of a project doing requirements and only have three left for implementation it will fail no matter how good the implementation team is. The problem is really that there is no way to determine if a requirements document is done, or when a design document is done. It is however no problem to define when an implementation is done, and hence the problems in the end. Also the practice of putting in the quality at the end is doomed since you rearly have time to do a good job when the implementation fase slips.

He then proceeded to talk about agile development and the different practices or principles in it. Now I don't want this blog entry to turn into a tutorial on agile development, so please follow the link above for an overview of agile development ala Robert Martin.

Finally, Bob, did a programming excercise to show test driven development. He set out to write a bowling scoring game (from his book). The point of the excercise was to show that you will arrive at a different and simpler solution that with up-front design. First we did a collaborative design and arrived at classes like Game, Frame, Roll, and Tenth Frame (to handle the special 3 roll possibility of the last frame). Bob then starts from scratch with TDD approach. Simple creation test for Game, first test case all rolls scoring zero (gutter game), nest test all rolls scoring 1, next test one spare, next test one strike and final test all strikes. This produces one class Game with two methods roll(), which registeres the pins taken down in each roll and score() which very accurately captured a clear bowling scoring algorithm. It was interessting to watch. I actually didn't realize he had finished.

Then we had Dave Thomas come in to tell us about scaling and how to fit in with management. Basically his statement was, give them whatever you have to to keep them happy, generate requirements documents from your source or Fitness cases, generate the plan, fake it if you have to to keep them off your back. Internally teams scale into teams of teams with aggregation of the practices. This comes with the price of longer time intervals between control at the top level, so you need to be able to trust the people running the teams and that they can perform. The team structure can be evolved starting with a few people or architected from the start. Stories at the top level are broken down and divided amongst the team according to the structure. This is not so relevant to us, as we don't have to scale that high, but some of it could be useful.

To sum up, this sessions answered a lot of questions for me personally, and I'm going to take with me these new ideas when we look at how we can take a step furter and improve the way we run IT projects.

Agile Development according to Uncle Bob

2005-09-25T18:36:00.000+02:00

Uncle Bob preaches pure agile development XP style, so those of you who know XP will recognize the practices:

Team level practices:

Planning game
Acceptance tests
Small releases
Whole Teams

Development practices:

Simple design
Test Driven Development
Refactoring
Pairing

In addition there are four intermediary practices:

Continuous integration
Collective ownership
Sustainable pace
Metaphor

An agile project starts with a meeting where the overall project parameters are defined. This most often starts with setting the delivery date, but the date is not always there from the start. In this meeting the overall functionality of the project will be discussed and start to be formalized as stories. Each story represent a function that has business value and that can be estimated and tested.

Bob use a deck of index cards, one for each story. Cards will be added and removed as the project moves on. First each story gets an estimate. The estimates are arbitrary numbers sigifying the relative complexity of a story. These numbers constitute the function points or story points used to plan and measure project progress.

An initial plan is then made laying the stories out in weekly iterations. The initial number of story points in an iteration is a guess and depends on team experience amongst other tings. If a team starts out trying to do 50 points in a week and on wednesday only 22 are done, the customer is promptly told that he can expect only 44 points to be finished by the iteration and so on. When the iteration ends, the final number of points done is counted, put in a graph to show progress and a new plan is created based on this new knowledge. The customer will select the stories that are most important at the beginning of each iterations, and stories can be added or taken away. The project is done when the customer cannot find any new stories that are worth implementing or the delivery date, whichever comes first.

They also do an initial two weeks of analysis into the problem domain. This is consistant with what Eric Evans recommends. This is when the requirement harvesting begins, and this phase could even produce an initial object model. The important thing is that this model will be discarded when the implementation starts.

So when is a story done? This is down to the acceptance tests. When a story passes all its acceptance tests its done. Acceptance tests are automated using Fitnesse or another framework, and run automatically. Ideally they would be written by the customer in Fitness, but most often it will be Business Analysts writing the "happy path" and QA people and testers writing the exceptions and boundary conditions.

How do they handle project slippage? When you measure function points done per week and function points remaining, after around five weeks the number of points done per week in average will be acurate enough for predicting a delivery date. This is still pretty early in the project, about seven weeks into the schedule we can tell the customer that the end date is unrealistic. This is unheardof in waterfall projects, where the norm is to have this information in the end at best when the implementation phase is reestimated. Of course the customers will still complain about slippage, but when you discover this early it's possible to do something about it. Most often the date will stay fixed, adding more people can be an option this early, and it is never a good idea to compromise on the quality. What is left is the scope, and the story deck needs to be reshuffled and reprioritized.

User demonstrations after each weekly iterations and fully functional, ready-for-production releases every six weeks. This means that if the project is cancelled after one of these releases, it will provide value to the customer. Also it allows the customer to terminate the project before the end delivery date if he cannot find any more stories worth implementing.

Whole teams refer to the practice of co-locating the whole team in one room. This includes business analysts and QA people, project manager and testers.

The lower level practices are more known to us and we have implemented most of them in the course of our work with Eric Evans on Domain Driven Design. To me these team level practices are what we need to complete the picture and help us avoid project failures in the future.

Why do we do the waterfall?

2005-09-25T18:08:00.000+02:00

The reason that the waterfall and its spawn document centric, specify then build processes has become popular has mainly to do with a paper by Dr. Winston Royce in 1970 where he began with an ideal proposition saying "wouldn't it be great if we could do this", and basically went on to describe the waterfall model. This is the most cited paper from people talking about the waterfall or similar processes.

What they mostly fail to mention is that Royce went on to saying that he didn't think that this was possible and that he instead recommended an iterative approach. Because what he found is that there will be feedbacks from development into design and from design into spec once you start working with the implementation.

The reason the waterfall turned into such an international hit is that the US Department of Defense asked a tech writer to compile the standard known as 2167, and when that was approved, countries and companies worldwide said "if the DoD is doing it it must be good."

Since then both Royce and the tech writer has, according to Bob Martin, spent their entire time trying to convince people that this was not their intention and appologizing for their errors. Even Royces son has been plagued by this, said uncle Bob.

Robert C. Martin on Agile Development

2005-09-25T10:37:00.000+02:00

I'm really happy that I signed up for this tutorial.

Bob Martin is describing his take on agile development, and in addition to being very inspirational, it really provides some missing pieces of the puzzle for me.

I will write a thorough summary of this later today, but for now I'll just say that this means a lot of changes to how we should run our projects. It effectively means the death of the requirements face as we know it. If we don't do this we will not be able to deliver our projects properly...

I'll leave you with that for now, and hopefully I'll be able to justify this statement in my post this evening.

JAOO 2005 conference has started

2005-09-25T08:21:00.000+02:00

I've just finished my breakfast, and am waiting for the start of the pre-conference tutorials. Registration should open any minute, and I've spent the time getting up and running on the conference wireless zone.

Today's session should be good, it's with Robert C. Martin and Dave Thomas (not the pragmatic programmer, the other one...) on Scaling Agile Methods. Now if you follow this blog you can expect me to rant a lot about agile methods in the next couple of posts, so if you don't know anything about it please have a look at the Agile Manifesto. I really think everybody should know at least what's on there ;-)

If you look at that site and see the names of the people involved, you'll find Robert C. Martin in addition to other well known names such as Martin Fowler, Kent Beck, Alistair Cockburn, Ward Cunningham, Dave Thomas (the pragmatic one, actually) and Andrew Hunt.

JAOO 2005

2005-09-23T22:26:00.000+02:00

It's time for JAOO 2005. There is a lot of interesting talks and sessions, and I want to experience as many of them as possible.

I will do my best to report on the different sessions that I go to and any interesting events that I vitness.

I will attend a tutorial with Robert Martin (aka. Uncle Bob) on agile methods, and definetly the track on Domain Specific Languages on Wednesday. I'm also signed up for a tutorial on JDO by the creator Craig Russel, which should be good. Other than that I'll play it by ear, and pick what catches my attention and time permits.

Interesting individuals @ JavaZone

2005-09-14T23:06:00.000+02:00

One cool thing about going to a conference as a speaker (besides getting the chance to speak in front of people ;-) is that you get to meet a lot of interesting speakers. This year I've met both old friends of mine from school like Knut Magne Risvik, and more famous guys like Kevlin Henney and Tom Gilb.

Also I would like to say that the level of people speaking at JavaZone is generally very high, and for the record I'm now talking about the other guys, not me. The local guys have a lot of insight into the different subjects that they contribute.

The thing about people like Tom Gilb, Kevlin Henney, Eric Evans, Bruce Tate, Rod Johnson and our own Einar Landre is that they have a more fundamental understanding of the problems we face in software development. This allows them to think beyond the mere use of tools or methods, and see the "big picture". Now I'm decidedly nowhere near their caliber, but I find listening to their discussions both inspirational and educational.

Einar and I had a brief discussion with Tom Gilb about his talk on Agile methods and what is missing from them, namely metrics and improvment processes. His talk was unfortunately parallel with mine so I couldn't participate, but I got his slides, as well as a copy of his new book titled "Competitive Engineering" and I'm looking forward to reading them both.

Another thing that strikes me after having met these people is that they are generally extremly pleasant and forthcoming people. I'm just sorry I had to come home tonight and couldn't stay for the second day. Well life's full of choices and I really need to spend a little time with my family now. So JavaZone 2005 is over for me, we'll just have to wait for the videotaped sessions and presentations to become available.

My impressions so far

2005-09-14T12:33:00.000+02:00

The focus in the sessions I've been to so far (Rod and Bruce) has been about the future of Java development. They both talk about new frameworks stretching the Java language and lightweight development. Personally I think this is crucially important.

We need to always consider the right tool for the right job, irrespective of whether it is open source or not, and get rid of our ridgid development practices. We are doing this now, by introducing things like Spring into our development and using Domain-Driven design. But we still have a long way to go...

Our primary challenge is to tailor our adoption of agile methods such as TDD and continuous integration with the PROMIT project model. We need to provide the same level of control that we had before, only do it better and more lightweight. This is a heavy challenge.

Our second most important challenge is to get rid of as much of our in-house developed framework as possible. Our JEF framework is mostly for GUI, and since things are happening here, we need to watch this development and be a part of it. In this process we need to look at how we can do things just a little smarter than we do today. I think aspect oriented programming will have to be a part of this.

If we are able to solve these to primary challenges we will have come a long way.

Bruce Tate - Lightweight Development Strategies

2005-09-14T10:13:00.000+02:00

How do you develop things in a lightweight way.
Java and java development has to get simpler, more reliable and more efficient or it will die.
Java bloat can be good. We need the new frameworks, but we need to be able to remove the deprecated stuff. The success of java and the shrikwrapped product acquisition model is forcing bloat. We need a new software model like subscription.
Don't sell processes, sell principles:

Small, smart teams
Good feedback from customers
Quality
Simple requirements management
Simplicity
Refactoring
Automated unit testing

Management fears agile development because they think it lacks dicipline. Agile is automated testing, continuous integration, refactoring and use of customer feedback. Make sure that you balance out the formal things you take out...

POJO programming model is stretching java in that you add services through the use of Spring and other framework and the dependency injection principle.

AOP are good for removing cross-cutting stuff like transactions and logging from the object. Spring provides AOP with "training wheels".

Strategies for injecting behavior:

Code generation (falling out of fashion)
Byte code generation (runtime - dynamic proxies, compile time - injection)
Source level metadata (annotations)

Java limitations is mainly that it is a rigid language, how to express configuration? Using Java or XML. What about metaprogramming in Java.

Callbacks can be used to simulate closures in places where they provide benefit, like JDBC, transactions. Continuation in Java with things like WebFlow, Rife, Cocoon2 or Lakeshore. More on these topics in the Beyond Java talk tomorrow.

We need code blocks (closures) and continuations in Java.

Spring will replace EJB, annotations and AOP will get us into trouble in some points, but in the end will survive, java metaprogramming will increase, REST wil slowly subsume WebServices (except maybe SOAP), one dynamic language explodes (Ruby?)

Rod Johnson - Trends in J2EE

2005-09-14T09:45:00.000+02:00

Rod Johnson is talking about the current state and the future of J2EE. Main message is that J2EE is in better health than we thought a couple of years ago. Diversity of open source is a strength, not a weakness.
Focus on creating a real object model (reference to DDD and Eric Evans) instead of "fake" objects like transfer objects. The J2EE space is starting to get back to real object oriented designs, but it has taken some years.
A real design pattern is not technology specific.
Agile J2EE :

Acceptance of change
Simplicity
Testability
Rejection of the waterfall

Framework oriented development:
The in-house framework is dead because there are more and more available 3rd party frameworks. Problem is that many of the best developers have been tied up in technical work when you need to use them on the problems of the business domain. Should use as little effort as possible on in-house framework.

Moving back towards a POJO programming model. No API means stability and backward compatibility. Aspect oriented programming and open source frameworks promote this. AspectJ 5.0 will be the definitive AOP solution moving forward.

Aspects will be integrated in Spring.

That's it for the short referendum. Will post an evaluation later.

JavaZone 2005 has started

2005-09-14T09:01:00.000+02:00

I'm sitting here to listen to Rod Johnson talking about Trends in J2EE. This is the opening session for me.

Great book on agent systems development

2005-09-10T22:15:00.000+02:00

I've been reading this great book on developing software agent systsms. It's called "Developing Intelligent Agent Systems: A practical guide", and is written by Lin Padgham and Michael Winikoff of the RMIT university in Melbourne Australia.

This book details a methodology called Prometheus that organizes the design and development of agent systems. What strikes me is that this the elements of this methodology can easily be transferred to other types of software development, especially enterprise applications.

The starting point and central theme of the Prometheus methodology is to identify System goals from Scenarios, and then refining these goals into functions or capabilities. This is a simplified description, of course, but this maps to any fairly complex software development where you need to keep track of the overall functionality of the system in a structured form.

Apart from this, the book has a brilliant introduction to software agents, so it's well worth a read for that alone.

Language as the enabler for thinking

2005-09-09T20:24:00.000+02:00

Yesterday I was involved in a very interesting discussion about language. We're currently doing a workshop with one of the guys from Eric Evans company Domain Language on implementing the Domain Driven Design methodology in our organization.

A couple of us went out to dinner during which the discussion naturally touched upon language and thinking. Part of the reason for implementing your code using the language of the domain, which is the core of DDD, is that it enables you to think more clearly about the problems in this domain. As it turns out, research with children points to the same thing, that their ability to think and remember things are related to their language skills.

I think this is an interessting input into discussions about using Domain Driven Design, and not to mention the new wave of discussions about Domain Specific Languages. There is going to be a separate track on DSLs at JAOO in Århus later this month, so I'm looking forward to following that .

JavaZone 2005 - Oslo

2005-09-04T22:59:00.000+02:00

I'll be attending JavaZone this year. I will give a talk about Software Agents and how they can be used to build more dynamic enterprise applications. If you're going to JavaZone this year and are interested in the subject please check out the presentation outline.

I hope a lot of you drop in and listen to this talk, as I feel this is an important topic for current and next generation enterprise applications. Software agents is in itself a very interesting subject, so I don't think you'll be disappointed.

Java 5 Generics

2005-09-04T22:31:00.000+02:00

I must say that I was a bit surprised when I read about Bruce Eckel and his problems in getting the grip on Java Generics in his blog, where he's saying that even he finds Java 5 very complex and has spent a lot of time writing the new chapters on Concurrency and Generics for Thinking in Java 4th ed.

I'd heard so many good things about this before and so I decided to check this out for myself. I readily admit that the prospect of getting rid of these incessant casts in iterators gets me a little excited. But when I started out using Java 5 on this little home project of mine, I kept getting dragged of into side issues with this thing. Maybe its my design, or the fact that I'm just starting out with generics, but there are so many little things to watch out for that it is easy to get lost in the technical issues of it all.

I'll admit that I haven't really spent enough time to form a solid opinion on this, but I don't feel like it is coming together as well as I'd hoped. Will report more once I've had some further experiences.

My first entry

2005-09-04T22:16:00.000+02:00

This is my first blog entry. I'm a late adopter of this form of communication but I've been following the scene for the last year or two, and have decided that I want to be a part of it.

My main interests at the moment include Agile methods with special focus on Domain Driven Design, Event Oriented Architecture, software agents in addition to my love for programming (mainly Java). Recently I've started to learn Ruby, and I must say that I like what I see. This is cool.

Well, I guess I'll be putting in my two cents from time to time about these subjects, so look out. I also plan to use this space to report my intake from any conferences I might attend.