Falls man auf seine Vorgesetzen nicht genügend herabsieht, dann sollte man sich diese Leute mal in freier Wildbahn anhören. Am Telefon sowieso nicht zu überhören – warum meinen die eigentlich ein Büro haben zu müssen während sie alle anderen in einen „open space“ „integrieren“, wenn sie sobald sie die Vertraulichkeit schützenden vier Wände herum brüllen, das Industriespionage nicht auf Lippenleser zurückgreifen muss? Die Antwort ist die erwartet niederdrückende: Das Gesülze ist derart inhaltsleer, dass eh niemand hinhören möchte auss sie selbst.

Richtig lustig ist es wenn zwei „mittlere“ Manager (meist auch mittlemässige) sich untereinander unterhalten. Erstaunlich wie sie trotz ihrer Überlegenheit – gerade dem dummen Kunden gegenüber – immer noch Mittelmanager sind, die sich mit solchen Peanuts herumschlagen müssen.

Mal wieder in Deutschland. Zwei Stunden Aufenthalt in Frankfurt, bin nicht ganz unglücklich darüber den Flughafen nicht verlassen  zu müssen. Selbst hier drin ist es kalt, da kann ich mir das Draussenerlebnis vorstellen.

Schon Scheisse genug im Flugzeug zu frieren, daran hat man sich ja gewöhnt, weil es Amis immer auf Eisschranktemperatur runtergefrostet haben müssen, besonders wenn es draussen plus oder minus 30 Grad hat. Und Amis kommen ja aus dem Wunderland des Service und darum miuss man alles so machen wie in Amerika … give me break.

Endlich, nach gar nicht so schlechten Nürnberger Röstbratwürstchen mit Kartoffelbrei und Sauerkraut und einem nicht minder nicht-enttäuschenden Käsekuchen und einer freundlichen, aufmerksamen Bedienung – die mich auf Englisch begrüßt hat, aber sich dann doch merken konnte einen deutschsprachigen Gast zu haben (hat sich also, wie sich im nachhinein herausstelltem völlig verdient ein gutes Trinkgeld verdient) dann ans Gate.

Niemand kommt auf die Idee zu Fragen wo man herkommt, man wird einfach auf Englisch angequatscht und ungelenk von den Sicherheitsleuten herumkommandiert. Auch wenn man auf alles was sie sagen auf deutsch antwortet, sie bleiben in ihrem Trott. Tiefpunkt am eigentlichen Gate (gibt es dafür noch ein deutsches Wort?): „Guten Abend“ – „You’re welcome!“ … klar, sie meinen es genau  so wie in Amerika…

Monads are usually associated with being something highly theoretical that nobody really understands - unless you either worked with category theory or came to Haskell via another route. An elephant in some sense - big grey matter…

James Iry provides a Monad introduction for Scala programmers, he leaves out most of the what a monad is, but explains more pragmatically what the qualities of monads are. So far part 1, 2, 3 and 4 (of a series of 5?) are available on his blog.

Give it a read, you might learn that you had been already using monads without knowing and why this perfectly nice Java code is hard to understand for other programmers. If this is the case give this intro to those programmers, in any other case learn it yourself.

(updated 15.11.2007)

Already a bit late hour, but after a nice couscous some things become clearer.

Currently I feel quite a pressure. After more than 12 years in this monkey business I have learned to ignore it - “people under pressure won’t think faster” (oracle@lister.com)

What was more important is a sudden shift of my manager. He became quite nitty-gritty and micro-manages some developers (we have “team-leaders” for that:-). This means the pressure he feels must be enormous.

I had been completing two important functions in the last days - both had been properly prepared and well - though not formally - specified. Implementing them had been easy. Two issue of highest priority and severeness resolved. Normally something that makes a manager’s face shine.

But a bit to my surprise he had been mildly angry with me. His point was that working on another issue was more important as the testing was more complicated. During the afternoon I grabbed together what was going on. It is true that we don’t even have a plan to test it, three parties are involved in the development, the specification is vague as the functional architect hasn’t barely any knowledge about the underlying technology. To make it worse the three parties work completely disconnected have not even a process to synchronize their work using a common code repository (each part is build and deployed independently!). I have advanced my work to everything that can be tested at the moment and I was reluctant to write anything that is either untestable of would stop me from completing over parts. Instinctively I stopped working on the project and turned to something more fruitful.

I had been chewing all evening long if I had been acting correctly. What had been the alternative? Instead of providing real value I had been writing junk code, perhaps got lost in an architectural beauty that just camouflaged my lack of understanding of the problem - I know myself: When I start to think deeply about a design, despite my experience, it is a warning sign that I actually didn’t understand the problem and try to build something very general that can be turned into the right thing or even anything in the last minute. Useless to mention that these attempt fail sufficiently often and with all the time consumed for these over-engineered solutions such an approach it ridiculously inefficient.

Question is now: Can we savely say that we should focus on the parts that are thoroughly understood and postpone everything else, or at least put the least understood at the back of the queue? This would be a radical approach to priority management, but it falls in line with some “truths” we have learned to accept:

1. Don’t start coding until you have the complete spec (from the waterfall processes)
2. Every function must have a provable business value. (the XP stuff)

Truth 1 is rarely fulfiled, but if you accept it: a problem you don’t understand is perhaps poorly specified. For Truth 2 it is easier: How can you prove business value if you don’t understand what you are talking about.

My stance therefore is: Do what you really can do

Jesse James einmal anders, wer wilde Schiessereien erwarte wird enttäuscht sein

Handlung

Jesse James am Ende seiner Karriere, er ist müde das Banditenidol einer Generation zu sein und provoziert seinen Abgang. Robert Ford ist einer seiner Anbeter und versteht nur langsam den Menschen Jesse James.

Warum sollte man den Film sehen

Der Film lässt sich Zeit und dem Beobachter Zeit zu betrachten. Die Elegie wird dadurch spürbar.

Was nervt

Brad Pitts schauspielerische Fähigkeiten sind doch arg begrenzt, gut das die Rolle vornehmlich verlangt mit leeren unausdrucksvollen Blick nichts zu fixieren. Der Abspann ist überflüssig, zu moralisch für meinen Geschmack

Platoon in den kabylischen Bergen

Handlung

Algerien ‘59. Die französische Kolonialmacht schlägt sich im algerischen Bergland mit der FLN. Ansonsten das übliche: Junger idealistischer Intellektueller gegen alten Haudegen

Warum sollte man den Film sehen

Wäre kein französischer Film, wenn der junge Held und der alte Haudegen nicht so ihre inneren Brüche hätten (Albert Dupontel spielt hier um den Ceasar mit!) .

Zudem, das Thema kommt in Mode, ist aber noch nicht tot geredet. Der Algerienkrieg ist ein bisschen;-) tabuisiert in der frz. Gesellschaft, wohl auch weil die Akteure in der Regel noch am Leben sind

Was nervt

In der zweiten Hälfte baut der Film etwas ab - es ist, als würde die Zeit fehlen (oder das Geld - oder auch beides). Animationen (Hubschrauber, brennendes Dorf) wirken wie auf einer Modelleisenbahn gedreht. Schade, für eine handvoll Euros mehr wäre diese Peinlichkeit zu vermeiden gewesen

Der Kult(?)roman von Frédéric Beigbeider (”39,90″) nun als Film.

Handlung

Octave is Kreativer bei Ross&Witchcraft, sein Leben ist es ein Bild zu vermittlen und er ist nicht anders - in ihm rebelliert es.

Warum sollte man den Film sehen

Der Film folgt dem Buch nicht im Detail, dadurch ist es interessanter den Film anzuschauen als das laue Geplapper von Beigbeider als Buchform für nun (19,90EUR). Einige cooole special effects wirken für den Film wie der Koks auf Octave.

Was nervt

Ist sicher kein Film für jedermann. Falls man ein gestörtes oder normales Verhältnis zu Drogen hat, besteht die Möglichkeit, dass man sich aufregt

Scala is now again capable to compile to IL-code so that you can use it from a .NET program!This feature vanished a while ago as the compiler got overhauled and now it is back - according to Martin Odersky, the main figure behind Scala “There are some known problems with exceptions, which we might be able to solve soon.” - but still, the best thing since sliced bread.Here is how to do it (get your paths properly set!):

1. Get Scala (JVM >1.4.2 needs to be installed)
2. Install the MSIL package with “sbaz install scala-msil”
3. Compile your  scala files with “scalac-net  <files>”
4. Build  a dll from them with  “ilasm /DLL  yourfiles.msil”  (use /EXE if you have a main method to get an executable)
5. Reference the dll from you .NET project

You can also use .NET libraries from Scala code, for the compilation you have to add the referenced DLLs with the parameter -Xassem-path First.dll;Second.Dll to the scalac-net commandNot so difficult and with some scripts pretty quick to integrate. Of course it will not work to use scala classes that  reference java libraries! Neither will you be able to run (not even compile) scala classes that use external DLLs - unless you want to dive into the JNI hell. A compile switch that warns of “unpure code” to the Scala compiler would be helpful here (Something I should ask for, hopefully I won’t forget).The limitations are not such a problem, the main goal is having a modern language (that is even more powerful than C#, more modern than Java 7 with all discussed extensions) to implement business function that can be directly used on both platforms is a huge win. I am curios what nice libraries will be published for the use on both platforms - distributed as a DLL for .NET or a simple JAR for Java environments.

From time to time I re-read two books: The Deadline and The Soul of a new Machine. They both are a sanity check to me and to what is going on around me. Both are in a novel form that makes them also a bit fun to read. This night I picked up again The Deadline, went to my favorite brasserie for some dinner an wine, I flipped through the pages and started reading somewhere in the middle.

Fine grained design (sorry I have only the German translation)

The key statement was that you can move quicker if you spend less less time on debugging. This is undoubtedly true I think, but their remedy is something I ever disliked: Fine-grained designed where you try to verify before starting coding . I never liked theses design documents for a simple reason: They spend lots of pages on the obvious to hide the sloppiness of what is poorly (if at all) understood. When verifying it you spend much time on the obvious and happily overlook the parts that aren’t well defined, as they can’t be that important – otherwise the author(s) would have spend more space on it, haven’t they? When implementing it, you’ll get the 90% syndrome: ask the developer after about half of the estimated time how far he got and he will answer “90% completed” - problem is – these ten percent will stay around forever, after 200% of the estimated time the programmer (now with tired eyes and a bad shave) will still tell “about 90% done”.

Short, I believe the only true design is the code (“The system is fully documented – granted you can read C++“- Z.Köntös), but of course not any code, it has to be expressive. In C days a basic design had been made from documented header files, in Java you create interfaces or if someone pays you to do so you’ll sketch endless variations of UML diagrams. UML is believed to be a superset of what you can code – given a smart generator it transforms your design into code where “you just have to fill the gaps” and changes to the design in the code “can be reverse-engineered”, NOT. There are some cases where certain diagrams are really useful to get you an overview of a project, but all examples I know fall in two categories:

1. Reverse engineered and handcrafted for better readability

2. Metacode that is feed into interpreters and MDD tools

If we have to accept that the design and the code have nothing in common, why not simply skipping this stage. 20 years ago this hadn’t been a proposition. But it is not true anymore. Modern languages and IDEs provide browsing and refactoring or mix in mechanisms that make the design malleable even if it it is (already) in code. With C and COBOL it might be possible as well, but it hadn’t been possible in their time. This means that your design process is less a constant than perhaps the design! If we accept this the consequences for the work are huge: If you use a language that is capable of expressing your design, it is idiotic to use a design tool outside to describe it. You’ll break your neck to describe in prose or diagrams what is a common idiom in your language (…API, DSL) – only to end up with something that is weaker than the code you have written. And this is the crucial point: Design tools and generators assume that their representation is complete, as any generator can only loose information – if your code is more expressive the generation and the reverse engineering of code cannot work at all. If you are inclined to follow, beware of the caveat: If your language is expressive enough, but you don’t use it appropriately the representation of you design will stay incomplete and you might need additional documentation - or better (but fewer) programmers.

You can use an expressive language to get around formal design, what do you get:

1. Instead of an intermediate layer, you have something you can work with

2. Your design is as live as the code is – any refactoring updates your documentation

But back to the claim of DeMarco’s book. It is is indeed still that verification of the design saves debugging, but that doesn’t mean that the design has to be made in another medium than the code. I came to this during my recent experiences learning Scala. I wrote some pretty complicated stuff and went naturally a bit wild with some feature of the language, but I noted one thing: I spend very little time on debugging (one thing I wrote was a specialized implementation of nauty). The language forced me to (or perhaps I did myself as I wanted to learn as much as possible from my examples) express concisely what I want to do. And as the language allows you to be extremely type-hard in your code it actually enabled me to do so. I also discovered that I wrote code that tended to be more declarative to avoid debugging into deeply nested list comprehensions. This topped even the positive experience I had years ago starting using Java, which I found pretty crippled as a language coming from C++.

One of my famous war stories is that I once wrote 400 lines of C++ on a single afternoon that compiled with no errors and also worked as I intended. I never managed to do it again. It was pretty convoluted code (technically a small interpreter) and I never managed to the same in another language I know very well: PL/SQL. And I have also Java code that has a complexity below those 400 lines C++ where I think that I’ll never be able to get them to work correctly.

So what is the key difference? Abstractions. Scala makes it easy to build abstractions, also because you get instantly rewarded by it, C++ as a very flexible language allows it also (though it is much harder), Java knows abstractions in form of APIs and frameworks – but this doesn’t help you as soon you are getting into region far from the API and your framework. These abstractions can be called DSLs, you shape your environment to you needs, perhaps even in multiple layers. In C++ operator overloading has been the too for that, in Java frameworks and APIs (quite clumsy in terms of syntax) where in Scala the difference between operators and methods dissolves completely ( as does the difference between a block and a parameter; and the extractors as antonyms to constructors). My C++ example was btw a good example of abstractions, many classes, few methods with am orthogonal interaction – such code either works or can’t be written at all. Making good abstrations in PL/SQL is as in Java on API-level.

Where is the dynamic world?

As much as I share the thoughts of Paul Graham, I can’t relate to his indissented preference for dynamic typing; there he is missing the point. Yes, malleable code is important, by if you have to keep track of each instance you might reinterpret it will likely blow your mind. I think he meant that you are coding DRY (Don’t Repeat Yourself), something that can be done perfectly (not that hacking style that is considered as expert Ruby) in Lisp (if you know macros!). Static languages can offer you the same comfort without resorting too often to macros (hard to implement in any language with syntax – Lisp doesn’t have any that’s why it is the only language having this feature) if you have type inference as well (Scala, C# 3.0). If you need to change a type, do it, the program will follow, but the compiler will shout at you if you crossed the line. This makes it even possible for others to change you program, because they get a quick feedback when they do something your initial design didn’t foresee.

The others

How is most software written today? Unfortunately with the methods of the 70’s and the tools of the 80’s (if at all). Even if they happen to use a technology of the 90’s, the methods are the old ones and the code will not exploit what is possible, but what is in the line what the environment gives you. In summary: You have a spotty design, verbose inexpressive code (“it is simple everyone can write it” – “if you have some dozens of programmers in India”) and exploding budgets and/or disgruntled customers. Poorly understood design leads to missing/faulty features, correcting these in a mess of thousands of lines of indistinguishable rubbish slows you down; the actual development moves to the debugging stage (if you are still lucky with a customer a beta(?) tester) – I call this “debugging into existence”. Even if development is always trail and error - debugging is different: When you discover a misconception during development, you go and update the spec – in debugging, the only trace will be a “resolved” in the bug database, more over debugging should fix issues and mustn’t create new ones, thus most people that correct bugs, correct them as locally as they can, even for the price of copy&paste code and compromised architecture.