Was kann einen Entwickler verlangsamen? [geschlossen]


12

Welche Dinge verlangsamen einen Entwickler?

Bitte versuchen Sie nicht, Antworten zu veröffentlichen, die:


@ Mark Trapp: Huh ?! Das ist überhaupt kein Duplikat ...: -S
Tamara Wijsman

1
Wenn sich die Frage nicht als nützlich herausstellt, werde ich sie in naher Zukunft entfernen. Die Leute listen Ablenkungen auf, die bereits durch eine andere Frage von mir abgedeckt sind. Deshalb neige ich dazu, nach nicht ablenkenden Dingen zu suchen ... TheLQ und Bill sind gute Beispielantworten.
Tamara Wijsman

Huh, die URL wurde entstellt. Das Duplikat lautet Welche Ablenkungen können beim Programmieren auftreten?

Die Frage wurde offen gelassen, weil es um Dinge geht, die nicht ablenken ...
Tamara Wijsman

11
Stackoverflow, SuperUser, Programmierer ... ja, im Grunde Sites wie diese :)
Bedwyr

Antworten:


49

Oh das ist einfach:

  1. Besprechungen
  2. Weitere Besprechungen
  3. Besprechungen zum letzten Treffen
  4. Treffen zur Vorbereitung auf das bevorstehende Treffen
  5. Entwickeln einer PowerPoint-Präsentation für ein Meeting
  6. Entwickeln einer PowerPoint-Präsentation für ein Meeting, in der nicht implementierte Funktionen besprochen werden, die nicht implementiert werden sollten, und aus welchem ​​Grund auch immer, der Typ vom Vertrieb wird überall hin springen. Ich kann nicht vorhersagen, welches Dokument basierend auf Ihrem aktuellen Standort in der App angezeigt werden soll, ohne dass eine Internetverbindung besteht oder auf Ihre Festplatte zugegriffen werden muss. Nein wirklich, gib einfach auf, danach zu fragen.

4
Kurzum: Management? ; o)
n1ckp

11
@ n1ck Nein, nein. Gutes Management kann einen Entwickler beschleunigen. Eine schlechte Planung der Zeiten eines Programmierers (dh ein Aspekt der Führungskraft) kann die Entwicklung erheblich verlangsamen.
Wheaties

3
Was mich umbringt, ist, wenn meine Firma dies tut: Besprechungen, Weitere Besprechungen, Besprechungen über die letzte Besprechung, Besprechung zur Vorbereitung, Besprechung, um zu besprechen, warum wir nichts erreichen können. Warum können wir nichts erreichen? Du hast vierzig Entwickler, die in einem Raum sitzen und dir zuhören !!
Mike M.

2
Bitte beachten Sie, dass diese Antwort fast auf eine PowerPoint-Folie passen würde .

44

Gleiches Problem hier
pramodc84

1
Ich würde mir so schnell wie möglich einen Laptop kaufen und daran arbeiten, wenn ich mich in dieser Situation befände, vorausgesetzt, die Firma würde dies zulassen.
Adam

Langsame Computer sind in der Regel die Ursache für eine Ablenkung. Jedes Mal, wenn der Programmierer wartet, wechselt er möglicherweise in den Ablenkungsmodus und kehrt erst einige Zeit später zum Programm zurück.
edA-qa mort-ora-y

Sie haben meinen Computer vor ein paar Wochen ersetzt. Es ist weniger leistungsfähig als das 4-jährige, das es ersetzt. Nett.
MetalMikester


25

StackOverflow, programmers.stackexchange.com usw. :)


4
Nicht zustimmen! StackOverflow hilft bei der Lösung von Problemen und beschleunigt so die Entwicklung!
Wizard

3
Beleidigende Albernheit. Für jede Minute, die ich auf SO "verschwendet" habe, hat es mich zurückgekauft 20.
MIA

11
+1. überhaupt nicht anstößig. SO ist sehr gut für den Aufschub. Es ist mein neues Facebook. :)
back2dos

@ back2dos Bitte vergleichen Sie die Attraktivität von SO nicht mit dem Teil von .. das ist Facebook.
Adam


15

Jeder Versuch, einem Prozess zu folgen, der nicht für die jeweilige Aufgabe geeignet ist.

Dies kann alles Mögliche sein, aber ich sehe häufig Folgendes:

  • Testmethoden, die nicht zum getesteten Code passen
  • Prozesse, die wesentlich agiler oder traditioneller sind als der (die) zu erbringende (n) Gewähr (en)
  • Richtlinien, die für ein anderes Toolset als das ausgewählte Toolset bestimmt sind
  • Konstruktionsprinzipien, die nicht den Anforderungen des Projekts entsprechen
  • Verwenden Sie ein Toolset, das für die Aufgabe nicht geeignet ist

All diese Dinge können sich für einige Projekte oder Situationen immens lohnen, aber einige Organisationen versuchen, alles in eine Richtung zu tun, und dies führt zu einer schlechten Anpassung an andere Projekte, was häufig zum Tod der Produktivität führt.


13

Politik

Beispiel: Wenn mehr als eine Person die Anforderungen besitzt (oder schlimmer noch zwei unterschiedliche Interessengruppen) und sie während der Entwicklung konkurrierende und widersprüchliche Änderungen an den Anforderungen vornimmt.


9

Gespräche von anderen

und Lärm im Allgemeinen

In vielen Antworten geht es um das Wechseln des Kontexts und das Verlassen der Zone, und Lärm, insbesondere Konversation, ist eines der Dinge, die zu diesen für mich führen.

In meiner Kubikwelt bin ich auf allen Seiten von Lärm und Gesprächen umgeben. Eine Reihe weiter hält das Mainframe-Team ständige Planungsbesprechungen in der Cube-Reihe ab. Manchmal treffen sie sich mit Beratern in einem Büro an der Wand, und das führt dazu, dass laut geschrien und gelacht und gelacht wird, und ich muss rübergehen und sie bitten, ihre Türen zu schließen.

Auf der anderen Seite befindet sich der Web-Team-Konferenztisch auf der anderen Seite meiner West-Cube-Wand, sodass ich an jedem Meeting teilnehmen kann, ob es mir gefällt oder nicht. Es gibt auch einen Drucker auf der anderen Seite der Südwürfelwand, und das ist immer gut für Chit-Chat von Leuten, die rumhängen und auf ihre Ausdrucke warten.

Die sofortige und offensichtliche Antwort " Können Sie nicht einfach Kopfhörer mit Geräuschunterdrückung bekommen?" Hilft nicht, wenn Sie Stille wünschen.

Manchmal bringe ich meinen Stapel Papiere für Code-Überprüfungen in die Kantine (natürlich nicht zur Mittagszeit), aber da ist ein Fernseher, der normalerweise dröhnt. Ich schalte es aus, wenn niemand zuschaut. Ansonsten suche ich einen leeren Würfel in einer anderen Abteilung in einem anderen Teil des Gebäudes.

Wenn Sie möchten, dass Ihre Programmierer die Arbeit erledigen, die sie erledigen müssen, dh vorwiegend nachdenken und überlegen, brauchen sie eine Umgebung, in der sie dies tun können.


Irgendwann wird es dort, wo ich bin, zu leise. Ich beginne mich auf die Mausklicks aller zu konzentrieren, und die Leute atmen schwer usw. Es ist, als würde man im Bett liegen und eine Grille hören.
kirk.burleson

8

Zu viele Codezeilen ohne angemessene Tests schreiben.


Dies ist die häufigste Ursache dafür, dass die Dinge meiner Erfahrung nach zum Erliegen kommen.
Paddyslacker

1
@Paddyslacker: mehr Test = produktiver? Huh? Nur für Leute, die gar nicht erst programmieren sollten. Test kann nützlich sein, aber "die häufigste Ursache dafür, dass Dinge zum Erliegen kommen"? Sind Sie im Ernst?
n1ckp

1
@ n1ck: Ja, das meine ich ernst. Der Code wird in einen nicht zu wartenden Zustand versetzt und das Fehlen von Tests und Testbarkeit der Codebasis führt dazu, dass es immer schwieriger wird, neue Features hinzuzufügen. Ich finde es amüsant, dass du denkst, dass Leute, die mehr Tests schreiben, "gar nicht erst programmieren sollten". Also sollten Roy Osherove, Michael Feathers, Onkel Bob, Kent Beck usw. nicht in der Programmierung sein?
Paddyslacker

@Paddyslacker: Ich weiß es nicht. Ich habe sie nie gesehen. Vielleicht sollten sie nach Ihrer Beschreibung besser im Management sein? Und warum wird Code aufgrund fehlender Tests nicht mehr wartbar? Test, um schlechten Code großartig zu machen, vielleicht durch irgendeine Art von Magie?
n1ckp

1
@ n1ck, Tests zahlen sich nicht aus, wenn der Code anfänglich geschrieben wird, machen aber einen enormen Unterschied, wenn der Code später gewartet werden muss.

6

Mangel an qualitativ hochwertigem Kaffee.


Oder Mangel an gutem Soda. Ich vermisse so viel entkoffeinierte Diät-Kirsch-Cola! In meinem Land kann ich nur Diät-Cola oder entkoffeinierten Cola und überhaupt keinen Kirsch-Cola bekommen :-(
Wizard

1
@Wizard - Ich arbeite für eine Firma, die Diet Cherry Coke anbietet. Ich weiß nicht, warum ich gegangen bin. Wenn du deinen Schmerz fühlst.
JeffO

2
@Wizard: Kaufen Sie einfach ein Glas Maraschinokirschen und fügen Sie etwas Sirup zu Ihrem Getränk hinzu. Jetzt kannst du es so stark machen, wie du willst ... (der gleiche Trick für Vanille: echte Vanille-Cola ist den vorgemischten Sachen weit überlegen)
Shog9

@Herr. C: Das Problem ist, dass ich Diät + Cola brauche, eine Kombination, die in meinem Land nicht erhältlich ist.
Wizard

5

Wenn ich perfekte Schätzungen machen muss, die nicht von Beginn der Entwicklung abweichen dürfen, ist dies meiner Meinung nach ein Hühnerei-Szenario


Wenn Sie häufig darauf stoßen, würde ich vorschlagen, dass Sie sich nicht trivial mit dem Schätzen beschäftigen. Dann können Sie antworten, "wenn es eine Schätzung ist, ist es per Definition nicht die Zeit, die es tatsächlich dauern wird".
MIA,

Oh, ich habe das schon mal benutzt. Die Antwort ist immer, dass ich schlecht einschätze. Wenn es nicht in sichtbare Aufgaben von 2 bis 4 Stunden unterteilt werden kann, mache ich es anscheinend falsch
MetaGuru

5

Die kaputte Version eines anderen reparieren


klingt so, als würde jemand seinen Kollegen nicht gut betreuen.
Anzeigename

@bold: es kann natürlich aus asynchronität entstehen. Angenommen, die tägliche Build-Abschaltzeit ist 5 Uhr morgens, und Sie checken die neueste Version um 9 Uhr morgens aus. (Mit anderen Worten, Sie können die Leute nicht davon abhalten, früh zur Arbeit zu kommen.)
rwong

4

Sitzungen ohne Tagesordnung.

Eine langsame Maschine.

Fehlen eines zweiten Monitors.

Eine alte Maus, die einen Ball anstelle der schönen neuen hat.

Fehlender Internetzugang auf dem Computer, was das Abfragen von MSDN / stackoverflow / etc zu einem Problem macht.


Bezogen auf das No-Agenda-Meeting ist der Meeting-Hijacker. Weißt du ... du hast es für eine Stunde in den Kalender eingetragen, aber selbst wenn das Thema in 20 Minuten abgeschlossen ist, findet der Typ andere Themen, um die 20 Minuten auszufüllen. Ich würde dich positiv bewerten, aber dann müsste ich dich für das "Fehlen eines zweiten Monitors" als verlangsamen bewerten. Es ist praktisch, aber es gelegentlich nicht zu haben hat mich nicht gebremst.
MIA

4

Verbrachte zu viel Zeit mit Programmieren

Selbst wenn Sie Programmieren wirklich mögen, wird Sie zu viel Zeit damit verbringen, Sie irgendwann auszubrennen ...



3

Jede Änderungsanforderung, die einfacher zu implementieren gewesen wäre, wenn Sie zuvor davon gewusst hätten.


"Auf dem Wasser laufen und Software anhand einer Spezifikation entwickeln ist einfach, wenn beide eingefroren sind"
back2dos 22.10.10

1
Dummes Zitat. Auf Eis zu gehen ist nicht immer einfach.
Peter Boughton

1
@Peter Boughton: Wenn wir eine Waage wählen, bei der die Entwicklung von Software anhand schwankender und eingefrorener Spezifikationen schwierig ist, ist es immer einfach, auf Eis zu gehen. Sie können einem 6-Jährigen beibringen, dies zu tun. Aber ich nehme an, Sie wissen das, Sie haben einfach Spaß am klugen Hintern.
back2dos

Und Sie können einem Sechsjährigen beibringen, auch mit schwankenden Spezifikationen zu arbeiten. Es ist nicht klug, es ist irritiert über die übermäßige Verwendung solcher Zitate, die nicht hilfreich sind. Eingefrorene Spezifikationen sind nicht einfach zu entwickeln, wenn sie falsch sind (da sie nicht repariert werden können), und sich ändernde Spezifikationen sind in Ordnung, wenn Sie im Voraus wissen, welche Teile im Fluss sind (da Sie dies berücksichtigen können).
Peter Boughton

3

Schlechter Code.

Es ist die größte Zeitsenke, die ich mir vorstellen kann, den Teil von jemand anderem neu schreiben zu müssen, der die Aufgabe von Anfang an richtig hätte erledigen können.


2

The Much That Slows You Down ist ein guter Blog-Beitrag dafür.

...

Viele Projekte wiederholen immer wieder die Kernfunktionen auf Infrastrukturebene und verlangsamen so die Bereitstellung von Funktionen, die das Unternehmen von den Mitbewerbern abheben.

...

Es ist unvermeidlich, dass Produkte und Innovationen dazu beitragen, die Zeit zu reduzieren, die Entwickler für nicht differenzierende Aufgaben aufwenden. Die Frage ist, wie diese Dienste und Tools aussehen werden.

...


+1: Tolle Antwort. Ich habe eine Stelle aufgegeben, weil das Unternehmen nicht bereit war, Zeit für den Abbau der technischen Schulden zu investieren. Die Entwickler waren gezwungen, "Kernfunktionen auf Infrastrukturebene immer wieder zu wiederholen".
Jim G.

2

Nun, in letzter Zeit ist die größte Verlangsamung zu verzeichnen, weil wir mehrere Dinge gleichzeitig entwickeln, die in einer bestimmten Reihenfolge hätten ausgeführt werden sollen. Also warte ich, bis (die Namen wurden geändert, um die Unschuldigen zu schützen) John seine Komponente fertiggestellt hat, die ich für mein SSIS-Paket benötige, und Harry wird langsamer, bis ich Datensätze importiere, da er einige Daten benötigt, um seinen Export zu testen (jemals versuchen) einen komplexen Exportbericht zu schreiben, wenn sich keine Daten in einer der Tabellen befinden?) und alle langsamer werden, weil das Design noch nicht fertig ist und die Datenbanktabellen, die wir für unsere Aufgaben benötigen, noch nicht erstellt wurden und möglicherweise noch nicht einmal enden up zu sein, was sie sagten, dass sie sein würden, etc.


1
Es hört sich so an, als würden Sie von Engpässen sprechen, die durch eine zu geringe Verteilung der Arbeit auf die Teammitglieder verursacht werden.
MIA,

1
Es ist nicht so sehr das Team ist dünn gestreut, aber das Management hat nicht über Abhängigkeiten bei der Zuweisung von Projekten nachgedacht. Und irgendetwas, von dem angenommen wurde, dass es zu dem Zeitpunkt fertig ist, als die andere Person dem Projekt zugewiesen wurde, war nicht, als die Leute versuchten, es tatsächlich zu benutzen.
HLGEM

2

Beantworten von Fragen auf stackexchange.com, wie dieses.


Dann können Sie in Betracht ziehen, Ihre Touch-Tippfähigkeiten zu verbessern.

2

Auch wenn Sie darum gebeten haben, keine Ablenkungen aufzulisten, können diese ein wichtiger Faktor sein. Überprüfen Sie ihre Arbeitsumgebung, um festzustellen, ob sie häufig unterbrochen oder aufgefordert werden, andere Aufgaben zu erledigen, die nicht mit dem Projekt zusammenhängen.

Manchmal bleibt ein Entwickler hängen, weil er etwas tut, was er noch nie zuvor getan hat, und er weiß nicht, wo er Hilfe suchen soll. Wenn es sich um ein kleines Team oder eine Einzelperson handelt, kann es noch schwieriger werden. Wir neigen dazu, etwas stolz zu sein und geben nicht zu, wenn wir nicht wissen, wie man Dinge macht. Außerdem bitten wir andere nicht gern um Hilfe. Es gibt keine einfache Möglichkeit, einen Entwickler dazu zu bringen, dies zuzugeben, außer vielleicht zu fragen, ob er die Frist einhalten kann oder was er braucht, um die Frist einzuhalten, und dann zu hoffen, dass er ehrlich ist. Möglicherweise müssen Sie anbieten, andere Hilfe in Anspruch zu nehmen, oder jemanden finden, der ihnen helfen kann.

Fehlen klar definierter Anforderungen, was dazu führt, dass sie Dinge herausfinden oder Entscheidungen treffen müssen.


2
  • Warten Sie ungefähr 15 Minuten, bis der PC in einen verwendbaren Zustand hochgefahren ist
  • Warten, bis der PC die Anwendung wechselt
  • Die einzige Person im Büro zu sein, die ihren eigenen Tee / Kaffee zubereiten muss.
  • Eine kaputte Tastatur (behoben!)
  • Arbeiten außerhalb des Büros des Managing Directors (US-CEO) (und auch nicht in einem Büro) mit nur einer Teilung dazwischen (insbesondere bei Besprechungen)
  • Der Chef ist nur per E-Mail erreichbar, aber alle anderen sind im Gebäude
  • Kein VCS benutzen zu dürfen - anscheinend sollte es in meinem Gehirn sein
  • Kleiner Bildschirm
  • Keine andere Zeit für Pausen als das Mittagessen
  • Sichern von Remoteservern trotz eines Systemadministrators im Gebäude
  • Sie werden aufgefordert, die Backups manuell durchzuführen.
  • Ein dummes Zeitmanagementsystem benutzen zu müssen, das unnötig kompliziert ist
  • Ich habe gerade erst eine vage Vorstellung von den Anforderungen in zwei Monaten bekommen

Ich könnte weitermachen, aber es ist Freitag und ich möchte die Arbeit vergessen.


Klingt so, als müsst ihr da raus!
Adam

2
  • Fehlende Dokumentation (System, Firma etc.)
  • Fehlender kommentierter Code
  • Ein unvollständiges Verständnis des Systems
  • Politik (dh unnötige Besprechungen, Papierkram, Hindernisse durch das Management ...)
  • Unvollständige Anforderungsdokumentation
  • Facebook!
  • Zu viel Schlaf?

1

Zu viele Leute am Projekt.

Ich habe es mehrmals gesehen, als das Management auf der Grundlage fehlender realer Daten entscheidet, dass mehr Personen zum Projekt hinzugefügt werden müssen. Das führt dazu, dass die Leute, die wissen, was los ist, alles stoppen müssen, um die Hände von Leuten zu halten, die wenig über das Geschehen wissen. Ich habe mehr als einen Projektpilz in der Größe gesehen und bin dann schnell von dort in die Toilette gegangen, wohingegen es vorher gut lief, obwohl es vielleicht etwas langsam war.

Sie haben also einen Monat Verspätung, weil Sie nicht genug Geschwindigkeit / zu viel zu tun haben, um überhaupt nicht zu liefern, weil Sie das Budget für all diese zusätzlichen Leute völlig aufgebraucht haben.


0

Abgesehen von den Dingen, die von anderen erwähnt wurden, der lange Weg zwischen der Entscheidung, Ihren Code zu kompilieren und auszuführen, und dem Erreichen eines positiven / negativen Ergebnisses . Idealerweise ist diese RTT nur eine Sekunde, aber ich habe ein Beispiel für Stunden gesehen. Übrigens, Unit-Tests versuchen, dieses Problem zu lösen.

Ein anderer Zusammenhang ist die allgemeine Latenz Ihrer Arbeitsumgebung. Stellen Sie sich vor, Sie müssten über eine unheimliche Verbindung über eine Remotedesktopverbindung mit dem Computer auf der anderen Seite der Welt arbeiten. Ich war dort. Ich habe das gehasst.


0
  • Übermäßiger Papierkram

  • Eine Abhängigkeit von jemandem haben, der nie in der Nähe ist (wie Ihr Chef - wenn Sie eine Frage stellen müssen, er aber immer in Besprechungen ist)

  • Unzureichende Werkzeuge und Ausrüstung.

  • Leute schieben ihr Ruder ohne Grund ein (jede sichtbare Änderung der Benutzeroberfläche ist davon abhängig) oder streiten sich nur über Kleinigkeiten.

  • Kaputte Kaffeemaschine

  • Die falschen Aufgaben zugewiesen bekommen


0

Die Klimaanlage funktioniert nicht.

So steigt die Temperatur im Büro im Sommer von -5 auf 40 Grad im Winter.

Das -5 ist nicht gut zum Tippen, da ich keine Handschuhe tragen und tippen kann. Die 40 verlangsamt nur mein Denken.


0

Dies ist eine sehr persönliche und vielleicht kontroverse Meinung, aber Sie müssen zu viel über Design im Voraus planen und darüber nachdenken oder ständig "Qualitäts" -Code schreiben. Es gibt ein Sprichwort, dass "Wochen des Codierens Ihnen Stunden des Planens ersparen können", das in einigen Fällen zutreffen könnte.

Ich sehe jedoch oft Programmierer, die versuchen, ein gutes Design zu entwerfen, bevor sie mit dem Codieren beginnen. Ich stelle fest, dass es einfacher ist, einfach loszulegen, wenn Sie programmieren, erfahren Sie mehr über Ihr Problem und Ihre Lösung, sodass Sie Ihre Lösung schnell in ein gutes Design umgestalten können. Die meisten der auftretenden Probleme sind zu Beginn der Codierung (zumindest für meinen schwachen Verstand) kaum zu erkennen. Daher ist es reine Zeitverschwendung, viel Zeit im Voraus zu verschwenden.

Dies ist auch der Grund, warum ich TDD nicht mag. Sie verschwenden zu viel Zeit damit, Tests zu schreiben, was dazu führt, dass Sie entweder weniger wahrscheinlich umgestalten oder viel Zeit für das Umschreiben der Tests benötigen. Unit-Tests sind in manchen Fällen und in einigen Phasen eines Projekts großartig, aber der Anfang eines solchen Tests gehört meiner Meinung nach nicht dazu :)

Bringen Sie etwas schnell zum Laufen und verbessern Sie es.


-1 Ich kann Ihre Überlegungen verstehen, aber es geht in der Entwurfsphase darum, die Notwendigkeit einer Umgestaltung zu begrenzen. Es erleichtert auch Unit-Tests, die die ganze Zeit großartig sind, um sicherzustellen, dass etwas, das funktionierte, nicht kaputt geht und freigegeben wird. Wenn Sie keine Planung vornehmen, werden alle anderen Aufgaben schwieriger, wenn sie versuchen müssen, den unvermeidlich schlecht strukturierten Code zu warten.
Adam

Wer sagt, dass die Architektur schlecht sein wird? Ich sage nur, dass Sie keine übermäßige Entwurfsphase wünschen und während eines Projekts viele Umgestaltungen und Neuarchitekturen vornehmen müssen, um zu einem Qualitätscode zu gelangen. Damit dies funktioniert, müssen Sie klar abgegrenzte Code-Verantwortlichkeiten haben, bei denen sich verschiedene Personen nicht gegenseitig im Code herumtollen.
Homde

Die Erfahrung zeigt, dass die Architektur schlecht sein wird. Fliegen am Hosensitz und Cowboy-Codierung sind wahrscheinlich die schlimmsten Dinge, die Sie während der Entwicklung tun können. Eine Designphase, die eine Woche dauert, erspart Ihnen Monate beim Programmieren und führt dazu, dass Code das tut, was er beim ersten Mal tun soll. Die Idee hinter TDD ist, dass Sie die Tests nicht ändern. Diese Tests sollen die Benutzerfreundlichkeit der realen Welt nachbilden. Wenn Ihr Code den Test nicht abschließen kann, ist Ihr Code falsch.
Mike S

Meine Erfahrung sagt etwas anderes aus, aber ich denke, es hängt vom Cowboy und dem Team ab :) Ich habe durch eine Woche Codierung mehr gelernt und habe Code erstellt, um dies zu demonstrieren. Natürlich haben Sie schlechte Architektur, wenn Sie keine extremen und kontinuierlichen Umbauten vornehmen und ein Team / Cowboy haben, das agil genug ist, um mitzuhalten. Zu denken, man könne eine "Designphase" machen, alles lernen und gleich beim ersten Mal richtig machen, ist einfach naiv. Der wahre Wert eines Prototyps sind die Lektionen, die Sie lernen, die Sie wegwerfen und es richtig machen. Mach das mehrmals und schnell :)
Homde

0

Programmer's Block : Im Gegensatz zu anderen Verlangsamungen ist diese schwieriger zu lösen.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.