The Microsoft-Nokia deal may be a great opportunity for Finland’s startup scene

There’s been so much said about how bad an idea the acquisition of Nokia’s Mobile device business is and why it will most probably not work out well. I don’t have much to add to all this, apart from how sad the news are. Microsoft is not gaining anything from the deal to increase the Win 8 Phone market share, but they’ll destroy a complete culture and make loads of Know-How spread all over the world.

This little gem on GIGAOM, however, puts the deal into a totally different perspective and I thought this is an excellent way to look at it:

If there is one upside, then I do believe that this just might be the best thing to happen to Finland and the Finnish startup scene. A lot of the talent draining out of Nokia will look for new opportunities in their areas of expertise — radio engineering, manipulating sensors and embedded systems. If anything, this is Finland’s big opportunity to become the epicenter of the Internet of Things.

So maybe there is even good news in these bad news…

Schauderhaft: Don’t Rewrite Your Application

I’m probably the last to find this excellent piece on Jens Schauder’s Blog called Don’t Rewrite Your Application. It’s not only worth reading, but also thinking about it and memroizing it. There’s almost never a really good reason to rewrite a reasonably-sized business application. The effect will very often be a the loss of a lot of money and probably never an application that is substantially better than the one it replaces:

  1. Whatever you might think of the code base and the developers that created it: They weren’t stupid nor evil. So chances are the results of your work will look just as ugly in two years from now.
  2. You don’t know the requirements: Part of the reason legacy code bases are ugly is that requirements change. There is no reason for you to assume this won’t stop.So chances are the results of your work will look just as ugly in two years from now.
  3. You don’t have the time: As long as the rewrite isn’t done, you’ll need to maintain and probably evolve the current application. If it is of any importance, you can’t ignore it for the months to come. If you can you should do so without wasting your time with a rewrite.

So true. In the Smalltalk world, we’ve seen all sorts of craziness in that field. Some customers spent literally millions of Euros into this lesson. Here’s a possible solution:

Instead of rewriting the application refactor it. Learn to properly estimate the effort needed for implementing new features in a clean way. Add some time to make the code immediately around that new feature a little cleaner as well. Use that as estimate. This way the application will become a little cleaner with every update.

Boy, how right he is!

If you know the requirements of your system, still have some skilled developers on the team and need to move the application further, it’s almost always better to invest in existing know how and the team to improve their skils in techniques like Refactoring, Unit Testing and Code Management. Combined with Continuous Integration you can accomplish several things:

  1. Improve an existing system with new features in little time
  2. Lay the grounds for easier addition of features in the future
  3. Come back to the pace of innovation that your project once  had
  4. Save a lot of money and frustration (and if you are a CTO or in upper management probably even keep your job and feed your family)
  5. (Re-) Motivate some of your most valuable team members who’ve lost their believe in a future of their projects a long time ago (you should NEVER underestimate this aspect!)
  6. Motivate new staff to come to your project as it promises to be fun, effective and respected within your organization (Have you ever heard or said the sentence “we can’t find Smalltalk developers”? – maybe it’s your fault because you scared people away from the project or technology for years for no real reason…)
  7. Surprise your users with new features instead of apologies for not delivering
  8. Have fun!

Should young programmers start in the green or in the brown field?

Many people view software maintenance as tedious, boring and ultimate penalty rather than a challenging and interesting job. And in fact, maintaining an old body of code can be painful and depressing. There’s so much to make you bang your head against the wall: bad programming style, wrong design decisions, stupid bugs and lots of areas where you simply don’t understand what for or why the heck somebody wrote such terribly bad code.

On the other hand, changing existing code, improving it, adding functionality to a running system can be fun and very satisfying. And there’s even some chance that there are hidden gems in old code. Something you can learn from people with lots of experience and good coding habits. It’s a challenging job to try and find out why certain deicisions were made as they are, and very often you’ll find out there once were good reasons for why something was done in quite some complicated fashion rather than in an obvious way.

So constantly being on an edge between breaking code and improving an existing system can be seen as dangerous and rewarding at the same time.

Being a young programmer, stuffed with only fresh ideas and little useful advice on how to write real software, it is surely a good thing to be put into a team with experienced developers. There’s so much to learn nobody ever told you and maybe nobody ever will.

So I think a new programmer should start maintaining a running system. They had a lot of time doing fresh development already during their education, and now it’s time to learn the rough edges. They should be given the chance to break an existing system. More than once. Because that is how you really learn to really be careful and not to judge existing code too fast.

Having to read and change crappy code does two things: it shows you how important it is not to write crappy code, and you’re forced to respect code. This body of code may have done it’s job for years, no matter how badly written it is. So it’s worth trying to be understood.

If you don’t handle it with respect, it will take its revenge: it’ll break and give you a hard time solving trouble tickets.

Putting new programmers into a think tank (where they presumably cannot break much) is no good for anybody. They won’t learn to understand the code in your organization, and they’ll write code that will be hard to understand for you. They won’t learn much and chances are they’ll simply write a system that’s completely out of spec. And they’ll have to learn things the hard way anyways, just later, when it’s probably even more risk to your project.

So I think young developers should start in a maintenance project rather than some fancy new strategic project.

We should resist the promise of “The young guys all can do Java a lot better than we can, so they should do the fancy new Java project while we maintain the really important core systems”.

Funny enough, chances are that if you bring the young into maintenance projects, the old guys will learn a lot from the young about newer concepts and tools that could make their jobs easier, and the young will learn a lot about how software is written in your organization. They’ll soon understand that you’ll have to accept bad code and weird decisions as long as they don’t fully understand the consequences of changing them.

Are you looking for a Smalltalk/Seaside job?

If you know Smalltalk or would like to learn it, get your feet wet in Web Application Development with Seaside, then you are probably lucky: such a job is available at, which is somewhat the epicenter of the Seaside world.

From Adrian Lienhard’s mail on the ESUG mailing list: is looking for a Seaside web application developer. We are a small, agile team located in Bern (Switzerland). With Cmsbox we have developed an award winning Content Management System. The successful candidate will have excellent skills in OO software development with a dynamic programming language. Fluency in German is not a must, but we expect applicants to acquire basic understanding of German.

A detailed job description can be found on our website (in German):

Sounds like there’s fun to be had at work…

Suchen freiberuflichen VisualWorks-Entwickler

…für den Würzburger Raum. Aufgabe: Weiterentwicklung eines ERP-Systems, Schwerpunkt zunächst auf Einarbeitung/Projektmanagement, später Entwicklungsarbeit.


  • Mehrere Jahre Smalltalk-Erfahrung, optimaler Weise mit VisualWorks
  • Erfahrung mit ERP-Systemen bzw. betriebswirtschaftlichen Abläufen in Unternehmen

Projektstart: idealer Weise Anfang August, Laufzeit minimum 6 Monate

Einsatzort: GR Würzburg

bei Interesse freuen wir uns über Profileinsendungen mit Stundensatzvorstellung (alles inklusive). Kontaktinfo findet sich hier.

Cobol ist 50 – und keiner will’s wissen

Irgendwie war mir das schon klar, dass Cobol sehr alt ist. Aber dass gestern offenbar der Tag des 50. Geburtstages war, ist mir nicht bewusst gewesen.

Ich selbst habe vor einiger Zeit mal ein bisschen Cobol-programmiert, und bin ganz froh darüber, dass ich es lesen kann und auch mal mitreden, wenn’s um Cobol-Themen geht. In den Projekten, durch die ich mich so kämpfe, ist Cobol fast immer die Sprache auf dem Back-End, also dem dicken IBM-Hobel im klimatisierten Hochsicherheitskeller.Und das, was Cobol da tut, tut es in beeindruckend schneller und stabiler Weise: Massendaten durchmassieren und von A nach B schaufeln. Das Gespann Großrechner und Cobol ist da ziemlich ungeschlagen das performanteste, was es gibt.

Umso schlimmer finde ich, dass man sehenden Auges in eine Situation hinein schlittert, die katastrophaler nicht sein könnte: Cobol ist bald nur noch was für alte Recken oder verkrachte EDV-Quereinsteiger, die sonst nix drauf haben. Dabei bewegt Cobol weltweit dermassen viele Daten und damit auch Geld, dass es befremdlich und unheimlich ist, zu sehen, wie stiefmütterlich sowohl der Mainframe als auch Sprachen wie Cobol oder PL/1 behandelt werden, wenn es um den Aufbau von KnowHow und die Ausbildung von Nachwuchs geht.

So hip und sexy Web und Rich Client sein mögen, so unbedeutend sind sie doch (leider?), wenn es um die Verarbeitung von Buchungen, Lastschriften, Abbuchungen, Massenmailings und so weiter geht.

Keiner bildet mehr Cobol aus, schon gar nicht unsere Universitäten, denn Cobol ist ja simpel und schon so alt. Mir hat man im Studium Anfang der neunziger Jahre erzählt, bis ins Jahr 2000 gäbe es den Mainframe nicht mehr. Das macht dann alles eine Unix-Maschine. Zwar hinkt dieser Vergleich ziemlich, denn das eine schliesst das andere ja nicht aus, aber das war den Herren Professoren wohl so noch nicht aufgefallen. Und mit der geänderten Hardwarearchitektur würde dann auch alles aussterben, was man auf dem Hobel damals eben so machte. Und damit auch Cobol.

Zugegeben, wir haben heute bunte und intuitivere Oberflächen in der Hinterhand als einen 3270-Bildschirm in Bernstein oder mit 6 Farben, und mehr als 80*25 Zeichen können heute sogar unsere Mobiltelefone darstellen.

Aber wir scheinen gerne zu vergessen, dass die Erfassung und Plausibilisierung von Daten zwar eine wichtige und unterstützenswerte Aufgabe ist, aber in den meisten unserer Projekte steckt am Ende ein Jobnetz aus Batchprozessen am Host, die dann morgends um Drei Uhr im bereits angesprochenen Keller die Schmutzarbeit machen.

Ein paar interessante Zahlen zum Thema aus dem Heise-Artikel:

  • weltweit 200 Milliarden Zeilen an Cobol-Code, und es kommen mehrere hundert Zeilen täglich hinzu. (Anmerkung des Autors: es sind ganz sicher deutlich mehr als ein paar hundert pro Tag!)
  • Ungefähr 1,5 bis 2 Millionen Entwickler haben mit Cobol-Code zu tun.
  • David Stephenson von dem britischen Cobol-Experten Micro Focus geht davon aus, dass heute 200-mal mehr Cobol-Transaktionen täglich durchgeführt werden als Suchanfragen bei Google.

Ist es nicht Wahnsinn, dass wir uns keinen Cobol-Nachwuchs mehr heranziehen, ohne bereits heftigst an einer geeigneten Nachfolgetechnologie zu arbeiten? Sind wir nicht ziemlich schräg unterwegs, wenn man bedenkt, dass wir noch nicht einmal eine müde Idee davon haben, wie diese Nachfolgetechnologie aussehen könnte?

Und selbst wenn wir schon eine hätten, wie lange müssen wir wohl in die Zukunft schauen, bis diese die bestehende ersetzen kann.

Jeder, der schonmal einen neuen Buchungslauf eingeführt hat, oder unter der alljährlichen Urlaubssperre zum Jahreswechsel dem großen GAU entgegengefürchtet hat, weiss, wieviel vergessenes Know-How und Detailwissn in diesen teilweise 30 Jahre oder noch älteren Programmen steckt. Wieviel Testaufwand steckt in diesen Systemen? Ich vermute, wir können hier global betrachtet von einigen Taused Personenjahren ausgehen.

Heise schliesst seine Geburtstagslaudatio mit den Worten:

Spannend dürfte für die Zukunft sein, wie viele Systeme Firmen aufgrund mangelnder Programmierer mit Cobol-Know-how auf andere Programmiersprachen wechseln.

Die Frage ist nur, auf welche sollte das sein?

Java-Batchprozesse? Technisch sicher machbar, und das Zeug zur Legacy hat Java ja durchaus.

Ruby on Iron? Immerhin sehr hip zur Zeit.

Wie lange werden diese Technologien leben, und welchen Vorteil hätte man daraus, eine neue Technologie mit Milliardenaufwänden zur Legacy von Morgen zu machen?
Sterben uns dann in dreissig Jahren nicht wieder die Ruby-Batch-Programmierer aus? Okay, wir hätten dreissig Jahre gewonnen, und die Konjunktur enorm gefördert.
Wieso denn überhaupt eine neue Technologie, wenn die alte doch eigentlich keinen Anlass zur Klage gibt, ausser, dass wir uns selbst den Nachwuchs abschrecken?

Achja, und egal, welche Programmiersprache man sich immer aussucht: schnödes Datenmassieren ist es allemal.