Der Softwareteufel rät: Stellen sie keinen Zeitplan auf. Sie werden, wenn sie drauf los programmieren, schon rechtzeitig fertig. Wenn sie einen Zeitplan aufgestellt haben, dann ignorieren sie ihn einfach. Überprüfen sie nicht, ob sie ihre geplanten Ziele erreicht haben, sie könnten sonst entäuscht werden.
Modifizieren sie ihren Plan nie, wenn sie ihre geplanten Ziele nicht erreicht haben. Ihr gescheiterter Plan ist lediglich ein Zeugnis gottgewollten Schicksals oder ihrer Unfähigkeit diszipliniert zu arbeiten.
Sie sollten einen Plan erstellen, der alle wichtigen Etappen ihres Projekts enthält. Auf diese Art und Weise behalten Sie den Überblick und können rechtzeitig Korrekturmaßnahmen ergreifen. Gegebenenfalls kann auch der Plan geändert werden. Natürlich sollten Sie auch versuchen den Plan einzuhalten und die Erfüllung desselben immer wieder überprüfen.
Der Softwareteufel rät: Schreiben sie nie einen Test. Es reicht vollkommen wenn der Compiler den Code akzeptiert. Wenn sie schon Tests schreiben, dann beschränken sie sich auf die Basisanwenderfälle und Testen sie nur die Klassen die der Kunde später direkt benutzt. Fehler in den darunterliegenden Klassen können ja dann nicht mehr auftreten, und Sonderfälle entstehen ohnehin nur durch Fehlbedienung durch den Kunden.
Testen ist eines der wichtigsten Kapitel im Softwareengeneering. Wenn sie die Korrektheit ihres Programms nicht beweisen wollen oder können, ist das der einzige Weg um Qualität anzustreben. Dabei ist es wichtig auch an ausgefallene Situationen zu denken. Am besten übernimmt das Testen jemand der den zu testenden Code nicht geschrieben hat.
Der Softwareteufel rät: Machen sie alle Arbeit selbst! Sie können es am Besten, und bis sie jemanden gefragt haben, haben sie die Dinge schon selbst erledigt. Ohnehin sind ihre Fähigkeiten schon ausgereift und sie benötigen die Kritik oder Anregungen von Anderen nicht.
Sprechen sie nichts mit ihren Teammitgliedern ab. Wenn sie die main-Methode auskommentiert haben, werden es die anderen schon merken.
Wenn sie nicht alles selber machen wollen, dann verlassen sie sich blind auf den Ehrgeiz und die Fähigkeiten ihrer Teammitglieder. Melden sie sich nicht für die anfallenden Arbeiten, sie haben ohnehin genug in ihrem Studium zu tun. Sie können ja auch die Getränke zum Projekt beisteuern.
Ab einer bestimmten Projektgröße ist die Arbeit nicht mehr alleine machbar. Große Projekte erfordern eine gut koordinierte Teamarbeit. Dazu gehört auch, daß alle Teammitglieder aufeinander eingehen, lernen Kritik zu üben aber auch zu empfangen und eventuelle Engpäße (Krankheit, Prüfung, Urlaub ...) im Team zu besprechen und abzufangen. Dabei ist es sehr wichtig das alle Mitglieder ihren Anteil daran haben.
Der Softwareteufel rät: Benennen sie ihre Klassen und Variablen möglichst abstrakt: Es ist viel wahrscheinlicher, dass sie in einem Monat eine Klasse X nochmal verwenden können als eine Klasse DateiFormatierer.
Deklarieren sie Variablen da, wo sie gerade gebraucht werden. Deklarieren sie lieber eine zuviel als eine zu wenig. Man kann die Variableninhalte ja ggf. durch Zuweisungen synchron halten. Benutzen sie keine langen Namen. Deren Bedeutung könnte nur verwirren (siehe auch oben; "Klasse X") und man muss viel zu viel tippen. Wenn sie später überprüfen wollen ob eine Variable schon benutzt ist finden sie sie ganz einfach wieder (suchen sie einfach in der/den Methode/n wo man eine Variable mit dem gesuchten Namen benutzen würde).
Rücken sie den Code nicht ein. Am besten sie schreiben ihr Programm platzsparend in eine Zeile. Schliesslich ist Speicherplatz teuer und das Semikolon als Trennzeichen wurde nicht umsonst eingeführt (z.B. in C,C++,Java ...).
Schreiben sie nie Kommentare. Der Code wird dadurch nur hässlich, zudem ergibt sich die Semantik ohnehin direkt aus den Befehlen.
Code der nicht lesbar ist, ist schon nach kurzer Zeit wertlos oder zu teuer.
Wenn sie oder ein Teammitglied Änderungen an ihrem Code vornehmen wollen,
dann werden sie aller Voraussicht nach nicht sofort alle Strukturen als intuitiv
empfinden. Die oben geschilderten "Tips" sind sehr stark übertrieben,
aber eine falsche Einrückung kann unter Umständen noch sehr lange
Fehlersuchen nach sich ziehen. Während man mit einer sorgfältigen
Einrückung beispielsweise schnell eine nicht geschlossene Klammer entdeckt.
Um den Code lesbar zu machen hält man sich am besten an sogennannte Programmierkonventionen.
Für Java empfiehlt sich da folgende Konvention.