Design happens
Was passiert, wenn man mit seinen Kollegen Freitag Abend ausgeht? Natürlich, man landet in Diskussionen über die Arbeit und das ganze drum herum. Eine der zwei großen Diskusionen gestern Abend ging dann um Feature-based Programming (gibts sogar ein Buch drüber
) und das ganze drum herum. Dabei viel dann meine etwas unbedachte Äußerung Design happens, was die ganze Diskusion noch mal um eine Stunde verlängert hat und weil das ganze so viel Spass gemacht hat wollte ich es doch noch mal hier zusammenfassen.
Was heißt also Design happens? Grundsätzlich ist es wie mit den Affen und Shakespeare, nur auf einem anderen Niveau: wenn man eine Menge an guten Programmieren nimmt (ein Projektteam), ihnen sagt was sie tun sollen (die Featureliste), dann entsteht das Design von ganz allein. Ein guter Programmierer sei hier also als jemand der sich auskennt definiert, der Best Practices kennt und eine gewisse Erfahrung mitbringt, also dazu neigt guten, wartbaren und modularisierten Code zu schreiben, weil das richtig ist und mittelfristig den Arbeitsaufwand verringert. Die Position des Architekten und ein Upfront-Design ist also hinfällig. Der iterative Ansatz des Softwaredesigns (die bekannten Stufen) ist also hinfällig, da es bei FBP nicht mal ein Design-Dokument im eigentlichen Sinne gibt. Das Design ergibt sich somit quasi aus und während des Entwicklungsprozesses und wird nicht vorgeschrieben, es passiert einfach.
Was heißt Design happens nicht? Es heißt nicht das das Design unwichtig ist oder einfach so da ist. Das Design wird natürlich von den Entwicklern abgesprochen (”Chinese Parliament”) und basiert auf Vorkenntnissen und Vorarbeit, die allerdings nicht auf einem Stück Papier steht sondern halt aus den Entwicklern an sich kommt.
Im Grundsatz ist es also so, das gute Software nicht durch einen möglichst förmlichen Entwicklungsprozess entsteht, sondern durch Freiheit und klar definierte Aufgaben. Das ganze Drum herum entsteht aus der Notwendigkeit die Aufgaben und somit die Features möglichst gut und ästethisch (aus der Sicht eines Programmierers) zu lösen.