Author Archives: hhensel

Refactoring, Merkmal professioneller Softwareentwicklung

Als Refactoring bezeichnet man die Veränderung von Quellcode, ohne dass sich das Verhalten der betroffenen Software nach außen ändert. Der geneigte Kunde, Auftraggeber oder Nutzer fragt sich daher oft, was das Ganze soll. Die Antwort ist einfach, aber nicht trivial: Durch Refactoring wird bestehender Code für Entwickler besser verstehbar und ist daher besser wartbar. Zukünftige Veränderungen werden hierdurch leichter, oft sogar überhaupt erst sinnvoll möglich. Warum aber schreiben Entwickler Software dann nicht von Anfang an so?

Stellen Sie sich vor, Sie schreiben einen wichtigen Brief, einen Artikel oder gar ein ganzes Buch. Sie werden mit einem Entwurf beginnen und sich nach und nach an die endgültige Fassung heran tasten. Ihnen ist klar, dass es unmöglich ist, die endgültige Version in einem Rutsch zu schreiben. Und selbst nach Fertigstellung werden Sie hier und da noch Stellen finden, mit denen Sie unzufrieden sind oder die Sie heute anders schreiben würden.

So verhält es sich auch mit der Softwareentwicklung. Man beginnt mit einer ersten Planung, welche die Strukturen der Software darstellen. Sobald diese fest stehen, werden die einzelnen Bestandteile erstellt und zu einer lauffähige Software zusammen gebaut. Hierbei neigt man dazu, relativ große und unübersichtliche Codeblöcke zu schreiben, welche man im Moment hervorragend überblickt. Kommt man aber nach zwei Wochen wieder an diese Stelle, weiß man kaum mehr, worum es geht oder was die Software an dieser Stelle tut. Geschweige denn, wer “diesen Wust verzapft hat”… 😉

Als Autor muss man also nach der ersten Fertigstellung des jeweiligen Softwarebereichs (oder eben des Abschnitts im Buch), diesen überarbeiten, so dass er auch in Zukunft und von anderen Entwicklern leicht verstanden werden kann. Ebenso achtet man darauf, dass man eine ordentliche Struktur hinterlässt. Sie würden sicherlich auch kein Buch gutheißen, indem zusammengehörende Informationen über verschiedene Kapitel verstreut sind und welches nur schwer und holprig zu lesen ist.

Der einzige Grund, kein Refactoring durchzuführen ist, wenn bestehende Software einwandfrei funktioniert und nicht mehr verändert wird. Dann liest auch niemand mehr den Quellcode oder muss diesen bearbeiten. Da wir Software aber wiederverwenden können wollen, ist dies eigentlich nie gegeben und Refactoring gehört zu einem professionellen Workflow immer dazu.

Nun habe ich diesen Artikel noch einige Male gelesen, verändert und hoffe er ist halbwegs verständlich. Sie werden aber bestimmt noch den einen oder anderen Fehler finden und stolpern vielleicht über manche Formulierung. Verstehen Sie, was gemeint ist… ?

Blog: Mehr als 250 Tausend im Sand

In einer Firma wurden rund 250 Tausend Euro investiert, um eine tolle neue Softwareidee zu verwirklichen. Einerseits wurde vor lauter Begeisterung bei den Investitionen nicht so genau auf die sinnvolle und ausbaufähige Umsetzung geachtet. Andererseits gab es auch nicht wirklich jemanden, der dies hätte beurteilen können. Nach 9 Monaten wurde dann leider klar, dass notwendige Änderungen nicht mehr effektiv möglich waren. Es wurde eine komplett neue Version des Softwareproduktes aufgesetzt und man hatte diesmal Unterstützung von Spezialisten, welche auf zukünftige Erweiterbarkeit und solide Entwicklungsarbeit drängten.

Alles verlief gut, die Entwicklung war deutlich günstiger als zuvor und man war noch einmal mit einem “blauen Auge” davon gekommen. Da es nun wieder voran ging, war man der Meinung sich von den Spezialisten trennen zu können. Es wurden junge, engagierte Mitarbeiter gefunden, die Lohnkosten sanken und man war zuversichtlich. Nur der Blick auf den Quellcode des Softwareprodukts hätte dem Fachmann verraten, dass die geschaffenen Grundlagen für Erweiterbarkeit und Wartbarkeit des Projekts mehr und mehr verloren gingen.

Engagement und Zuversicht alleine reichen nicht. Es braucht auch einige Erfahrung und viel Disziplin, um gemachte Fehler nicht zu wiederholen.

Szenarien wie das oben beschriebene sind beileibe kein Einzelfall. Seien Sie sich dessen bewusst und handeln sie entsprechend.

Blog: Einfach kompliziert

Auf der täglichen Suche nach Wissen, stolpert man im Internet über sehr viele Informationen. Es gilt hierbei, so schnell wie möglich die Spreu von Weizen zu trennen, um sich effektiv zu informieren. Darauf kommen wir bestimmt bald wieder zurück, aber vor einigen Tagen haben wir eine kleine, vermutlich unbewusste, aber vielsagende Bemerkung gefunden, welche wir doch mit Ihnen teilen möchten. Sinngemäß stand im WWW geschrieben:

“Dies zu erklären, ist eigentlich sehr einfach,
man könnte zwar ganze Bücher darüber schreiben,
aber ich beschränke mich auf das Wesentliche.”

Das trifft es doch sehr genau: Meist werden die einfachsten Dinge unglaublich verkompliziert. Wenn denn in Antworten überhaupt auf die ursprüngliche Frage eingegangen wird. Oft wurde diese vom Antwortenden nicht einmal verstanden oder falsch interpretiert. Menschen neigen eben dazu, viel zu sagen und oft leidet die Qualität der Aussagen darunter. Gesprächspartner schalten dann umso schneller ab und eine effektive Kommunikation ist schwer möglich.

Es gibt den Spruch (gerade für das Internet gültig): “Erst denken, dann noch einmal denken, und erst dann sprechen bzw. schreiben”. Wie wahr, wie wahr…

Auch wir bemühen uns diese Regel einzuhalten und haben damit manchmal noch unsere Probleme. Wir sind uns dessen aber bewusst und sie findet sich wieder im KISS Prinzip, welches definitiv zu unseren eigenen Richtlinien gehört.

Blog: Hohe Ansprüche, wenig Resultate

Mal wieder war es soweit. Ein Treffen zwischen Auftraggeber und Softwareentwickler stand an. Je zwei Teilnehmer beider Seiten sollten alle noch offenen Fragen klären.

Die Auftraggeber hatten extra einen wichtigen Termin verschoben und eineinhalb Stunden für das Treffen reserviert. Nach hinten war auch noch Luft, daher war es nicht ganz so schlimm, dass sie erst um 13:15 vor Ort eintrafen. Der vorige Termin hatte wieder einmal etwas länger gedauert.

Das Entwicklerteam wartete seit 13:00 Uhr im Besprechungsraum, nahm die Entschuldigung für die Verspätung dankend an und öffnete einige Dokumente, welche mittels Projektor an die Wand geworfen wurden. Es ging los, die Stimmung war gut.

Zwei Stunden später, die Situation ist hektisch, die Sicht der Auftraggeber:

Die beiden Entwickler waren knapp mit der Hälfte der im Vorfeld als E-Mail versendeten Punkte ihrer Liste fertig. “Punkte” war sowieso das falsche Wort – “Kapitel” oder “Abhandlungen” wäre treffender. Einer der Auftraggeber war gerade gegangen, sie hatten sich entschieden, dass den nächsten Termin auch einer alleine bewältigen könnte. “Wie lange soll das noch dauern?” dachte der Verbliebende. “Warum machen die Beiden es so kompliziert?” Er konnte sich kaum noch konzentrieren – die Flut von Detailfragen empfand er als unnötig und übertrieben. Gleichzeitig hatten er mit seinem Partner versucht noch zwei kleine Änderungen einzubringen, von denen eine mit sichtlichem Unmut akzeptiert wurde, die andere aber gleich als “jetzt nicht machbar” auf später verschoben wurde. Eigentlich gab es nur noch die eine unausgesprochene Frage:

“Warum kostet das alles soviel Zeit und Geld? Wie sollen wir so unsere Pläne verwirklichen?”

Das kommt Ihnen bekannt vor? Hier geht es zu Lösungsvorschlägen!

Blog: Große Erwartungen, wenig Zeit

Mal wieder war es soweit. Ein Treffen zwischen Softwareentwickler und Auftraggeber stand an. Es sollten nun endlich alle noch offenen Fragen geklärt werden.

Das Entwicklerteam traf sich um13:00 Uhr im Besprechungsraum mit Projektor und Laptop. Mit mindestens fünf Stunden musste man rechnen, der Rest des Tages war also “geblockt”. Jeder war gut vorbereitet und hatte alle wichtigen Punkte für die Besprechung notiert.

Die Auftraggeber waren um 13:15 vor Ort, ein Termin hatte etwas länger gedauert als erwartet. Man entschuldigte sich dafür ehrlich und nun sollte es losgehen. Man freute sich auf handfeste Ergebnisse, man hatte sich schließlich gut vorbereitet und bis 14:30 Zeit genommen

Zwei Stunden später, die Situation ist hektisch, die Sicht der Softwareentwickler:

Ein Auftraggeber war gerade gegangen, der andere mittlerweile sichtlich angestrengt. Und das, obwohl gerade einmal die Hälfte der Themen auf der extra vorher per E-Mail versendeten Liste abgearbeitet waren. Die beiden Entwickler taten ihr Bestes, um die offenen Fragen so einfach und direkt wie möglich darzustellen, trotzdem war die andere Seite nicht wirklich bei der Sache. Nein, es sollten in das eh schon knappe Zeitfenster schon wieder neue Features aufgenommen werden. Einen Punkt hatten die Entwickler “geschluckt”, ein anderer war definitiv zu umfangreich für den jetzigen Entwicklungsabschnitt. Beide sahen sich an und wussten, dass ihnen die gleiche Frage auf der Zunge lag: “Warum macht sich eigentlich niemand klar, wie komplex Programmierung ist und dass wir schon (wie immer) mehr Punkte als ursprünglich geplant umsetzten?” Dies bedeutete für die Entwickler wieder Überstunden und mehr Druck für die nächsten Wochen. Und dies “natürlich” ohne Anerkennung von irgendeiner Seite.

Die unausgesprochene Frage bei den meisten Teammitgliedern lautete:

“Wie kann man diesen Job dauerhaft durchhalten?”

Das kommt Ihnen bekannt vor? Hier geht es zu Lösungsvorschlägen!

 

Intro: Typische Situationen aus der Praxis

Seit langer Zeit beschäftigen wir uns mit Softwareentwicklung und den dahinter stehenden Konzepten und Strategien. Hier finden Sie an reale Erfahrungen angelehnte Abrisse von typischen Situationen im täglichen Umgang mit Softwareentwicklung. (Haben Sie bitte Verständnis dafür, dass wir hier “keine Namen nennen” – wir wollen niemanden bloß stellen, sondern wiederkehrende Schwierigkeiten und Missverständnisse beschreiben.)

Beide Seiten werden hier berücksichtigt. Einerseits Auftraggeber, Kunden und Benutzer mit ihren Erwartungen gegenüber den Erstellern der Softwareprodukte. Andererseits aber ebenso die Entwickler und Mitarbeiter der Firmen oder Bereiche, welche mit der Entwicklung beschäftigt sind.

In keinem Fall wollen wir hier mit dem “Finger zeigen” oder “Schuld zuweisen”. Im Gegenteil, es geht viel mehr um gegenseitiges Verstehen. Nur so kann langfristig eine gute Zusammenarbeit erreicht werden. Und wer die Situation seines Gegenübers kennt, kann ihn besser unterstützen und seine Arbeit auf die Bedürfnisse des Empfängers abstimmen.

Denken Sie immer daran: Es sind Menschen, mit denen Sie arbeiten. Behandeln Sie sie so, wie sie von ihnen behandelt werden möchten.