MacBook Pro – Verjüngungskur

Seit ich auf meinem MacBook Pro 4,1 (early 2008) in einer Windows XP VM auch noch DB2 zu Entwicklungs- und Testzwecken brauche, zeigt sich, dass 5 Jahre offenbar eine ganze Weile sind. Ab und an hatte der Beachball doch mal ein paar Sekunden seinen farbigen Charme versprüht.

Nun gibt es natürlich die Möglichkeit, so richtig Geld in die Hand zu nehmen, und sich eines der schicken neuen MacBook Pro’s zu kaufen, aber irgendwie missfallen mir Apples Wartungshürden, die immer höher werden. Ich möchte mir, auch wenn sie leider völlig überteuert sind, einfach einen neuen Akku kaufen können. Oder einfach ein bisschen mehr Speicher reinstecken. Oder womöglich mal eine Platte austauschen. Nun war das noch nie eine der starken Seiten von Apple, aber besser geworden ist es bei diesem Thema in den letzten Jahren nun wirklich nicht.

Bis vor der Installation von DB2 unter Windows hatte ich mit diesem Core 2 Duo – Gerät keine Performance-Probleme, auch nicht, wenn ich Windows XP unter VMWare nutzte. Verglichen mit sogenannten modernen Entwicklungsumgebungen ist VA Smalltalk ein wirkliches Ressourcen-Sparwunder. Und was spricht schon dagegen, ein komplett funktionstüchtiges Gerät einfach mal ein paar Jahre länger zu nutzen: noch ist mein MacBook vom neuesten und feinsten Mountain Lion unterstützt, zumindest sind alle features unterstützt, die ich brauche (Powernap ist bestimmt sehr nett, und Airplay auch, aber…)

Langer Rede kurzer Sinn, ich habe mir nun also eine Samsung SSD aus der 840 Baisc Serie gegönnt und eingebaut. Nun bin ich zwar kein wirklicher Hardware-Hacker, aber vor vielen, vielen Jahren habe ich mir meine PCs auch selbst zusammengeschraubt (Es dauerte IMMER ein Wochenende, denn Samstags musste man grundsätzlich ein paar Teile beim Händler umtauschen, damit Sonntag früh dann alles installiert werden kann. Aber Spass hat es gemacht!), also ging ich frohgemut und mit einigen Anleitungen bewaffnet ans Werk:

• Es gibt wohl keinen berühmteren Ort für Reparaturanleitungen, als iFixit.com
• PowerBook Medic half beim Aufschrauben per Video, weil die Sache mit den vier komischen Haken vorne über dem DVD-Laufwerk fühlte sich schon unheimlich an…

Nach dem (fast kompletten) wieder Zusammenschrauben gleich mal die große Freude: Tastatur und Streichelbrettchen gehen noch! Was bin ich für ein Held!

Das Laptop hat schon ein paar Generationen OS X erlebt, und es wurde bisher immer per Update installiert. Damit hatte ich zwar nie wirklich Probleme, aber irgendwie wollte ich nun mal frisch installieren. Wenn schon Platte raus, dann entschlacke ich gleich richtig, dachtre ich mir. Das ist natürlich bei einem Betriebssystem, das man nicht auf einem Medium kaufen kann, eine Sache für sich.

Aktuell installiere ich Mountain Lion von einem USB-Stick. Im Grunde war das alles sehr einfach, wenn man denn eine passende Anleitung dazu findet. Und ich habe eine von netzwelt.de benutzt. Sie war so schön bebildert und wirklich Idiotensicher.

Nach dem Einbau dann die erste Schrecksekunde: Das Installationsprogramm kennt die Platte nicht. Kurzes Paniken, dann die Erleuchtung: vielleicht ist das ein bisschen anders als bei Windows, und das Partitionieren ist nicht Teil des Installationsvorgangs. So war es dann auch. Zurück zum Startdialog, Festplattendienstprogramm starten, und die Platte wird dort angezeigt. Also rasche eine Partition drauf, und zurück ins Installationsprogramm. Großes Aufatmen, die Platte ist da und wird als Medium für die Installation angeboten.

Noch kann ich gar nichts zur Performance sagen, der Installationsvorgang läuft ja noch, und dauert eine gefühlte Ewigkeit (knapp 20 Minuten laut Installationsprogramm). Der erste Reboot hat geklappt.

Apple wäre nicht Apple, wenn es einfach so alles mögliche an Hardware zuliesse. Deshalb unterstützt OS X auch kein TRIM. Dafür gibt es aber ein mit Lob überhäuftes Freeware-Programm namens TRIM Enabler, das ich nach der Installation gleich drauf machen werde. Und dann gehts ans kopieren der Daten und Installation meiner Anwendungen. Das wird noch spannend. Ich habe mich wegen der “clean install”-Methode gegen die so oft zitierte Vorgehensweise mit Carbon Copy Cloner oder SuperDuper entschieden, sondern werde die alte Platte einfach extern per USB anschliessen (hab da so ein externes Dock für Platten) und die benötigten Sachen von Hand kopieren.

So, nun habe ich lange genug getippt, die Installation ist durch, der Rechner bootet gerade neu, jetzt habe ich keine Zeit mehr fürs Blog. Demnächst vielleicht mehr zum Thema. Jetzt will ich erst mal Besitzerstolz aufbauen

Werbepause: VA Smalltalk zum Sonderpreis für VisualAge-Kunden

Es ist ja gerade EM, da hat man sich ja schon an sie gewöhnt, die Werbepausen. Wieso also nicht auch mal eine hier auf meinem Blog?

Instantiations hat gestern eine zeitlich begrenzte Aktion für Kunden von IBM VisualAge Smalltalk bekannt gegeben. Sie richtet sich an alle Nutzer der Entwicklungsumgebung VisualAge Smalltalk in allen Versionen bis einschliesslich 6.03 und ist zeitlich befristet bis zum 17. September 2012.

Was heisst denn Sonderpreis?

Für Kunden, die bisher noch kein Upgrade von VisualAge nach VA Smalltalk durchgeführt haben, bieten wir das Upgrade inklusive 12 Monaten Support und Upgrade-Berechtigung zum Preis des jährlichen Supports an. Das heisst, die Lizenzkosten entfallen bei Nachweis einer VisualAge-Lizenz völlig. Das entspricht einer Ersparnis von etwas über 70% gegenüber dem Neukauf von Lizenzen. 

Wir unterbreiten Ihnen gerne ein Angebot.

Warum sollte man auf VA Smalltalk upgraden?

VisualAge Smalltalk wird seit 2005 nicht mehr von IBM weiterentwickelt. Damals hiessen die aktuellen Betriebssysteme noch Windows XP oder in vielen Unternehmen noch Windows NT. Mit neueren Windows-Versionen ab Windows Vista gibt es mit VisualAge teilweise Probleme durch ein neues Berechtigungs- und Sicherheitskonzept im Betriebssystem. Mit Windows 8 ist zu befürchten, dass zusätzliche Probleme auftreten.

Aber nicht nur bei Windows hat sich die Welt weiter gedreht, sondern auch in Sachen Datenbanken und Middleware. Noch wichtiger für laufende Projekte ist jedoch, dass VA Smalltalk in vielen Details weiterentwickelt wurde und seit 2005 einige hundert Fehler beseitigt wurden. Es sind auch ein paar wirklich interessante neuere Features aufgenommen worden, wie etwa ein neues Persistenzframework (GLORP) oder das Web-Anwendungs-Framework Seaside. Der XML und Web Services Support wurde weiterentwickelt und viele Verbesserungen der Entwicklungsumgebung selbst wurden aufgenommen. Hier finden Sie eine genauere Auflistung aller Neuerungen in VA Smalltalk seit 2005.

Ist ein Umstieg nicht zu aufwändig?

VA Smalltalk ist bei all dem vollständig kompatibel zu VisualAge 6.0, sodass ein Umstieg sehr einfach durchzuführen ist. Gerne bieten wir dazu auch unsere Hilfestellung an.

Was muss ich / muss meine Firma tun?

Wir benötigenen einen Nachweis über den Kauf von IBM-Lizenzen (Seriennummern, Kaufrechnungen, Lizenzverträge). Diese reichen wir bei Instantiations ein. Bestätigt der Hersteller, dass Sie für ein Upgrade qualifiziert sind, unterbreiten wir Ihnen ein Kaufangebot.

Warum bei der objektfabrik kaufen?

Wir sind seit Anfang an Vertriebs-, Schulungs- und Beratungspartner der Fa. Instantiations und haben bereits davor als IBM Business Partner unseren Kunden im Umfeld von VisualAge Smalltalk geholfen. Seit 1999 arbeiten wir erfolgreich mit Smalltalk – nicht nur, aber vor allem in VisualAge / VA Smalltalk.

Für Kunden in Europa hat ein Bezug über uns den Vorteil eines Kaufs auf Rechnung mit deutscher Mehrwertsteuer bzw. eine Abwicklung im Reverse-Charge-Verfahren. Keine unkalkulierbaren Kosten durch internationalen Zahlungsverkehr oder die Problematik des Einkaufs auf Kreditkarte.

Nicht zuletzt sind wir als lokaler Ansprechpartner rund um VA Smalltalk bei kleinen und großen Problemen für unsere Kunden da, helfen im Projekt oder schalten uns in die Kommunikation mit dem Entwicklungsteam ein.

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!

PragDave on Software Archeology and The Advantages of Self-Containment

I just finished listening to Episode 148: Software Archaeology with Dave Thomas (Pragmatic Dave) of Software Engineering Radio.

It’s a really interesting interview and Dave has a lot to say about our Software Engineering Jobs of today:

• Most of the time we read code rather than write it
• Most of the code we have to read is in less than perfect shape
• Most of the programmers aren’t educated in how to read code
• Far too often people change code they don’t really understand
• Tests are a great way of proving your hypotheses about what existing code does
• Code rots, and you have to be prepared or it
• Only documentation tends to rot faster than code
• Most documentation that gets written is mostly useless, because people tend to document the obvious rather than the reasoning behind their decisions
• Reading code is not only good in software maintenance but also is an educating exercise
• You can write bad code in any language, but also: a well-written program can be easy to understand in any language

There’s not much space for disagreement here, since you learn these lessons pretty fast when you maintain software. Also the idea of having to “get into people’s heads” about their style of programming, thinking and problem solving is absolutely right. To me, it’s often good to know who wrote a method, especially in projects where I know the initial programmers. You sometimes really know why something was done in a certain way if you know who wrote the code.

So it may sound funny, but sometimes you find your way to a bug a lot faster by knowing whose code it’s in. Every programmer leaves some DNA in their code, and since software maintenance has a lot in common with detective stories, it’s always good to have a profile of your “Mister X” in mind

Some of the things Dave talks about sound weird or ridiculously obvious at first:

• Print out an artefact in 2pt font size to learn about its structure
• You need to make sure you’re digging in the right version of the code
• You need to make sure you have all the necessary code
• Use a local code repository
• IDE’s and code generation can be dangerous
• Tools like Emacs and grep can be of great help

But once you think about them, you’ll find them much more useful advice than they sound in the first place.

When trying to translate some of these to Smalltalk, however, I guess we can put some of these aside. There’s no point in using grep on Smalltalk code if you work in an image based environment. There are much better tools like References, Senders/Implementers and such. And there’s not much use in looking at a body of code isolated from the Smalltalk class library. In the light of these arguments, the use of a good source code control system like Envy becomes more important. Since I never tried the tiny font-size thing, I can not really judge it. But I can imagine that in a purely file based world, even this kind of thing can help (and if not, it’s been worth a try).

This, combined with the fact that software archeology is not necessarily a nondestructive task (it’s not about conserving code, but about understanding it), version control gets more important. As I mentioned in my talk at the VA Smalltalk Forum two weeks ago, Refactoring is a great way of finding your way into existing code. Sometimes just changing the name of a temporary variable or a parameter or extracting parts of e method and giving it an intention revealing name makes understanding code a whole lot easier.

Dave also mentions the importance of getting a hold on all artefacts that are needed to make a piece of code run, like database creation scripts and stuff. Since I am a strong believer in “get all your stuff into your code repository” and since my favourite language Smalltalk makes this quite easy by having the compiler available to create classes out of scripts (again, see my talk for an example), I think we have a very good environement to our disposal to make the lives of later software archeologists easier.

Since Software Maintenance is one of the most important and least appreciated tasks in Software Engineering, I guess we owe it to ourselves and to the developers who need to get along with our code to use techniques and tools that make archeology easier. We need to improve our coding style, documentation habits and we need to keep in mind our code is not only there to be executed by machines, but mostly to be understood and reworked by humans.

And I guess there aren’t many environments that make reading (into) code as easy as Smalltalk. The Smalltalk Debugger as a means of watching the innards of a program on the job and even modifying a program in the middle of a task, together with a rich set of inspection tools and well-integrated testing facilities like sUnit, combined with a whole set of Code Browsers that are written around the idea that “FINDING EXISTING CODE” is the main task in programming, not only make writing code easier in the first place, but also help later developer generations to understand our code.

In case of Smalltalk, this is not a theoretical assumption, it is a proven fact that the language allows for long product lifecycles. There are many systems around that are running for more than one and a half decade, and continue to be integrated into modern architectures like Web Services or to be transformed into Web based applications while also adding new features all the time. This would presumable be a lot harder in less maintenance-friendly environments.

As developers, it’s our responsibility to lay the grounds for later generations, and we have to make decisions that will have consequences even when they’re pushing us through the park of our elderly’s home on a wheelchair every wednesday afternoon. So using an environment that’s helpful in reading code and checking hypotheses is what we should do. Smalltalk is an environment that qualifies in this area and should seriously considered as the platform of choice.

Many people out there think that Image-based systems are a bad thing, since they feel they’re losing control over their system’s structure, but it’s quite the opposite: A Smalltalk Image is the whole world of the objects in a system and therefor gives you much more abilities to explore and search than a list of dead files. In the end, in an object world, what kind of structure does a file give you? Your running program consists of classes and instances, not of files.

Taking Dave’s Analogy a step further, there is a strong advantage in Smalltalk, because learning about existing code is not really archeology, but much more like time travel: you just jump into the bazaar of a running system, talk to the merchants and visit the temple on the hill instead of just digging some old stones out of the sands. So while software archeologists try to imagine how a system might work or have worked, we Smalltalk developers have the luxury of just starting the system up and live in there for a day or two.

Lieber ein Ende mit Schrecken…

…als ein NAS-Gerät, das ständig zickt.
Monatelang waren wir mit der IcyBox IB NAS 4220 B ganz zufrieden. Es ist ein leises und sparsames Gerät, das seinen Job als NAS ganz gut macht, wenn man die richtigen Platten drin hat.
Ganz offenbar mag es keine Samsung-Platten und mit Western Digital gibt’s auch immer wieder Probleme. In unserem stecken zwei WD Platten (5000ABYS, um genau zu sein).
Seit aber vor kurzem das RAID aus den Fugen geraten ist (oder es schon länger aus den Fugen war, und es erst vor kurzem auffiel), und man dem Web Interface wohl nicht so recht trauen kann, macht mir das Ding echte Sorgen.

Als dann am Samstag aus heiterem Himmel angeblich eine Platte defekt war, und das RAID wieder hergestellt wurde, und nun angebliche wieder alles in bester Ordnung ist, die Kiste aber nicht immer hochfährt, ist für mich eines klar: keine Projekt- und Kundendaten mehr drauf.

Für diesen Job habe ich mir nun eine fast genauso sparsame und fast genauso kostengünstige Alternative ausgesucht, die hoffentlich noch vor Weihnachten ankommt.
Mit seinem Atom 330 und einem stinknormalen Linux (glücklicherweise habe ich genug Linux-Erfahrung) drauf, löst das Ding dann auch noch ein paar weitere Probleme:

• Es kann problemlos als Subversion-Server fungieren
• Es kann PostgresQL-Datenbanken verwalten (es werden maximal eine handvoll clients gleichzeitig drauf arbeiten)
• Wir können den Envy-Library-Manager drauf installieren
• Mit Webmin lässt sich auch hier eine hübsche Überwachungsoberfläche per Browser nutzen (um etwa den Status des RAIDs zu prüfen)

Es ist eben ein normaler Linux-Server mit fast genauso sparsamem Verbrauch wie die IcyBox, aber eben ein vollwertiger Rechner, an den man auch eine Tastatur und einen Monitor anstöpseln kann, wenn mal nichts mehr per SSH geht.

Bisher scheint mir der Anbieter auch sehr kompetent und freundlich.

Die von mir zusammengestellte Konfiguration wurde hinterfragt und ich habe heute gleich morgens einen Rückruf bekommen, um die offenen Punkte zu klären. Obwohl es sich hier um ein absolutes Low-Price-Modell aus der Produktpalette handelt. So kam nebenbei noch heraus, dass der im Webshop obligatorische RAID-Controller nicht wirklich dabei sein muss (ich will ein SoftRAID einrichten, um die Platten auch an Fremdmaschinen nutzen zu können, wenn mal gar nichts mehr geht). Und es werden keine separaten Festplatteneinschübe benötigt, weil die Platten in welchen verbaut werden. So ist meine Bestellung also um 300 Euro günstiger geworden.

Also bisher ein gutes Gefühl bei der Sache, aber noch habe ich die Maschine ja nicht…

Icy Box NAS und Firmware-Update: Licht und Schatten

Ich hatte ja bereits von meinem RAID-Problem auf unserer Icy Box IB-NAS 4220 erzählt.

Kurz gesagt stellte sich das ganz so dar: alles schien zu funktionieren, aber die Web-Oberfläche meinte stets, es sei am Wiederhesrstellen des RAIDs, und behauptete sogar, einer der Platten sei unmounted. Gleichzeitig gab es aber im SMART-Protokoll keine Fehler, die auf einen Ausfall von Sektoren oder ähnliches hinwies.

Nach einiger Recherche im Netz stiess ich auf Berichte, die auf ein Problem mit neuerer Firmware hindeuteten, das irgendwie mit Partitionsgrößen zu tun hatte. Es gab also nur wenige Alternativen:

• Box wegschmeissen und durch einen richtigen Server ersetzen, denn mit ähnlichen NAS-Geräten habe ich nicht vor, nochmal herumzuprobieren. Ich habe im Zuge dieser Geschichte beschlossen, nur noch Geräte zu nutzen, an die ich einen Monitor anstöpseln kann, und der ich beim Booten zuschauen kann. Wenn mal der SSH-Server auf der Bos aussetzt, steht man im Wald.
• Box auf alte Firmware zurücksetzen, was mir nicht so recht gefallen mochte, denn ich hatte Probleme mit dem Spindown meiner WD-Platten. Sie legen sich mit der alten Firmware nicht schlafen, und so muss die Box immer ausgeschaltet werden, um das grüne Gewissen zu schonen
• Box auf Firmwarestand lassen und RAID neu einrichten und wieder aus einem Backup bestücken
• Box auf neueste Firmware aktuelisieren

Die letzten beiden waren mein Favorit.

Der erste Versuch war also, erstmal ein zusätzliches Backup zu ziehen. Da bei unserer Box der Backup-Knopf am Gerät nicht funktioniert, und ich ausserdem sicher gehen wollte, dass ich mit unseren Büromaschinen auf das Backup zugreifen kann (wir haben derzeit keinen physischen Linux-Rechner am Start), zog ich die Daten über einfaches Dateikopieren über den Mac auf eine USB-Platte und machte zugleich einen neuen Sync auf einen zweiten mac (Chronosync ist wirklich eine tolle Synchronisierungssoftware, mal so nebenbei bemerkt).

Zwei parallele Backups waren irgendwie zuviel, die Box lief nach ca. 1 Stunde Amok und legte das Netzwerk lahm. Es ging gar nichts mehr, kein Internetzugang, kein Zugriff auf Netzdrucker oder der Rechner untereinander, das komplette Netzt schien ausgefallen zu sein. Bis ich die Box ausgeschaltet habe. Die Lan-LED an der Box und am Switch blinkten wie die Hölle, wohl weil irgendwelche Zombie-Pakete im Umlauf waren.

Glücklicherweise konnte ich nach dem Neustart der Box und des Switches ein Backup ziehen und synchronisieren, ohen weitere Probleme.

Dann der Schock: ein Zugriff auf die Box per SSH war nicht mehr möglich: Connection Refused. Das Web Interface lief noch, Daten von der Box lesen und schreiben auch.

An den User-Konten lag es nicht, und der Dienst schien zu laufen, soweit dies dem Adminsitrationslog anzusehen war. Auf irgendwas nachgucken ging ja leider nicht, denn ich kam nur per Webinterface drauf.

Also: Letzte Hoffnung Factory Reset. Danach waren die Daten noch drauf, der Spindown der Platten ging leider nicht, weil die alte Firmware ja noch Fehler hatte. Aber leider war ja nun eine der beiden Platten mit einer größeren Systempartition ausgestattet, als die andere, und das RAID war demnach nach wie vor noch am ständigen Wiederherstellen.

Im Internet gibts zwar einige Tipps dazu, wie man die Partitionierung von Hand ändern kann, aber ich wollte mich da auf keine Abenteuer einlassen, meine Zeit ist mir zu kostbar für Experimente.

Da nen also sowieso partitoniert und restored werden musste, lag es nahe, gleich mal nach neuer Formware zu schauen. Die neueste mag Raidsonic ja nur auf Anfrage rausrücken (ist mir meine Zeit auch zu schade dafür), also habe ich einen Link auf eine fast ganz aktuelle Firmware gefunden.

Nun habe ich also die Firmware IB-NAS4220-2.6.3.2-20090424 drauf, das RAID neu eingerichtet und die Daten zurückgespielt.

Es scheint erstmal alles zu laufen, das Web Interface bietet nun mehr Optionen und vir allem scheint das RAID okay zu sein.

Leider funktioniert der Spindown nicht. Die Platten rotieren auch die ganze Nacht lang, wenn alle Rechner aus sind.

Dabei sind Schmakazien wie Twonky Media etc. deaktiviert. Aber der crond läuft doppelt, wahrscheinlich hat Raidsonic die ganze Kiste einfach nicht im Griff.

Also wir der Server nun zunächst immer schön ausgeschaltet, wenn er nicht gebraucht wird, und wir freuen uns erstmal daran, dass die Daten wieder auf 2 Platten gespiegelt sind. Immerhin das geht ja nun anscheinend.

Aber irgendwie wird’s wohl doch mit der Zeit wieder eine echte Linux-Kiste werden. Es gilt wohl doch: trau keinem, dem Du nicht beim Booten auf die Finger schauen kannst…

Softwarewartung ist Schlammschlacht

Ralph Johnson schreibt in Antwort auf einen Post von Robert Martin einige sehr interessante Punkte dazu, wie ein Projekt in der Wartungsphase zu einem “Big Ball of Mud” werden kann, also einem Machwerk, in dem mit der Zeit jede Änderung nur noch die Gesamtfragilität des Systems erhöht, anstatt die Stabilität und Qualität zu verbessern.

Seine Kernaussage ist, dass das wirkliche Projektleben einfach so läuft, und sich viele Beispiele dessen, was eben im täglichen Projektwahnsinn passiert, nicht ein Ausfluss kollektiver Dummheit der Entwickler ist, sondern eine Folge unglücklicher Umstände und vor allem von Zeitdruck sein kann:

For example, suppose you copy a big chunk of code and then refactor it a little to eliminate duplication.  Then you realize that somebody else has also copied it, but didn’t refactor it.  And somebody else had copied it and refactored as well.  So, you need to figure out how to abstract the whole thing.  You think about it for several hours, try one thing and another, and then decide to go home and hope you think better in the morning.  But in the morning there is a crisis that you must handle.  You don’t get a chance to look at it for a few days [...]

Kommt uns das nicht irgendwie bekannt vor?

This is often how we end up with balls of mud.  As soon as we realize we are in the mud, we should try to get out.  Sometimes something else is more urgent, and we wallow in the mud for awhile.  But as long as we detect the situation when it is a small ball of mud, and don’t let it grow to a big ball of mud, we should be OK.

Die große Frage ist leider gar nicht, wie man einen solche Ansammlung schlechten Codes verhindert, schon gar nicht mehr in der Wartungsphase eines Projekts, das bereits seit 10 Jahren läuft und in dem die Urväter gar nicht mehr mitarbeiten.

Gefordert sind viel mehr Techniken, um mit dem Umstand umzugehen, dass ein System seine ganz eigenen No-go-Areas hat, also Methoden und Klassen, die möglichst niemand anfassen will, und über die man so lange gar nicht nachzudenken wagt, bis eben der Ernstfall in Form eines Tickets aus der Produktion eintritt.