Erik made a real good comment on that article:

“Start learning how to test today”

Do you have any good resources?

“Most of the code we produce isn’t fizz buzz, but is concerned with GUIs and databases, both make testing hard and expensive. But these problems can be solved, so you can gain the benefit of TDD even for these cases.”

How?

I’ll try to answer the first question today, the other one will have to wait.

TDD encourages good design (at least on the class level), because code that isn’t nice and modular is hard to test. Therefore I recommend as a first resource the best book I have read on that topic: Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin also known as Uncle Bob. Actually you should as much stuff written by him as possible, e.g. his principles of OOD. If you are into twitter you might follow him there

There are plenty of books about testing, but I have to admit I wasn’t tremendously impressed by any of them. But they are still usefull.

A good introduction into TDD is Test Driven Development. By Example (Addison-Wesley Signature) by Kent Beck. This book is for TDD beginners. Although the two examples he is working on through the book aren’t trivial they do have the appearance of examples and probably differ a lot from what you’ll find in real life. But in every topic you start with simplified tasks in order to get started. For this purpose I can recommend this book.

The first book I read on this topic is Test Driven: Practical TDD and Acceptance TDD for Java Developers by Lasse Koskella. It starts with very simple stuff, but also covers things like acceptance tests and mocking frameworks. There is one tip from the book that I remember especially well: Don’t access thing like the system time directly, but use a simple service which implements a simple interface. If you do so you can stub/mock that service which helps tremendously when testing time dependent code. Without this, how are you planning to test that your code works correctly across the change from daylight savings time and back?

Possibly the best book about testing I read so far is Working Effectively with Legacy Code by Michael C. Feathers although it actually isn’t focused on testing in itself. He writes about legacy code which he defines as code without test. So I guess for many of us this is most of the code we are dealing with on a day to day basis. Most strategies he describes are about bringing convoluted code bases under tests. Very helpful, although I’d wish I’d never need these strategies. Although the code examples in the book are shortened to fit into a book you can ‘smell’ the bad code found in real world projects.

Of course I haven’t read everything available about testing. So there is still stuff on my whish list, like for example Growing Object-Oriented Software, Guided by Tests.

All the reading doesn’t help as long as you don’t put the stuff you read about into action. So start writing test. For the start stay with simple stuff. Where you can immediately write down the test. You might wonder if the test is worth the effort for such trivial code. But remember you are trying to learn. And learning is done by practicing over and over again. You will find situations where you realize writing the test isn’t as easy as you thought. Try to write the test anyway. Try to find a solution for the testing problem. Ask at stackoverflow how to solve the issue.

Learn a testing framework. Learn a second one. Learn one in a different programming language. A long the way you will learn a lot about different styles of testing and different solutions to problems.

Learn a mocking framework. I’d recommend Mockito. Try not to use it. Find out why using a mocking framework might be a sign of bad design.

Enjoy the ride. And add recommendation as a comment.

Why it isn’t perfect:

• It’s bound to Amazon. Everything in the kindle is geared to buy from Amazon and to be bound to Amazon the content is encumbered with Amazons DRM. This isn’t much of a problem right now, but I don’t like that situation a bit.
• It’s not an iPad. Don’t get me wrong, I’m not much interested in an iPad. If I would win won, I would be happy to sell it and to buy books for the money, but It would be cool if the kindle would have the fast color display, touchscreen and a sensor to tell it its orientation in space.

But the kindle is awesome because it is the perfect gadget for the purpose for which I bought it: Reading.

• The kindle is small and light. You can hold it for a long time in one hand, e.g. while walking. Try that with an iPad.
• It has a display that is so paper like that I actually thought it would be a piece of paper I had to pull of before using the kindle when I unwrapped it. You can read in in bright sunlight at an angle at which a normal computer screen would act like a mirror
• You can put it to the side for 5 seconds or 5 days without worrying about the page you where reading. Great if you want to read near kids who ask a question approximately every 12.57 seconds.
• Kindle books are cheap. This might confuse you because a lot of people complain that Kindle books are only a little cheaper than hard covers and more expensive than paper back editions. But if you buy English books at Amazon.de you pay the american price for the kindle book which is in many cases way cheaper than the German book price.

One complain you often here is that the handling of PDFs and other document formats is bad. Well it depends on what you expect. PDF is a page oriented format without any semantic information. For example a footnote is just a piece of text inside PDF an in no way tied to the place where the footnote is referenced. If you convert such a format to the kindle format you get some not so nice effects, but it was absolutely usable in about half a dozen cases where I tried it. If the layout is to complex, possibly with tables and graphics you can read PDF directly without converting it, which works ok, when holding the Kindle sideways. It will enlarge the PDF so the width fills the screen. And ‘turning the page’ will actually scroll down the page in about two steps before actually proceeding to the next page. Again not perfect, but absolutely usable.

So if you read a lot and are interested in English Tech Books or old Classics (which are often free) chances are you want a Kindle.

Presentation Zen Design: Simple Design Principles and Techniques to Enhance Your Presentations (Voices That Matter) is the follow up on Presentation Zen: Simple Ideas on Presentation Design and Delivery (Voices That Matter) which I loved and which changed the way I do presentations. While Presentation Zen is one extremely important book for me, Presentation Zen Design was a little weak. A lot of stuff I already knew, plus to much on the design side which I can’t apply. Not a bad book but not really for me.

How Would You Move Mount Fuji?: Microsoft’s Cult of the Puzzle — How the World’s Smartest Companies Select the Most Creative Thinkers is a fun read about the interview questions they supposedly ask at microsoft and other places. As a preparation for such interview it is probably pretty useless, but it is fun to read, especially when you like logic puzzles.

Domain Specific Languages (Addison-Wesley Signature) by Martin Fowler. As often with books by Fowler there is not much an experienced developer doesn’t know yet or can’t find in other books. BUT he once again assembles a complete set of patterns, describes them and gives names to them. While this doesn’t sound like much it helps a lot in evalutating your options when considering a DSL. I also learned a lot about parsing, lexing and so on. Good book. Must Read.

Test Driven Development. By Example (Addison-Wesley Signature) is a great introduction into TDD. If you are not practicing TDD yet, you should read this. But if you already read another book about that topic, you might skip this one.

Drive: The Surprising Truth About What Motivates Us is simply a great book. It showed me a lot of things that motivate me, which is great because now I can at least to some extend use that knowledge to improve my life. I also recommend this book for everyone who is or wants to be the boss of someone. If you really can’t read the book, here is my personal essence from it: Bonuses don’t work. Read the book if you want to know why.

Lean Software Development: An Agile Toolkit for Software Development Managers is one of the many books I read about lean and agile and stuff. Its good. Its written by the Popendieks which shows. I especially liked the chapter about the effect of contract design on the relationship between supplier and customer.

Don’t Make Me Think!: A Common Sense Approach to Web Usability a guide to pragmatic user interface design. It’s simple. It’s easy to read and it even shows how to do actual usability testing when you are one a tight budget.

Extreme Programming Explained: Embrace Change adds what is missing in many books about agile software development: practices of solid, high quality software development (as opposed to practices revolving around the organization of work). When you want to learn about agile, this is one of the two books you need to read as a developer.

Agile Software Development with Scrum is the other book you must read when you are interested in agile. While it is focused on Scrum, it does a great job in explaining why scrum works the way it is. This is helpful no matter what method you use.

Getting Things Done. The Art of Stress-Free Productivity shows simple little process that will lead you to higher productivity. At least it did that to me. While my productivity isn’t nearly where I would like it to be, I at least know the things to tweak in order to get better. Must read when you are constantly feel like you day needs at least three extra hours.

Programming in Scala … well the readers of my blog noticed, that I’m fooling around with scala a lot lately. This is one reason and the foundation of my fooling. It’s a good book, although I have to admit I don’t know other Scala books yet, so I can’t make a comparison.

Structure and Interpretation of Computer Programs (Mit Electrical Engineering and Computer Science Series) is possibly the most interesting read during the last year and I’m actually not finished yet. This book gets either great or awful revisions at amazon. The reason is simple: It’s not an easy read. It is not easily applicable. The chances of direct application of your new skills in the job are extremely slim. BUT no matter how much programming and software development you did, if you read this book you will learn a lot. For example you will learn how much you can do in a language without using assignement. And you will only notice this on page 200 something when assignment is introduced. So I am absolutely on the 5 star side of this book. Must read for everybody who really wants to push his understanding of programming and programming languages.

So that is my (not complete) list of the somewhat IT related books I read during the last 12 months. There where lots of helpful books in the list. I hope it will be the same during the next 12 months. Ok I’ll head over to amazon and order another book. Enjoy the new year.

Design Patterns. Elements of Reusable Object-Oriented Software: This is the standard book on patterns and patterns are an extremely important piece of vocabulary for every developer. Not to impress coworkers with your knowledge, but to be able to think about bigger concepts than loops and conditionals. It describes each pattern with its purpose, it’s applicability and an example. Make sure to read a couple of blog posts about each pattern, to make sure you avoid some of the more common mistakes when applying them.

Clean Code: A Handbook of Agile Software Craftsmanship: You want to be proud of your code? You want to be able to go back to your code in a year without swearing? This is the book for you. The author Robert C. Martin (also known as Uncle Bob) is extremely aggressive on what he is accepting as clean. This book really changed the way I look at code, and of course the way I write code. Make sure to really understand the lengthy examples. It is tedious, but it pays.

The Pragmatic Programmer. From Journeyman to Master: In Software Development the professionals often follow practices which the professionals them selfs aren’t aware of. This book lists and explains many of these practices as well as some obvious once. While this sounds trivial the resulting book is a great source of small and big practices to acquire as a habit.

For the German readers of my blog: Read the english originals. German translations of computer books are horrible on average.

Agile Software Development with Scrum by Ken Schwaber: Obviously this book is about Scrum, which is just one of many agile processes. But even if you don’t want to go with Scrum, this book will teach you a lot about why Scrum is designed the way it is, and this will be very helpful, no matter what approach you choose. Be warned: the book is small, has crappy graphics and is rather expensive. But it is worth it’s money.

Lean Software Development: An Agile Toolkit by Mary and Tom Poppendieck: This book isn’t tied to any specific process or approach, instead it describes the underlying concepts, which are common to all agile approaches. And these are the ones that really count. Since the Poppendieck have a lot of experience in non software projects they provide lots of examples an cross references which might help convince a stubborn manager, who doesn’t realizes that doing waterfall software development might be 10years behind standards in software development, but is about 50 years behind when compared with other branches of industry.

Management 3.0: Leading Agile Developers, Developing Agile Leaders by Jurgen Appelo: Unfortunately you can’t buy the book yet. But I had the honor to review an early version of the book and provide Jurgen with my nit-picky comments. This book is very different from the other two, because it focuses completely on the management side of things. Agile doesn’t mean managers will go away, they don’t even become useless. Quite the different, they might actually put themselves to good use, and this books will tell you (or your boss) how. Even if you don’t go fully agile, this book will offer lots of advice and ideas, on how to improve you work as a manager.

I like the concept, but it does not work for me. I read in a lot of different places and I read about 2-5 books or magazines in parallel most of the time. I do not want to carry those around all the time. In fact I read so many things in parallel because I don’t want to carry the books around. Instead I try to have a book at every place where I might want to read. One in the bed room, one in the bath, one in the living room, one at the office at LINEAS and one at the desk at the customer for the lunch breaks. And last night I had to buy a new one because I was traveling by train and hadn’t a book yet for that place.

No matter if you are more like jurgen or more like me, or if you are one of these weird people that read one book at a time: Use Tools for Reading. At least when you are reading in order to learn something, you should use the following tools:

1. a transparent ruler. Hold it under the current line. It will prevent you from loosing the line, and thereby enables faster reading. If a ruler is not available, a pen or a sheet of paper might work as well.
2. a pen. Put down notes. Put them on the margin of the book if you like or on post its, or on a seperate sheet of paper. Whatever, in my experience taking down notes, writing a short summary on after every chapter is the single most effective thing to prevent information to fall out of your ears, while you take it in through the eyes.

Reading is such an important thing, there really should be more discussion about how we do it. So what are your reading tips?

Andererseits hat die klassische Netzplantechink durchaus etwas für sich. Der Argumentation: Wenn A von B abhängt, kann ich erst mit A beginnen, wenn B abgeschlossen ist, leuchtet ein. Und so mancher Vertreter der Agilen Methoden verwechselt wohl agil mit chaotisch.

Leute die Worte wie Agil, Iterativ und Inkrementell nutzen, aber nicht erklären können machen die Sache auch nicht besser.

Ich habe jemanden gefunden, der nicht nur diese Unterscheidungen kennt, der weiß wie man in agil geführten Projekten plant und schätzt, sondern der darüber sogar Bücher geschrieben hat. Mike Cohen. Na gut, ich habe ihn nicht persönlich kennengelernt, aber ich habe zwei seiner Bücher gelesen: “Agile Estimating and Planning” und “User Stories Applied”.

Beide Bücher kann ich empfehlen, obwohl ich nicht empfehlen würde beide Bücher hintereinander zu lesen, wie ich es getan habe. Dafür ist die Schnittmenge des Inhalts zu groß.

Genug der Werbung: Wie plant nun das agile Projektmanagement? In letzter Instanz nicht so viel anders, als das klassische Projektmanagement, wenn es richtig gemacht wird. Es wird das geplant was planbar ist, und was für eine erfolgreiche Weiterarbeit notwendig ist. Bei der klassischen Netzplantechnik ist es naheliegend alle Aktivitäten gleich detailliert zu planen, obwohl dies weder realistisch noch förderlich ist.

Mike Cohen empfiehlt getrennte Planungen für unterschiedlichen Planungshorizonte: Projekt, Release, Iteration, Tag. Dadurch wird auch gleich ein weiterer typischer Fehler von klassischem Projektmanagement vermieden: Bei Projektbeginn wird der Projektplan erstellt und dann allenfalls mit dem Projektfortschritt aktualisiert. Klar, dass der bald nichts mehr mit der Realität zu tun hat. Aber wenn der detaillierte Plan nur bis zum Feierabend reicht, dann kommt man nicht drum rum am nächsten Morgen einen neuen Plan zu machen. Das gleiche gilt für die Pläne auf Iteration und Release Ebene.

Damit wird das Möglich, was für mich ein ganz wichtiger Aspekt der agile Projektarbeit ausmacht: Embracing Change (Änderungen umarmen?) d.h. Änderungen der Ziele und Vorgaben werden nicht als Störung des Projektes betrachtet, sondern als integraler, willkommener Bestandteil des Projektgeschäftes.

Aber was passiert mit den heiß geliebten Gantt-Charts und der Netzplantechnik? Diese sind tatsächlich hinfällig. Als Ersatz für die Abhängigkeiten im Netzplan werden die Anforderungen (Stichwort: User Stories) so gewählt, dass sie möglichst unabhängig voneinander sind. An dieser Stelle wird die Sache meiner Meinung nach wirklich spannend. Warum meint die Softwarebranche ohne diese Abhängigkeiten zurecht zu kommen, obwohl andere Branchen seit Jahrzehnten darauf schwören? Weil bei (gut geschriebener) Software jeder Teil geändert werden kann, ohne dass dies nennenswerte Auswirkungen auf andere Teile hat, während dies bei klassischen produzierenden Gewerbe unmöglich ist.

Man stelle sich mal vor, bei einem fertigen Gebäude soll das Fundament ausgetauscht werden … unmöglich, unbezahlbar. Bei einem Programm die Persistenzschicht austauschen? Kein wirkliches Problem, natürlich müssen beide Varianten der Persistenzschicht entwickelt und letztendlich bezahlt werden, aber bei dem Rest des Programm sollte sich recht wenig ändern. Während das klassische Gebäude wohl komplett ab und wieder neu gebaut werden müsste. Dadurch ist es möglich die Bestandteile in beinahe beliebiger Reihenfolge zu erstellen. Im Umkehrschluss bedeutet dies aber auch, Projektanteile die nicht so flexible disponiert werden können, müssen entsprechend langfristig geplant werden. Know How in diesem Bereich ist also nicht verloren.

In allen anderen Bereichen geht es meist um eine verschobene Gewichtung: Wenn Plan und Realität auseinander gehen, wird dies eher über Anpassung der Ziele, d.h. des Projektumfangs aufgefangen, als durch Veränderung des Arbeitsvolumens. Dabei trifft der Kunde die Entscheidung was genau gestrichen oder angepasst werden sollte, anstatt wie ich es oft erlebt habe Grabenkämpfe um die Übernahmen der Kosten zu führen.

Löst das alle Probleme? Ganz sicher nicht. Letzten Endes geht es in Projekten um Geld und da wird es Konflikte geben. Aber ich bin überzeugt, fast alle Projekte könnten von einer kleinen oder größeren Prise ‘Agile Estimating and Planning’ profitieren, nicht nur Softwareentwicklungsprojekte. Und wenn unsere Kunden das Buch lesen würden, könnten wir sie eher davon überzeugen gemeinsam ein Projekt zu machen anstatt gegeneinander.

Na gut, aber nur weil man nichts besonderes ist, kann man ja trotzdem mal reinschauen. Leider war kein Inhalt drin. Versteht mich nicht falsch: Seiten waren schon drin. Es standen auch Buchstaben und Bilder drauf, aber Inhalt war nicht dabei. Etwa ein Drittel der Seiten sind großformatige Werbung. Ganzseitig oder doppelseitig. Und wenn der Rest im Fernsehen liefe würde ständig ‘Dauerwerbesendung’ eingeblendet werden.

Keine Spur von Kreativität, bis auf das Geschäftsmodel. Wenn man nämlich nach dem Verlag googelt landet man bei einer Werbeagentur. Anstatt also wie üblich zu Inhalt passende Werbung zu suchen, oder für Werbung passenden Inhalt, haben die einfachWerbung mit Werbung kombiniert und verkaufen das ganze jetzt.

Falls euch die Zeitschrift interessiert … ich habe mein Exemplar schon weggeschmissen, aber das Oracle Magazin verfolgt ein ähnliches Konzept. Leider ist es kostenlos und durch die schlampige Redaktion schleichen sich eigentlich immer 3-4 Seiten Inhalt rein.

Man muss den DBAs und Datenbankentwicklern zu Gute halten, das selbst Martin Fowler refaktorn von Datenbanken für besonders schwierig hält und es daher dieses Thema in seinem Buch “Refactoring” mehr oder weniger vollständig ausgeschlossen hat. Dieses Thema haben mittlerweile andere bearbeitet und seit einigen Jahren ist eine gesondertes Buch zum Thema Refactoring von Datenbanken verfügbar. Ich halte dieses Buch für sehr wichtig und lesenswert und es sei allen, die mit Datenbanken zu tun haben dringenst an Herz gelegt.

Allerdings muss ich den potentiellen Leser warnen. Die Autoren Scott Ambler und Pramodkumar Sadalage haben keinen Trick auf Lager, wie sie Änderungen von Datenbanken zwischen den verschiedenen Instanzen synchronisieren. Bei Änderungen an Datenbanken müssen sehr oft auch Daten aktualisiert werden und dies geht nur mit dem Wissen um diese Daten, dies kann nicht automatisiert werden. Es wird hier also korrekter Weise auf die manuelle Pflege von Skripten verwiesen. Leider hat sich die Hoffnung der Autoren bisher nicht erfüllt, dass leistungsfähige Tools für die Unterstützung dieser Aufgaben entstehen. Es gibt zwar mittlerweile einige, die Skripte verwalten, feststellen welche noch eingespielt werden und diese einspielen oder zu einen SQL Script zusammenführen. Aber diese Tools fühlen sich an wie ein Faustkeil, wenn man Werkzeuge wie IDEA oder Eclipse gewohnt ist.

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.