Rusty Car

I just finished ‘Here Comes Everybody’, a must-read for anybody trying to understand what is going on with all this social media stuff. One point Clay Shirky makes, is that  the various web2.0 tools make failing cheap.

If in the 80s you had an idea for a group to form, you had a lot of things to do, many of which cost money: Finding a room to meet, printing fliers or ads to promote your idea and so on. If your idea failed, all that money was wasted.

Compare that to the situation today. Create a webpage, and promote it using facebook, twitter, xing or many of the other tools is free. All you have to invest is your own time. If it fails, nothing is lost. Actually something that fails today might get picked up tomorrow by somebody else and brought to success. Like a wikipedia article which is a stub at first, but then evolves in a well written article, through many mostly small changes an improvements. If one of the changes is bad, again the cost of this is minimal. Somebody will notice it and revert the change. Cost: a couple minutes of online time for bad article and 5 minutes work. Compare that to a typo in a printed encyclopedia. Fixing a typo would cost thousands of euros. So it won’t get fixed until the next revision which might take years to come.

So where is the relationship to the title of this post, namely the ISO 9001? One of the corner stones of modern quality management is to prevent errors to happen. This is a good thing under the assumption that fixing errors is way more expensive then preventing them. For building a car, this is probably still true: “Oh the brakes didn’t work? Probably because we installed any in the first place. Let me fix that right away. What do you mean, you don’t want them anymore? Oh you are dead … I see.” But for building software, for creating documentation for the software, for gathering requirements of the software, this assumption is wrong in many cases.

I am trying to write clean code, tested code, working code all the time and I expect my coworkers to do the same. But that doesn’t prevent me from checking in less then perfect code into the version control system. Because as soon as it available for others to see and to use, they might find bugs, or even fix some. They might provide feed back for improvement or further development of the piece. I would not accept a rule that disallows less then perfect code (or documentation) to be seen by others.

So, is ISO 9001 obsolete? I’d say NO for the following reasons:

• While it is OK to have broken stuff around, it is not OK to leave it that way. An implementation of ISO 9001 may help with making this clear for everybody.
• The agile / social media way of doing things does lead some people to the impression that it is OK to write crappy software. Although it is hard to understand how they come to that conclusion when reading the agile manifesto or any of the well known literature on agile software development, it still happens. Fixed rules inside a company of what must be done before releasing software or any development artifact to a customer.
• While the ISO 9001 is build on the idea of preventing errors it actually isn’t hard coded in a form that requires anything like a Waterfall approach.
• Even in a software developing company there are processes that need attention and that don’t need, and maybe shouldn’t be as flexible as a wiki page (consider the processes of paying the salaries with correct taxes and all)

But there are a couple of things that pop up around ISO 9001: Lengthy specifications and lengthy review processes of that specification. Many companies like to create those, and many people seem to think they are a requirement of the ISO 9001. This is not true. The norm requires that you know what you need, before you build it. A specification of the complete system certainly fits that requirement. But since you don’t create a complete new CRM in an afternoon, you don’t need the complete specification.

If you agree with a customer on a couple of user stories to be implemented in the next two weeks, and write those down on a whiteboard or in a webbased application or on some sheets of paper, any auditor of ISO 9001 conformance will have a problem criticizing that. If you use a whiteboard, you might want to make a photo of that. And if you write it down as a Fitnesse test, the auditor will probably be impressed.

So no, ISO 9001 is not obsolete. What is obsolete are ways of implementing the ISO 9001 that are damaging the reputation of that norm.

Tools

When reading blogs you get the impression, that everybody works in high end environments, using the latest greatest distributed version control system. Writing tons of tests, before they even dream about writing actual code and of course the tests a executed by the continuous integration system after every commit, which happens about 30 times per day and developer. But when I look around in the real world, this is not what I see. Instead the way people work on their code like ancient ‘doctors’. Drilling holes in heads in the hope it will reduce the headache of the patient. It probably did. In many cases in a very final way. I urge you: Don’t let that happen to your code (or your career). Practice solid software development. And in order to help you with that I compiled a simple list of things you really really should do. Those are basic practices. If you don’t even adhere to those then I have only two possible explanations: You are not involved in software development at all. Go away, this blog isn’t for you. Or … you are a dabbler.

• Use a Version Control System (VCS). I am not even going to comment on this one.
• Commit your changes at least once a day. This does not mean you should commit what ever is on your filesystem at 5pm, but you should break your tasks in so small pieces, that you finish one or two of them on a normal day.
• Tag or label everything in the VCS you hand out to somebody outside your team (testers, salespersons and of course customers)
• Have a complete and working build script. This means you can build everything you hand of to the customer by getting the source code out of the VCS and start the script. Necessary adjustments are made in a tiny file which contains settings for the local machine. A well commented template for such a file is in the VCS. And NO, hitting the compile button in your IDE is not the same as a build script.
• You must have the complete environment necessary to run your application under your control. That means if your application needs a database, you have a database available. One per developer that is, or at least one schema per developer. If you need a queue or ten queues, you have those, again once for every developer. If you have systems that you interface to, that can’t be installed once per developer, you have mocks, stubs or similar available. In the year 2009 a single developer database for 5 developers is no longer acceptable.
• You have an extensive set of automatic Unit tests. These test should cover at the minimum the main execution paths.
• Let a Continuous Integration system execute your build script, i.e it compiles your code, executes the automatic tests and builds a setup or jar, or what ever you are deploying.
• Have a specification of what a piece of software is supposed to do, before you try to write the software. You don’t need a full specification of the complete application upfront. Maybe you have just the first user story for the first feature, or only a test. But you must have something that tells you where to go. And where not to go. Flying blindfolded is not the same as being agile.
• Adhere to a style guide that describes your naming conventions, indenting and so on. Ideally this gets enforced by the IDE and automatic tests. Fighting about the content of such code conventions is useless. Not having one is dumb. Remember that your tests are code too, so the conventions apply to tests as well.
• Document how your code is structured. It should at least describe the different layers, and the way two layers may depend on each other, and it should not allow for circular dependencies. These rules as well should be enforced by automatic tests. Even if the language you use doesn’t support packages you should use a similar concept, possibly through naming conventions.

These are my points. What did I miss?

The goal of the Agile Process Maturity Model (APMM) is to provide a framework which provides context for the plethora of agile methodologies and practices out there today.

First I was quite impressed by the BWPS ratio (Buzz Word Per Sentence). I count 6 (counting “Agile Process Maturity Model (APMM)” as one). But then I realized that this is what I would highly welcome: Context for Agile Methods. If this means we get an overview of all the process that you need if you do software development and then markers in this process landscape to indicate various Agile Methods to help with this process, that for sure would be helpful. But how would this be a ‘Maturity Model’?

So once again I had no choice but to read the complete article, including the comments. I must say, I was disappointed. What follows is basically a ranking of agile process, methodologies or what ever you want to call these. Such a ranking explains the ‘Maturity Model’ part, but it completely voids the agile part. What value can a ranking of processes have in a context where the common understanding is that processes aren’t that important anyway?

So my clear opinion is: No thanks we don’t need another maturity model, the existing once are causing enough problems. I know some of my coworkers are reading this blog and are by now probably thinking: “Interesting opinion for the quality manager of our company”. So let me explain why I think ISO 9001, SPICE, CMMI & Co are often doing more harm then good.

The problem is the same as with any kind of measurement: If you measure people or they work, they start to optimize for the measurement. For example if you start to measure code coverage and declare high coverage to be good, people will create automated tests for code that gets created automatically, although in most cases these kind of tests are of very limited use. With all the quality norms the auditors look for proofs that a certain aspect of a process gets executed as intended. This is really difficult to do, expect for the cases where documentation is created. But documentation created only for some audit is actually the exact kind of thing you don’t want to have. It costs money, gets outdated fast after the audit and has no benefit for your project, your company or the customer.

How to avoid this pitfall is a topic for a different post.

Sprachen

Das aktuelle Thema überhaupt ist sicherlich Sprachen. Durch die Allgegenwart von zwei wesentlichen Laufzeitumgebungen (JVM von Java/Sun und der CLR von .NET/Microsoft) ist es extrem einfach neue Sprachen mal auszuprobieren. Zu dem Thema empfehle ich den Artikel von Markus Völter.

Meine persönlichen Erkenntnisse dazu:

• Fast(?) nichts von den Konzepten ist neu. Die Basis für funktionale Sprache z.B. ist das Lambda Kalkül von 1930. Insbesondere das Polyglotte Programmieren ist doch längst Standard. Ich z.B. zähle in den meisten Projekten mindestens Java, SQL, PL/SQL, HTML und CSS zu meinem Handwerkszeug. Was sich ändern könnte, ist warum wir zwei oder mehr Sprachen einsetzen: Weil bestimmte Aspekte in der einen, andere in der zweiten Sprache besser darstellbar sind. Während bisher der Grund der Mangel an Alternativen ist. (Ja ich weiß, man kann auch in Oracle mit Java arbeiten. Aber wer das einwirft hat es noch nicht ernsthaft ausprobiert).
• Wir werden uns damit beschäftigen müssen. Heiße Kandidaten für die praktische Anwendung sind für mich: Groovy und Scala.
  Auch spannend finde ich Haskell. Ich habe vor vielen Jahren an der Uni Miranda gelernt und hätte nie gedacht, dass dies mal im Berufsleben relevant werden könnte.
  Als Physiker, der einmal intensiv mit Fortran gearbeitet hat finde ich auch Fortress sehr beeindruckend. Dies Sprache kann zumindest für Mathematiker und ähnliche sehr leserlich gerendert werden und ist speziell auf (massiv)parallele Ausführung ausgerichtet.

Womit wir bei einem weiteren Thema sind:

Concurrency

Das Moore’sche Gesetz als Basis des Quaketunings (18 Monate Quake spielen, schon ist die Anwendung doppelt so schnell) ist am Ende. Als ‘horizontale Ausweichbewegung’ werden uns von AMD und Intel Mehrkern CPUs auf den Schreibtisch gestellt. Dadurch geraten überall Leute in Panik, existierende Anwendungen würden nun wie die Fliegen von den Wänden fallen, da Threadingprobleme sich nun manifestieren.

Nun ja, ich weiß nicht was für Anwendungen ihr schreibt, aber ich schreibe beruflich entweder Swing oder Webanwendungen, die auf Datenbanken gehen. Nur ein sehr kleiner Teil der Arbeit steckt in komplexen Algorithmen, und ich habe noch nie etwas davon parallelisiert. Datenbanken und Webserver laufen ’schon immer’ auf Mehrprozessormaschinen. Es sind heute halt 512 statt 16. Die Art und Weise wie dort Parallelverarbeitung eingesetzt wird, ist extrem einfach und daher handhabbar: Jede Anfrage bekommt einen Thread, und darf ihn für sich alleine verwenden, bis die Anfrage abgearbeitet ist. Zumindest sieht es aus der Sicht des Entwicklers so aus.

Nur in Swing muss man typischer Weise mit mehreren Threads arbeiten, da lang laufende Aktionen sonst die Darstellung der Anwendung blockieren. Dies wird man aber wenn irgend möglich minimieren, da jeder der Doug Leas Buch gelesen hat, weiß wie schwierig Concurrency ist.

Viele der neuen Sprachen haben aber Konstrukte, die die Verteilte Ausführung unterstützen und es ist ja nicht so, dass wir die nicht zu nutzen wüssten. Unabhängig von der Anzahl der Prozessoren gibt es nämlich einen Bereich, in dem Concurrency eine Rolle spielen sollte: bei dem Zugriff auf verteilte Ressourcen. Egal ob es die Datenbank oder der entfernte Web Service ist, wenn wir eine Anfrage abschicken und warten, bis die Antwort kommt, bevor wir die nächste Anfrage lostreten verschwenden wir mindestens Zeit, und meist auch wertvolle Ressourcen (mindestens den wartenden Thread). Je nachdem wie knapp die Ressourcen sind, wird man früher oder später genötigt sein, die Anfragen parallel anzustoßen und anschließend die Ergebnisse zusammenzuführen. Schön wenn die Sprache mit der man dies tut, ein solches Vorgehen angemessen unterstützt.

Security

Es gibt immer wieder Stimmen, die meinen, Security würde jetzt DAS große Thema. Vertraut mir, wird es nicht. Genauso wenig wie Gasmasken oder Panzertüren DAS große Thema werden. Aber Security ist ein Dauerbrenner, den niemand ignorieren sollte. Oder schließt ihr euer Auto und eure Wohnung nicht ab? Daher gab es auch auf der JAX Vorträge zu diesem Thema.

Für mich die wichtigsten Punkt waren dabei:

• * Der Deming Zyklus gilt auch hier. D.h.
  • Plant was eure Sicherheitsziele sind und was ihr dafür tun müsst. Wollt ihr euch gegen Skriptkiddies schützen? Oder haltet ihr die NSA für euren Feind? In letzterem Fall könnte aber auch ein Psychater helfen
  • Führt die Maßnahmen durch.
  • Prüft, ob die Maßnahmen wirksam sind.
  • Wenn die Prüfung negativ ausfällt, reagiert darauf.
• Schwierig an dem Security Thema ist, dass selbst gigantische Sicherheitsprobleme nicht von allen erkannt werden. Wenn ich in mein Haus eine Tür aus Pappe einbaue, brauche ich keinen Experten um zu erkennen, dass das eine schlechte Idee ist. Bei Software ist das ganze deutlich weniger offensichtlich. Ich habe die privaten Schlüssel für Zertifikate schon gemailt bekommen. Daher gibt es eine ganz wichtige Aufgabe, wenn eine Anwendung ’sicher’ werden muss: Awareness schaffen. Alle Beteiligten (Entwickler, Designer, Tester, Administratoren, Anwender, …) müssen in Sachen Security geschult werden. Denn was nützt die schöne Sicherheitsarchitektur, wenn der Benutzer seines Sohnes Namen als Passwort verwendet und das auch noch per E-Mail verschickt und auf den Monitorrahmen schreibt?
• Security heißt nicht einfach Benutzer Authentifizierung und Authorisierung sondern durchdringt den gesamten Entwicklungsprozess.
  • Bei der Analyse müssen die Anforderungen aufgenommen werden.
  • Diese müssen bei der Architektur und dem Design berücksichtigt werden.
  • Es muss natürlich implementiert werden,
  • aber auch getestet,
  • deployed
  • und genutzt

  Und wie ich oben skizziert habe, gibt es auch in den Bereichen Herausforderungen, wo man sie normalerweise vielleicht nicht erwartet.

Architektur

Ist ein weiterer Dauerbrenner, und ähnlich wie bei Security lautet hier mein Hinweis Deming Circle! Eine Architektur hat eine Aufgabe zu erfüllen. Die Aufgabe sollte vorher klar sein und nachher muss geprüft werden, dass die Aufgabe gelöst wurde. Ansonsten ist Architektur ein Unfall oder Selbstbefriedigung des Architekten.

Durch das Thema Nr.1 ‘Sprachen’ gewinnen wir gerade im Bereich Architektur gerade gewaltig an Möglichkeiten:

• Unterschiedliche Sprachen für unterschiedliche Bereiche.
• DSLs für Spezialfälle
• AOP oder spezielle Sprachstrukturen für die Umsetzung von Architekturentscheidungen

SOA und BPM

Viel Hype und (fast) nichts dahinter.

Das 5. Element (Quintessenz)

Die Probleme bleiben die alten. Die Lösungen sind auch nicht neu. Die Zeiten bleiben interessant.