Sonntag, 25. August 2024

ProductDev

Neulich wunderte ich mich über die geringen maximal erlaubten Tagessätze für Entwickler bei einer großen Firma.

Der Entwickler wird gemeinhin immer noch als der Maurer des modernen IT-Landschaft wahrgenommen – eine austauschbare Ressource wie der Sklave beim Pyramiedenbau. Ein Baustein, den man problemlos aus einem niedriglohn Land hinzustecken kann.

Man geht von der Annahme aus, dass eine (sehr) genaue Spezifikation eines Features – ähnlich wie ein Bauplan – ausreicht, um von einem beliebigen Entwickler eine funktiontierende Software zu erhalten.

Dieser Bauplan/Architekten/Haus Analogie begegnet man oft im Software Bereich und sie ist in meinen Augen an mehreren Stellen irreführend:

 

  1. Ein Haus ist oft ein deutlich weniger komplexes Produkt als eine Software
  2. Ein Haus ist eher ein statisches Produkt, eine Software ein sich stetig veränderndes Produkt
  3. Häuser werden meist nach gleichen Prinzipien und Ideen entwickelt – es gibt teils jahrhunderte alte und bewährte Muster. Bei der Softwareentwicklung befindet man sich immer noch in einer Forschungsphase.
  4. Das Endprodukt Haus ist leichter gegen Qualitätsansprüche zu testen als eine Software
  5. Änderungen bei einem Haus sind teuer und aufwändig, bei einer Software ist dies im besten Fall umgekehrt.
  6. … 

 

Und genau wie die Analogie Haus=Software irreführend ist, ist die Vorstellung vom Maurer=Entwickler in meinen Augen schwierig:

 

Schon länger ist es geübte Praxis (best pratice), dem Entwickler auch Betriebsaufgaben zu übertragen (devops). Dieser Schulterschluss mit einem angrenzenden Gewerk hat zu einer deutlich verbesserten Qualität und gesteigerten Geschwindigkeit in der Softwareentwicklung geführt.

Und genauso leben gute Softwareentwickler heute die Praxis, die fachliche Domäne vollumfänglich zu verstehen und dazu nicht nur geeigneten Programmcode bereitzustellen, sondern auch passende Detaillösungsvorschläge und neue Ideen beitragen zu können. Auch hier führt der Schulterschluss zum angrenzenden Gewerk (hier die Fachseite oder der Kunde) zu einem deutlich besseren Produkt und einer erhöhten Geschwindigkeit.

Und noch eine dritte Dimension berührt den Softwareentwickler und zwar das Design bzw. das Frontend, die Usability. Und auch hier zeichnet sich der top- Entwickler von heute durch eine große Portion Fachwissen und „Überlappung“ zum anderen Gewerk aus. Hier sei das Stichwort Fullstack-Entwickler genannt.

 

 

Ein solcher Top-Entwickler, der sowohl die Bereiche Development (=Codieren), Ops (=Opererations, Betrieb), Analytics(=Fachlichkeit) und Design (=UI, Interface) abdecken kann, bzw. zumindest teilweise abdecken kann, ist enorm wertvoll für ein Projekt bzw. ein Produkt.

Er bringt Vorschläge und Methoden ein, die kein anderer Projektteilnehmer einbringen könnte. Und er hat im besten Fall das große Ganze im Blick – also nicht nur den aktuellen Zustand, sondern auch mögliche geplante Versionen oder Sonderfälle. (Nicht selten ist die IT der Know-How Träger im Unternehmen.)

Und jetzt bediene ich mich doch der Haus-Analogie: Er ist Maurer, Architekt, Prüfer, Innenausstatter und Bauingenieur in Personalunion.

Solche Top-Entwickler verdienen deutlich höhere Tagessätze und Ansehen, als sie hierzulande erreichen.

In Amerika ist dies übrigens erkannt worden. Dort verdienen Top-Entwickler > 300.000$ im Jahr – mehr als die meisten Manager.

Disclaimer: Ich bin nicht ganz ein solcher Top-Entwickler. Ich kenne aber welche.  😊

 

Dieses Überschreiten der eigenen Domäne, dieser Perspektivwechsel ist selbstredend auch bei anderen Gewerken extrem hilfreich. Der Verkäufer mit IT-Know-How, der Designer mit HTML/CSS Kenntnissen, der Ops mit Betriebswirtschaftlichen Kenntnissen – you name it.

Donnerstag, 10. März 2022

Future predictions

 Ein paar Gedanken zur Zukunft:

Mietmodelle werden die zukünftige Form des Besitztums werden. Miete für die Wohnung, fürs Handy, fürs Auto, für die Software, für den Computer.

Arbeitsteilung/Spezialisierung: Konzentration auf das Wesentliche - so wie es Firmen mit ihrer Konzentration auf das Kerngeschäft machen, werden auch wir uns nur um unsere Spezialdisziplinen kümmern müssen. Alles andere übernehmen Dienstleister: Steuererklärung, Versicherung, Hausbau, Auto, Gesundheit. Alles im Komplettpaket ohne Sorgen - und ohne eigene Beteiligung und Gehirnschmalz. Worauf wir uns konzentrieren: Freizeit/Spaß und unseren Job. -- Dies wird nicht nur den Privaten Menschen betreffen sondern auch Geschäfte/Selbständige/Unternehmen.

Vielleicht wird es so eine Art "Lebens-Flat" geben, in der alles drin ist. Diese gibts dann in verschiedenen Ausführungen (S / M / L).

Rationierung: Güter werden knapp - Wohnraum, Öl, Gas, Essen, CO2 Verbrauchserlaubnis. Für jeden wird es "Freibeträge" zu vernünftigen Preisen geben, danach wird es richtig teuer. Du wohnst ganz normal mit deiner Familie? Der Strompreis wird wie heute sein. Du hast noch einen Whirlpool und einen riesigen Fernseher? Du zahlst überproportional drauf. Du willst in Urlaub fliegen? Einmal pro 3 Jahre zum Ryan-Air Preis. - Öfter? Dann 3500€ pro Flug.

Diffusion: Arm und reich werden sich angleichen. Nord-Süd Gefälle werden ausgebügelt. Die Natur strebt nach Ausgeglichenheit - und so werden wir uns auch entwickeln.


Dienstag, 1. Oktober 2019

Wie findet man _nicht_ die richtigen Kollegen?

In der Biologie findet Evolution durch Mutation bzw. Mischung der Gene statt. Im Zuge dessen sollten sich Firmen - die an einer Weiterentwicklung interessiert sind -  gezielt verändern. Zum Beispiel durch die gelegentliche Einstellung von Kandidaten, die nicht ins Schema passen, also die normalerweise durchs Raster fallen würden. Etwa durch
- Bildungsgrad
- Alter
- Herkunftsland / kultureller Hintergrund
- Sprache
- Berufserfahrung
- Geschlecht (nur der Vollständigkeit halber erwähnt)
- Lebenslauf
- Kleidung

anders sind.
Also: 99 Linientreue einstellen - und danach eine Einstellung "mit Gendefekt".

Your package structure is broken

Each package structure is sort of broken:
Layered package structure
controller
  file1
  file2
  file3
  …
repos
  file1
  file2
  file3
  …
services
  file1
  file2
  file3
  …
Good: Easy to understand
Bad: Things that belong together are spread all over the project. No true modules.
Module package structure
module1
  FileController
  FileRepo
  FileService
module2
  FileController
  FileRepo
  FileService
Good: True modules
Bad: Layer-Info hard to distinguish, not so easy to understand
Mixed mode
module1
  Controller
    File1
    …
  Repo
    File1
    …
  Service
    File1
    …
module2
  Controller
    File1
    …
  Repo
    File1
    …
  Service
    File1
    …
Good: True modules, Layers easy to spot.
Bad: Mixing of two concepts: Folders for modules, folders for layers. Developers have to travers large dir-structures.
———————
Main problem: You need folder structures to group modules, build modules, show layers. (one concept for different purposes)
Possible solution: Folders for group of modules. (may be nested) Folders with with Manifesto.xml - sorry Manifesto.yml to show module structure to IDE. And „markers“ for layers. (Which are maybe inspected automatically by the IDE.)
What is your favourite? Do you have suggestions?

Speed is king!

Natürlich ist eine schnelle Website eine gute Sache. Nutzer bekommen ihre Inhalte schneller, Google bewertet höher und der Server läuft effizienter.
Nicht von ungefähr liegt also Software-Entwicklern dieses Thema am Herzen. Ich habe aber viele Entwickler kennengelernt, die das Ziel mit einer ungewöhnlichen Inbrunst verfolgen. (Ich gehöre auch ab und zu dazu …)
Der Grund dafür mag in der einfachen Messbarkeit liegen. In der Softwareentwicklung gibt es sonst keine leichter verständlichere, einfach messbarere und für den Nutzer nützlichere Messgröße. Aussenstehenden lässt sich eine gesteigerte Performance besser verdeutlichen als z.B. eine höhere Testabdeckung. 
Fazit: Softwareentwickler sind auch nur Menschen. Positives Feedback - und sei es in Form von ein paar Zahlen - ist wichtig.

Auswege aus dem Pitch Dilemma

In der Internet/Marketing Branche ist es üblich, neue Aufträge durch sogen. Pitches auszuschreiben. Gewöhnlich werden hier nach unbekannten Methoden eine Reihe von Agenturen ausgewählt. Ich vermute hier, dass Faktoren wie 
  • persönliche Bekanntschaft
  • Position in Agenturrankings
  • Größe und Bekanntsgrad der Agentur
  • Referenz zum Briefing passend
  • Schmiergeldeinsatz (?)
eine Rolle spielen. Nicht selten werden 5 oder gar mehr Agenturen angeschrieben. Das Briefing schwankt stark in seiner Qualität, oft werden aber bereits ausgearbeitete Lösungen erwartet.
Nun erfolgt eine teuflische Dynamik bei den teilnehmenden Agenturen: Je größer das zu erwartende Budget ist, desto größer der Pitchaufwand. Nicht selten wird bereits 20% des “Pottes” verbraucht. Dies sind nicht selten 3 stellige Tagesaufwände. Oft werden diese unter extremem Zeit- und Leistungsdruck in Nacht- und Wochenendschichten erbracht. Wenn nicht genug eigene Mitarbeieter verfügbar sind, werden auch Freelancer eingesetzt.
Gezahlt wird vom Auftraggeber oft nichts oder nur ein viel zu kleiner Betrag.
Wenn ein Pitch verloren wird, muss die Agentur diese Aufwände abschreiben. Dies bedeutet eigentlich, dass die Aufwände über andere Projekte querfinanziert werden müssen. Diese werden dadurch teurer. Oder aber die Agentur macht weniger Gewinn oder rutscht gar dadurch in den roten Bereich und muss um die Existenz fürchten. In jedem Fall führt der Verlust eines Pitches zu einem Frustrationserlebnis bei den Mitarbeitern.
Oder aber die Agentur gewinnt: aber auch in diesem Fall wird der Aufwand auf das Projekt abgeschrieben oder die Agentur leidet auf andere Weise.
Resultat eines Pitches sind also teurere Projekte bzw Destabilisierung einer Branche.
Beides sollte nicht im Sinne der Auftraggeber sein.
Natürlich möchte ein Auftraggeber auf der anderen Seite die passendste und beste Agentur für die Aufgabe wählen.
Folgende Lösungen kommen mir in den Sinn:
Auswahl über Refenzen: Agenturen sollten Wert auf gut präsentierte und ausführlich beschriebene Referenzen legen. Evtl könnten dort auch Infos über Budgets oder Umsetzungszeiten gegeben werden. Codemetriken könnten die Qualität beschreiben.
Probearbeit: eine definierte Aufgabe muss von einem repräsentativen Team vor Ort gelöst werden. Das Team muss auch an der späteren Umsetzung beteiligt sein. Die Probearbeit ist entweder hinreichend kurz - oder sie wird bezahlt. (Z.b. Mit ca 500 Euro Tagessatz)
Pitchaufwände entlohnen: komplette pitchaufwände werden entlohnt bis zu einer sinnvollen Obergrenze.
Pitchzeit stark begrenzen: Auftraggeber kündigt Pitchbeginn und Abgabe rechtzeitig an, nennt aber nicht den Inhalt. Beginn und Abgabe liegen z.b. 3 Tage auseinander. (Nicht durch Wochende trennen, Kollegen! :)
Und folgende Rahmenbedingungen sollten fairerweise angegeben werden:
  • Zur Verfügung stehendes Budget (warum verschweigen? Vielleicht macht es ja eine Agentur billiger!)
  • Entschiedungskriterien (billigstes Angebot, beste Idee, wirtschaftlichstes Pflegekonzept…)
  • Nennung eines Ansprechpartners der für Rückfragen bereitsteht. Die Antworten sollten (evtl zeitverzögert) allen Teilnehmenrn auch zugänglich sein.
  • Formblätter, um Angebote abzugeben, evtl mit Aufteilung nach Aufgabengruppen und Gewerken.
Um die Pflegefalle (= Angebot sehr günstig, nachträgliche Änderungen extrem teuer) zu vermeiden, sollten Aufwände aufgeschlüsselt abgegeben werden müssen und fachkundig beurteilt werden.
Nun wünsche ich … tja, das Ende der herkömmlichen Pitchkultur herbei. 

Start

Nach beinahe 20 Jahren Interneterfahrung, drängt es mich, einige Gedanken und Erfahrungen dazu festzuhalten und zu teilen.
Und natürlich fange ich mit meinem ersten Kontakt zum Internet an:
Ich begann 1991 meine Ausbildung im Rechenzentrum der RWTH Aachen. Uns wurden klobige MS-Dos Maschinen vorgesetzt - eine Maus suchte man vergeblich.
Eines der installierten Programme ermöglichte den Versand von Textnachrichten zwischen unseren Rechnern. Unsere Adressen folgten einem Namensschema, bei dem Name und Zugehörigkeit mit einem Klammeraffen getrennt wurden. Man eröffnete uns, dass man diese Nachrichten weltweit verschicken könnte.
Später auf einer Einführungsveranstaltung wurde ein Forschungsprojekt vorgestellt: ein Mailprogramm mit grafischer Bedienung (Unix, X-Windows) ermöglichte auch das Versenden von gesprochenen Nachrichten. Andächtiges Gemurmel. Bis einer von hinten rief: “Hey, die Jungs haben das Telefon erfunden!”

ProductDev

Neulich wunderte ich mich über die geringen maximal erlaubten Tagessätze für Entwickler bei einer großen Firma. Der Entwickler wird gemeinhi...