News

Freitag, 28. Mai 2010 | News

10 Dinge über Software-Entwicklung, die man nicht an der Uni lernt

(Link zum Artikel: http://www.it-republik.de/jaxenter/news/055679)
  • Teilen
  • kommentieren
  • empfehlen
  • Bookmark and Share

An der Universität oder Fachhochschule wird man bestens auf alle Aspekte des Berufslebens als Software-Entwickler vorbereitet!

Dieser These widerspricht der altgediente Programmierer Alberto Gutierrez in seinem Blogeintrag "10+1 things they never teach in college about programming", in dem er seine Top Ten der Erfahrungsweisheiten präsentiert, die ihm garantiert niemand während seiner Ausbildung vermittelt hat:

  1. Entwickler haben immer unrecht – nur der Grad unterscheidet sich, in dem verschiedene Entwickler in ihren endlosen Architekturdiskussionen falsch liegen!
  2. Wenn etwas kaputt gehen kann, wird es auch kaputt gehen – also bitte alles daran setzen, dass ein Projekt narrensicher ist!
  3. Jeder Code ist schlecht – auch hier gibt es nur graduelle Abstufungen der Mangelhaftigkeit eines Stücks Software!
  4. Es gibt immer irgendwo einen Bug – man muss nur lang genug danach suchen!
  5. Das wichtigste ist der Kunde – und den interessieren die verwendeten Technologien und Prozesse nicht die Bohne!
  6. Projektentwicklung auf dem Papier funktioniert nicht – Probleme erkennt man erst während des Entwicklungsprozesses!
  7. Weniger ist mehr – wenn etwas nicht nötig ist, einfach weglassen (Keep it simple, stupid)!
  8. Nur 20% unserer Arbeit besteht aus Kodieren – der Rest ist Konzipieren, Debuggen, Testen, Meetings, Besprechen etc.
  9. Der Kunde weiß NIE, was er will – alle haben nur eine vage Idee von dem gewünschten Ergebnis!
  10. Irgendjemand hat es bereits vorher gemacht – also: nicht das Rad neu erfinden wollen!

Wer nun etwas demoralisiert aus der Wäsche guckt, dem sei der ungebrochene Optimismus aus Albertos elfter Programmierweisheit ans Herz gelegt:

Entwickler haben einen wirklich coolen Job!

(hs)

Anzeige

Kommentare

Gravatar HAL 9000 28.05.2010
um 15:41 Uhr
Sehr schöne Liste, ein paar Ergänzungen zu den Punkten hätte ich aber noch ;-)

zu 1: Der Grad höhergestellter, entscheidungsbefugter, geldgebender Fachbereiche/Kunden beeinflusst ebenfalls die Menge, die der Entwickler unrecht hat.
zu 2: Narrensicher ist aber real nicht planbar.
zu 3: Full ack!
zu 4: Meistens fallen derartige Bugs über einen her, wenn man es am wenigsten braucht. Bugs suchen brauchen wir nicht, ist doch alles TDD!
zu 5: Ja, doppelt leider.
zu 6: Auch mit weniger Papier läuft es eher anders statt besser. Aber Meeting- und Planungsorgien sind definitiv am schlimmsten.
zu 7: Genau! Meist wird der Fachtest weggelassen, vorher die Doku.
zu 8: 20% wäre ein Traum.
zu 9: Der Kunde weiß beim Prototyping immer ganz genau, was er NICHT will!
zu 10: Rad erfinden ist meist aber einfacher als immer ein komplettes Auto umbauen zu müssen, damit es wie gewünscht rollt.

zu 10+1: Ja, wenn sich nur endlich Groovy durchsetzen würde *g*

Schönes WE :-)
#zitieren
Gravatar RPR 28.05.2010
um 23:46 Uhr
Außer, dass der Typ sehr recht hat und man dazu mehrere Bücher voll an Worten zusätzlich verlieren könnte, eine kleine Randbemerkung:
Wie kommt man auf die Idee, dass man von einer UNI, in der man sich für die Lehre der Wissenschaft der Informatik eingetragen hat, statt dessen Soziologie gelehrt bekäme?
Das ist wohl auch der Grund, warum Wirtschafts-Informatiker in Unternehmen sehr gefragt sind und in der Regel schneller aufsteigen, obwohl sie als Techniker in der Regel nicht so viel taugen - sie nehmen sich halt mehr Zeit für den Kunden.

Evtl. wäre wohl ein Studiengang "(praktische) Informations-Soziologie" ein geeigneterer Ausganspunkt für eine erfolgreiche IT-Karriere ;-)

Wenn der Typ recht hat, dann sind also andere Studiengänge wesentlich besser dafür geeignet, den gewünschten Entwickler-Typ hervorzubringen; z.B. lernt man Projektarbeit in Bau-Studiengängen besser.

Aber die "Wahrheit" liegt wohl wie immer irgendwo zwischen allem; der perfekte Entwickler sollte:
- ein guter Techniker sein mit dem richtigen Händchen für einfache, stabile und schnell einzusetzende Technologien.
- kein Spielkind sein, sondern seine Freude daran haben, wie sich der Kunde an dem Nutzen der Software freut.
- am Erfolg der Software (finanziell) beteiligt werden.
- wissen, was dem Kunden wiklich wichtig ist oder nicht - und die 20 % "echte Anforderung" von den 80 % "so stelle ich mir halt das vor" trennen können.
- somit mit eigenen kreativen Ideen die Umsetzung möglichst einfach und schnell vorantreiben.
- am besten all die kleinen feinen Sachen (nebenbei) einbauen, die aus einem groben Klotz ein geiles, richtig in der Hand liegendes Werkzeug machen, das der Kunde liebt.
- durch Erfolge und Wissen des Geschäfts so viel Vertrauen beim Kunden zu haben, dass dieser ihm die notwendige Entscheidungs-Kompetenz und -Freiheit geben kann. Keine Entscheidungsfreiheit -> keine Kreativität -> plumpes Ergebnis.

Ergo:
- sondern das Geschäft des Kunden so gut kennen als dieser - also aus eigener (erfolgreicher) Erfahrung kennen.
Sprich: Beim Kunden sitzen und dessen Geschäft mitmachen und nicht extern sein.
Alter Hut, weiß jeder, befolgt nur kaum einer mehr. IT ist halt in vielen Firmen erst ein Selbstläufer geworden, dann ein Irrläufer und dann mit der Notbremse nach außen "gegeben" worden.

Andererseits: Vertriebs-IT kommt immer mehr - und damit der ITler zurück zum Kern des Geschäfts, und so macht das ganze auch wieder Spaß - kann ich nur jedem empfehlen :-)
#zitieren
Gravatar Thomas 05.08.2010
um 08:22 Uhr
Also ich weiß ja nicht wie das auf anderen Unis ist, aber bei mir ist im Laufe meines bisherigen Masterstudiums an der TU Wien jeder dieser Punkte zumindest mal vorgekommen, ins so LVAs wie SW Engineering, SW Qualitätssicherung, Projektmanagement, Requirement Engineering, etc.

Aber der Titel soll vermutlich nicht wörtlich genommen werden, sondern ist nur ein Aufreisser ;)
#zitieren
Gravatar Fallen Angel 15.12.2010
um 23:03 Uhr
Sehr schön! Kurz, knapp und in jedem Punkt richtig! #zitieren

Folgende Links könnten Sie auch interessieren

zurück zum Seitenanfang