SpringOne 2009: The side talks…

bulbThe most interesting thing about conferences (besides having the chance to hear about something you simply missed while being distracted by your normal daily workload) is that you can meet all kind of interesting people. Well, actually you can all kind of people and some are more interesting than others. But if you manage to identify the particularly interesting people and get to talk to them about your and their interests, this really can widen your horizon (not really surprising, but I need to remind myself of that every once in a while when I sit in a particularly boring or uninspired talk). Yesterday night we explored Amsterdam and actually had a very interesting discussion about what we perceive to be major problems of the software engineering discipline as a whole – not with someone new we met but with a good old acquaintance we hadn’t met for some time. The night ended after 2pm in the morning but the resulting 5 hours of sleep were a tiny price to be paid for the great evening – both intellectually and socially. Thanks, Nils! So what did we discuss…?

We both (actually, we three – Daniel, a good colleague was also with us) are in the business of engineering software and we again and again notice that all companies and technology vendors seem to continuously struggle with the small things (besides struggling with the big things like SOA – but the small issues never seem to end).

The small issues arising again and again from my point of view can be summarized like this:

  • Technology continues to evolve at an amazing speed and it becomes harder and harder to keep up to date.
  • For newbies to the job this is even more difficult – they are more and more overwhelmed by the number of technologies and architecture styles they need to understand. Just look at one of my favoured topics – web development. Ten years ago in the Java world you had to learn HTML, Servlets and JSP and you probably wouldn’t even encounter model-view-controller patterns. Maybe you world learn Struts, probably you would need to understand JDBC and SQL but that was about it. If you were in financial projects or working with insurance companies, you probably also would see a bit of Enterprise JavaBeans… but maybe not considering the fact that EJB technology did not really work that well around 1998-99. Today? Well, choose one from many web frameworks (Wicket, Spring Web MVC, JSF, Tapestry, Struts 2, Grails, Rails, Spring Roo, GWT, JavaFX, Flash, Silverlight  etc. pp.). Learn (X)HTML, JavaScript, CSS and probably Dojo or jQuery thrown into that pot. Then add architectural styles and patterns (MVC, command patterns, services, factories, repositories, DAO, multi-layer architectures). Add in communication styles (HTTP, Web Services, REST, AJAX) and associated protocol styles (JSON, ATOM, RSS, XML). Do not forget sidelines (XPath, XSLT & co.). Oh, and don’t forget persistence (JPA, Hibernate, JDBC, iBatis, Spring Batch, etc.). Mix in language fads and hits (Java, Groovy, Ruby, Scala, Erlang, Haskell, …). Finally shake and stir and combine with infrastructure frameworks like Spring. And we haven’t even touched on methodology (TDD, BDD, agile methods, Scrum, …). You won’t need all this at once and most of us never will pick up indepth knowledge about more than a couple of those technologies but even the choice about where your intellectual investment is going to go is rather difficult.
  • Then you will face the challenge of keeping up. All these technologies and methodologies evolve at the same time – some faster than others but almost all of them very rapidly. It is both very hard to keep your own skills uptodate – and we haven’t even talked about how difficult it is to keep your implemented solutions even somewhat up to date (most frameworks out there do not address technology evolution as a topic – actually quite surprising for me).
  • And then there are the applications themselves – they keep getting more and more complex because more and more systems are connected, exchanging complex data, acting and reacting. While it’s sometimes possible to quickly stick something together (mashups & co.) it still seems to be rather costly to maintain solutions – and this issue does seem to improve right now.

And suddenly you face pretty big issues. Yesterday night we really started wondering where all this is heading – since many day to day problems still are rather trivial CRUD problems – but the amount of technology thrown at them is amazing. Especially since computer scientists seem to be very eager to again and again invent the perfect solution – even for trivialities. And the “not invented here” syndrom still seems to be dominating the industry.

After a long discussion (and some good drinks) we concluded that one of the basic problems is the following:

  • Many of the problems we are facing are rather problems of craftmanship than of creativity and art.
  • Computer science as a discipline still seems to favour a very artistic approach to problem solving (even in science), striving for perfect solutions.
  • The majority of “normal developers” out there is neither interested nor talented enough to engineer great artistic solutions on the spot – some never will. This becomes particularly obvious when analyzing the rather high investments required to get job newbies up to speed (which is not their fault, mind you).

We concluded that computer science must accept that many problems are those of simple craftmanship (e.g. the many CRUD solutions out there) which neither require new programming languages nor new frameworks since the essential underlying technical questions have been solved for many years. We just need to standardize simple tools for these domains instead of inventing overly generic and super-powered tools that in consequence do not help to solve any specific problem with great efficiency. And we need to change our education system to more clearly differ between craftsmen and artists. Artists will plan, design and implement the power tools (but we need only very few of them), craftsmen will work with customers to understand their problems and provide practical solutions. Or the artists will provide guidelines and enforce them, so tha craftsmen can work in a well defined environment that protects them from leaving established and productive tracks.


Reading this once more and thinking of all our typical IT marketing this is nothing new… everyone seems to be doing exactly that (or at least says so). And why are conference topics pretty concerning the issues mentioned in the beginning pretty constant and the search for the next perfect wonder technology continues?

Wonder for yourself 😉 Something is wrong there… I have an opinion about how to tackle this but that’s a topic for another blog entry (or three).

Comments are closed.