My email address is . More on the contact details page.
A short biography is available on the biography page.
I have worked in the field of enterprise applications for more than ten years now but I have not entered what some people affectionately call the post-technical stage; the stage where the newest IDE on your laptop was released several years ago and your “recent documents” list is full of PowerPoint presentations and UML diagrams. I see this as as a good thing and, actually, made a conscious decision that I want to remain near delivery rather than becoming an ivory-tower architect. Luckily, working for ThoughtWorks, practicing agile development on all projects, this hasn’t stopped me from doing architectural and strategic work at the same time.
Over the past few years it has become more and more apparent to me that the success of a software project rarely depends on choosing a certain development platform or specific technology, as so many vendors and language fans want to make us believe. In my opinion, the main causes for problems are on the one hand inappropriate development processes that emphasise big upfront design and force businesses to lock down requirements early and on the other hand technical implementations that are high on accidental complexity. The latter is still quite common more than twenty years after Fred Brooks wrote his No Silver Bullet paper.
It is true that developers are turning increasingly to incremental development and evolutionary design, as Brooks suggested, and a lot of accidental complexity that was caused by low-level programming languages has disappeared, but unfortunately the industry overshot the target and now accidental complexity is caused by ever more elaborate frameworks and products that over-abstract problems, causing development teams again to wrangle with complexity that has nothing to do with the actual business problem.
As a consequence I have become quite interested in simple architectures and software visualisation as a way of exposing accidental complexity. This interest is reflected in the talks I’m currently giving at conferences.
On a technical level I have spend a lot of time with post-J2EE architectures in Java. In such architectures the focus is on a strong domain model expressed as Plain Old Java Objects (POJOs) hosted by lightweight dependency injection containers. This greatly improves testability and maintainability, and I have reported some of my findings at the JAOO conference, here and here. On the .NET platform I am following Microsoft’s latest addition, F#, as the pendulum seems to begin swinging away from a complete dominance of object-oriented programming.
How did it all begin?
The very first piece of software I created was a little game that I wrote in Basic on the Commodore VIC-20. That was in 1983. I got the first taste of real software development in 1987 on an Atari ST when I stopped hacking assembly code directly into memory (using a “monitor” application) and began to work with an IDE, a C compiler and a debugger. This was also my first exposure to windowing systems. Have a look at a this screenshot of the Turbo C IDE on the Atari.
In 1990 I started Uni where we learned Scheme using the legendary SICP book. It was a bit different at first but in retrospect I think it was a great way to understand fundamental concepts, and to realise that programming should be enjoyable, which is something that is often forgotten. Of course, we also got accounts on Unix machines, the lunchbox Sun IPX for example, and we were connected to the Internet! Not that we could surf, the Web hadn’t been invented yet…
A year later I got a student job at a company that wrote software for NeXT computers running NeXTSTEP and at that point I knew I didn’t want a beige lunchbox but a black pizza-box! It was UNIX, it was fast, had a great user interface and futuristic applications. Check out this screenshot of NeXTSTEP in 1994 and note the emulator window in the background running the then current version of Windows.
However, the best of it all was the development environment: It was all object-oriented and late binding with a great UI toolkit, which in my opinion was so much better than most of what came later; and this decidedly includes Win32 and Swing. (As a side note: There is a connection between some NeXT enthusiasts and Swing but a lot got lost on the long way to Netscape’s IFC and later JFC.) Interestingly, the architecture of the NeXTSTEP UI kit has not really changed in more than 20 years and now forms the basis for all new Mac OS X applications.
In 1995, while still writing my thesis, I joined another small IT consultancy that was also devoted to the NeXTSTEP environment. Happiness did not last all too long, though, as we had to abandon our two-tier applications with their beautiful and rich user interfaces and moved back into the future with request/response web-based 3-tier applications. Another piece of roadkill during this time, at least as far as my commercial career is concerned, was Objective-C, the programming language at the heart of the NeXTSTEP platform. We all moved to Java and, given the state of the platform and the tools at the time, were sorely disappointed. Then again, it was probably a bit ambitious at the time to have a Java Applet do RPC with some middleware. On the positive side, the NeXT heritage provided us with an excellent application server, WebObjects.
Late in 1999 I gave up all resistance and fully joined the internet hype. And I guess, a few months of TCL development for the Vignette CMS give you a sense of appreciation for Java and J2EE. (In all fairness, Vignette have moved on since those days.) It was a great time and we delivered many beautiful B2C websites; even arts projects. In any case, we were in the new economy, the dot com bubble. Soon, I realised that this was not meant to last and I found myself having to decide between small web shops with cool but technically boring projects and IT departments of large corporations. A decision I could not make as I love technology and the drive and excitement of small companies.
After a break in 2002 a good friend of mine introduced me to the solution of my dilemma: A boutique consultancy that specialises in the “heavy stuff”, a company that runs a Geek Night. And this pretty much brings you to what I’m up to now.