Visual Basic – VB.NET Programmierung

Kurz und bündig

• Kleinere Projekte: Um die 500€
• Mittelgroße Projekt: Um die 1300€
• Große, komplexe Projekte: Mehrere tausend Euro

Kommen wir zum – seien wir ehrlich – für viele Auftragnehmer wichtigsten Punkt zuerst: die auf den Beauftragenden zukommenden Kosten. Dabei sprechen wir einerseits von fixen, stündlichen Kosten und den andererseits häufig vorkommenden Paket-Preisen. Welche Dinge man hier beachten sollte, erkläre ich Dir grob in den folgenden Abschnitten.

Hintergrund

So, wie z. B. Handwerker, lassen sich auch Software-, bzw. VB Programmierer (mich eingeschlossen) meist auf Stundenbasis bezahlen. Das liegt einerseits – wie bei fast jedem anderen Beruf – am "Leistung + Dauer = Preis" -Prinzip und andererseits häufig am Bedarf. Zusätzlich gibt es vermehrt auch die typischen, festen Preis-Pakete. Dabei einigen sich Auftraggeber und Auftragnehmer für ein Projekt, oder einen Bestandteil dessen, auf einen festen Preis.

Beides hat Vor- und Nachteile

Wie so häufig haben beide Vorgehensweisen ihre Vor- und Nachteile. Solange ich jemanden nur Stundenweise beauftrage, bin ich als Kunde verständlicherweise wesentlich flexibler. Ich habe dadurch eventuell eine bessere Kostenkontrolle und kann zu jeder Zeit den Anbieter wechseln, falls ich z. B. trotz klärender Gespräche unzufrieden bin.

Wenn ich als Kunde hingegen die Festpreis-Variante verwende, binde ich mich häufig über längere Projekt-Zeiträume an den jeweiligen Programmierer. Dabei stellen sich auch Fragen wie: "Möchte ich, dass der Entwickler sich allgeinig auf mein Projekt (also allein) konzentriert?". Bei der Stundenbasis ist es hingegen häufig so, dass hier in gewissen Wechsel-Modellen gearbeitet wird.

Neben den oben genannten Vorgehensweisen gibt es selbstverständlich auch Hybrid-Versionen, wo dann verschiedene Aspekte kombiniert werden. Welche Vorgehensweisen nachher zu einem einerseits als Kunden und andererseits als Entwickler passen muss man natürlich erarbeiten. Je nach Größe des Projektes könnte man hier auch variieren, so wie ich es gerne tue.

Das Fazit

Ich persönlich folge nach all den Jahren als VB Entwickler (und Softwareentwickler im Allgemeinen) eigentlich einer bestimmten Vorgehensweise. Für mich muss Programm-Code sauber geschrieben, bzw. programmiert sein, daher ist Software leider eben nicht gleich Software. Im Zweifel sollte man nach Möglichkeit erstmal großzügiger mit dem Budget umgehen, auch wenn dies erstmal vermeintlich weh tut. Damit kann man dann später allerdings häufig gängigen Probleme vorbeugen – unerlässlich ist hier natürlich immer die Absprache zwischen Kunde und Programmierer.

Man kennt nicht umsonst das gute alte Sprichwort: "Wer billig kauft, kauft zweimal!". Besonders in der Software-Branche hat das einigen "Günstig-Enthusiasten" schon das Genick gebrochen. Wer sein Haus auf einem wackeligen Fundament baut, wird feststellen, wie schmerzhaft es ist, alles nochmal abreißen zu müssen, nur um das Fundament zu richten.

Mein Tipp / Rat

Für kleinere Projekte sollte man mindestens 300-500 € einplanen und eine konkrete Vorstellung in Form von Skizzen, etc. liefern. Ein besonderer Vorteil ist es natürlich auch, wenn man sich an vorherrschende Standards hält. Dabei spreche ich von gängigen Oberflächen und die Vermeidung von aufwändig animierten Neu-Entwicklungen. Große und vor allem komplexe Systeme können selbstverständlich auch an die mehreren tausend Euro kosten.

Letztendlich sollte immer der Mehrwert im Fokus stehen: Wenn ich ggf. erstmal Geld in die Hand nehmen muss, aber anschließend meinen Alltag, oder den Alltag meiner Mitarbeiter immens optimieren kann, dann muss ich dies eben abwägen.

Wenn Du Dir diese Frage stellst, während Du Dein Projekt planst, bzw. es beginnst zu planen, hast Du das Potential einer erfolgreichen Umsetzung Deiner Software drastisch erhöht. Schaue Dir hier viele gängige Fehler an und versuche Diese nach Möglichkeit zu vermeiden.

Eine Vision ohne Aktion bleibt eine Illusion – Punkt!

Angelehnt an den obigen Punkt im FAQ spielt die Zeit, die Du als Auftraggeber selbst in Deine Idee investierst, selbstverständlich eine immense Rolle. Zu oft habe ich erlebt, dass die Projekte gefühlte Nebensache waren, was natürlich mehr oder weniger zum scheitern verurteilt ist. Auch wenn mir dies als Programmierer bei erfolgender Bezahlung egal sein könnte, entspricht dies nicht meinen Werten.

Wer ein erfolgreiches Projekt bewerkstelligen möchte, muss neben der Erreichbarkeit für den Entwickler natürlich auch eine gewisse Planung abgeschlossen haben. Gerne unterstütze ich Dich bei Deiner Planung in den mir möglichen Formen.

"Das gibt es doch schon"

Wer sich Gedanken um ein Projekt macht, könnte auch schnell zu der Auffassung kommen: "Ach, das gibt es doch sowieso schon". Auch wenn man sicherlich nicht mal eben den nächsten Amazon-Klon aus dem Boden stampft, lasse Dir Folgendes gesagt sein: Facebook war nicht das erste soziale Netzwerk, sowie es auch nicht nur eine Automarke gibt, oder?

Die letztliche Frage, die Du Dir in Deiner Planung, oder in Deiner Ideen-Situation stellen solltest ist doch: "Was möchte ich mit meinem Programm besser machen?". Dies kann sich in vielen verschiedenen Bereichen widerspiegeln, wie z. B. Preisgestaltung, Laufzeiten, Performanz, Funktionalitäten. Manchmal reicht es einfach schon, sich das anzuschauen, was die Kunden an bestehenden Systemen bemängeln.

Dir bringt natürlich sämtliche Funktionalität nichts, wenn Du den essenziell wichtigen Punkt namens "Marketing" aus dem Auge lässt. Dabei kann ich Dich wie Du oben im Kontaktformular sehen kannst auch unterstützen. Das Thema Marketing allgemein bringt uns damit auch zum nächsten gängigen Fehler.

Die Denkweise, dass der Entwickler automatisch ein Marketing-Experte ist

Obwohl Du in meinem konkreten Fall das Glück hast, auch einen Content-Creator mit Marketing-Erfahrungen an Deiner Seite zu haben, ist dies natürlich nicht der Regelfall. In erster Linie ist der (VB) Entwickler eben genau das: Ein Softwareentwickler. Klar haben wir "IT Guys" auch diverse Kontaktpunkte zu anderen Gebieten, aber dies ist nunmal nicht unsere Kernkompetenz und vor allem nicht der Regelfall.

Plane also dementsprechend (je nach Größe und Ausmaß Deines Projekts) alle entsprechend benötigten Parteien ein. Neben einem Programmierer in erster Linie, benötigst Du meistens noch einen Rechtsanwalt, einen Steuerberater und Marketing-Experten. Ebenso stellt sich die (freudige) Frage, wer eventuelle Anfragen beantwortet, wenn erste Leute Deine Software verwenden. Welche Reaktionszeit erwartest Du von Deinem Programmierer, falls mal ein Bug aufritt?

Der Irrglaube, dass alles "von der Stange" existiert

Hier kommen wir zu einem meiner Lieblings-Fehler, da Dieser besonders tückisch ist. Viele kreativen Köpfe ohne Ahnung von Softwareentwicklung glauben, dass es alles irgendwie schon geben würde. Man müsste ja nur kaufen, herunterladen und installieren, jedoch muss ich Dich da enttäuschen.

Auch wenn es sicherlich schon viele Erweiterungen gibt, sind Diese auch zuallererst mal meist auf spezielle Systeme (Kontexte, Umgebungen) getrimmt. Es fängt schon bei den verwendeten Technologien, deren Be- und Einschränkungen an und geht weiter über die verschiedenen Hersteller. Eine wichtige Rolle spielt hierbei auch die Performanz, da ein dynamisches und komplexes System eben auch sogenannten "Overhead" mit sich bringt.

Zum Glück gibt es für uns Entwickler und damit auch für die Endkunden die Möglichkeiten, nicht alles von neu bauen zu müssen. Dabei handelt es sich seitens der Programmierung meistens um gewisse Infrastruktur-Tools, allerdings müsste ich zur weiteren Erläuterung zu tief in die Programmierung abtauchen. Die gemeinten Tools erleichtern den Entwicklern das Erstellen der Anwendung.

Einen Vergleich kann ich hier meiner Meinung nach sehr schnell anbieten, denke dabei einfach mal an einen/Deinen schönen Garten. Du wirst den eventuell bestehenden Rasen auch vermutlich nicht mit der Nagelschere, sondern mit einer erfundenen, erbauten und weiterverkauften Maschine namens Rasenmäher trimmen, oder? Ebenso können auch Entwickler auf bestehende Werkzeuge, Welche uns den Tag versüßen, zurückgreifen.

Das ist doch alles rechtssicher, Herr Programmierer-Anwalt, oder?

Wir Du hier vermutlich schon am Titel erkennen kannst, soll hier ein wenig Ironie rein. Diese bringt es aber meiner Ansicht nach direkt auf den Punkt: Ein Programmierer ist eben kein Anwalt. Welche Software was, wie können darf, oder eben muss, muss geplant und abgesegnet werden. Der Entwickler hilft bei der technischen Umsetzung und berät auf dieser Ebene, allerdings ist er eben kein rechtskundiger Anwalt.

Besonders in Zeiten des Datenschutzes und des internationalen Rechts ist hier besondere Vorsicht geboten. Wer hier am falschen Ende spart, endet nachher mit größerem Minus, als die umgesetzte Software tatsächlich eingebracht hat.

Auf den Punkt gebracht: Es kommt darauf an!

Grundsätzlich gehört der Code im ersten Schritt immer dem Entwickler, da hier das Urheberrecht greift. Allerdings sollte man die Situation – unter anderem aus diesem Grund – auch vorher (wie oben im Kontaktformular, Punkt Kommerzialisierung) ausreichend durch Bestandteile eines Vertrags klären.

Wie Du Dir sicherlich vorstellen kannst, ist das Nutzungsrecht einer kleinen Hilfs-Anwendung für Deine Firma sicherlich günstiger, als die gleiche Software, Welche Du zig fach zu verkaufen planst. Das ist auch nicht zwangsweise eine Art Willkür des Entwicklers, sondern teils notwendig. Dieser muss schließlich auch eventuelle Lizenzen beachten und je nach Anwendungszweck ggf. erwerben.

Fazit

Letztendlich ist es also erstmal alles eine Regel-Sache des jeweiligen Vertrages zwischen Entwickler und Auftraggeber. Verschiedene Anwendungszwecke erfordern mehr, oder weniger Klärungs- und Kostenbedarf.

Achtung: Keine Rechtsberatung!

Grundsätzlich gilt – mehr ist besser

Je mehr Informationen mir als Entwickler zur Verfügung stehen, desto mehr Informationen kann ich dementsprechend in die Unterstützung fließen lassen. So bietet sich mir dann auch die Möglichkeit verschiedene Aspekte zu berücksichtigen, Welche andernfalls vielleicht fatale Folgen hätten.

Daher meine Empfehlung

Auch wenn es verführerisch erscheint, das obige Kontaktformular wirklich nur auf die Pflichtfelder begrenzt auszufüllen. Nimm Dir bitte zu Deiner eigenen Sicherheit die Zeit und fülle alles gewissenhaft aus. Auch wenn es vermutlich meiner Conversion-Rate nicht guttut, lass' Dir zur Not mehrere Tage Zeit.

Es wird Dir nicht nur in erster Linie schon helfen, Dein Projekt nochmal von anderen Aspekten zu beleuchten, sondern auch meine Arbeit erleichtern. Dies wird auch andererseits den Planungs-Prozess beschleunigen und Mehraufwand (zumindest unnötigen) häufig vermeiden/reduzieren.

Genaueres

Definiere für Dich im Hintergrund die einzelnen Rollen an Personen, Welche Dein Programm verwenden werden. Gibt es neben den Rollen vielleicht tiefer geschachtelte Berechtigungen? Sollen Diese Berechtigungen verwaltet und zu neuen Rollen erschlossen werden?

Welche Views, also Welche Masken/Oberflächen soll Dein Programm haben? Wie wird zu diesen Views navigiert: Eine standardmäßige "Sidebar", oder soll es eher eine dicke, Windows 8 ähnliche Kachel-Navigation sein?

Viele der genannten Blickwinkel findest Du oben im Kontaktformular unter dem jeweiligen Reiter.

Kurz und schmerzlos – so viel wie möglich

Dein Software-Projekt steht und fällt natürlich mit der existierenden Wurzel des Ganzen – Dir! Auch wenn die Umsetzung der Software aus technischer Sicht ein Haupt-Aspekt ist, bist Du natürlich die Wurzel des Ganzen. Testest Du vom Entwickler bereitgestellte (und eventuell "geforderte") Tests auch wirklich mit vollem Einsatz?

Hast Du die Dir relevanten Aspekte klar und deutlich formuliert und auch so an den Entwickler weitergetragen? Das sind natürlich Fragen, Welche unter anderem zu einem erfolgreichen Projekt beitragen. Die regelmäßige und vor allem offene Kommunikation zwischen Kunde und Entwickler (-Team) ist essenziell!

Besonders schwierig wird es aus eigener Erfahrung, wenn der Kunde leider kaum Zeit aufbringen kann. Eine kreative Idee, also ein eventuelles komplexes System zu erschaffen bedarf Zeit. Extrem schwierig wird es für mich als Programmierer, wenn ich den Kunden lange nicht erreiche und die Antwortzeiten schlecht sind.

Je nachdem wie man es betrachtet, gibt es qualitativ gesehen (leider) eine Menge Unterschiede in der Softwareentwicklung. Viele "Mal Eben"-Aufträge werden wirklich einfach nur mal eben erledigt. In solchen Projekten fehlt es häufig an Weitsicht und richtiger Planung. Besonders schlimm ist es allerdings, wenn die Qualitätsunterschiede im Bereich der Sicherheit liegen!

Aus der Vergangenheit lernen

Wie oft habe ich es selbst erlebt, dass Kunden "schnell schnell" haben wollten und – wer bin ich, es Ihnen abzusprechen – nachher auf die Nase fielen. Ich kann hier lediglich meinen Job gewissenhaft erledigen und insofern erwünscht beraten. Wenn der Kunde es dann z. B. aus Kostengründen ablehnt..

Ein Beispiel gefällig? Kein Problem! Es gab z. B. diesen Großkunden, Welcher ein wirklich großes und komplexes System programmiert haben wollte. Trotz meiner Beratung wurden viele Vorschläge und wichtige Hinweise abgelehnt, bzw. ignoriert. Nach 12-14 Wochen durchgehender Arbeit kam dann das böse Erwachen, denn wir sprachen hier von mehreren tausend Nutzern.

Der Kunde hatte weitere Wünsche, Welche im damaligen Stand schlichtweg nicht ohne großen Aufwand umsetzbar waren. Um es grob anzuschneiden, es ging um Berechtigungen, Welche komplex verwaltet werden sollten. Ich betone hier noch einmal das Beispiel mit dem Fundament eines Hauses. Software kann natürlich immer erweitert werden, klar, aber die Kosten, die Zeit und viele andere Dinge spielen dabei unweigerlich eine immense Rolle.

Man kann in der Softwareentwicklung – ob nun bei Visual Basic NET, oder bei anderen Programmiersprachen – nicht immer alles von vorne rein bedenken, das stimmt natürlich. Ich habe es aber schon zu oft erlebt, dass gewisse grundlegende Dinge häufig einfach als "das machen wir später" (trotz Warnung) abgetan wurden. Wer alles immer fleißig nach hinten verlagert, bekommt dies freilich irgendwann auf den Tisch gesetzt.

Durch Verfolgung der Management-Tools

Sobald sich die beiden Parteien geeinigt haben und losprogrammiert wird, möchte der Kunde natürlich auch wissen, wo sich das Projekt hier und da befindet. Wie so oft spielt auch hier wieder die Größe des Projekts eine Rolle. Mittelgroße bis große Projekte werden meist mit einem Tool für das Aufgaben-Management begleitet. Dort können die involvierten Parteien hereinschauen und erledigte Aufgaben abhaken.

Ebenfalls dienen solche Programme auch als Anlaufstelle für fehlerbasiertes Reporting, also wenn mal etwas nicht so klappt, wie es soll. Man sollte dabei allerdings kontextuell unterscheiden, ob es sich um etwas Separates, oder um den tatsächlich gemeinten Teil handelt. Ansonsten kann dies schnell zur Verwirrung und zur Verzögerung der einzelnen Aufgaben führen.

Durch Staging-Systeme, etc.

Neben der Verfolgung von Screenshots und der erledigten Aufgaben, gibt es noch Optionen wie "Staging"-Systeme. Diese sind dann spezielle Umgebungen, oder separate Veröffentlichungen der eigentlichen Software, Welche primär zum Anschauen und Testen da sind.

In der Web-Entwicklung hat man dann meistens eine separate Domain, Datenbank, etc. unter "staging.meinsystem.de". Bei der VB Programmierung würde man hier zumindest ähnlich, also mit unterschiedlichen Veröffentlichungen verfahren. Dies geht meist Hand in Hand mit dem Quellcodeverwaltungs-System.

Lokal auf dem Entwickler-PC

Fangen wir direkt einmal damit an, wie man es auf keinen Fall tun sollte und dennoch von vielen Entwicklern getan wird. Auch hier werden wir wieder die qualitativ unterschiedlichen Herangehensweisen von diversen Programmierern feststellen.

Einige Programmierer "lagern" den geschriebenen Quellcode trotz moderner Quellcodeverwaltungs-Systeme immer noch auf ihrem PC. Dies ist nicht nur im meist gedachten Fall fatal, also dem Ableben von diverser Hardware. Allgemein ist diese Vorgehensweise völlig veraltet, unflexibel und ein Graus, wenn es um die Arbeit im Team geht.

Was ist z. B., wenn Du als Auftraggeber eventuell noch einen zweiten oder dritten Programmierer beauftragst. Diese sollten sich im Optimalfall natürlich absprechen und gemeinsam am Projekt arbeiten können. Wenn der Quellcode allerdings nur auf einem einzigen PC liegt, wird es mehr als schwierig.

In Quellcodeverwaltungs-Systemen

Hiermit wären wir dann bei der modernen und kontrastreichen Alternative zum obigen Beispiel angelangt. Neben vielen essenziellen Funktionen, wie das gemeinsame Arbeiten an Projekten, bieten diese Systeme mehr. Allerdings würde das natürlich an dieser Stelle den Rahmen sprengen.

Final kann man also festhalten, dass der Quellcode sich im besten – und eigentlich normal-modernen Fall – in einem passenden Verwaltungssystem befinden sollte. Dort kann er zur Not völlig unabhängig vom Entwickler-PC verwaltet und eingesehen werden.