Het wiel opnieuw uitvinden

 
30 december 2008

Soms moet je het wiel opnieuw uitvinden. Door alleen maar beproefde bibliotheken te gebruiken kom je minder snel tot productieve inzichten. In deze post maak ik duidelijk waarom ik dat vind.

Begrijp mij goed. Ik zie in dat het gebruik van beproefde bibliotheken om verschillende redenen verstandig is. Een bibliotheek zal uitvoeriger getest zijn en daarmee stabieler zijn. Het zal een grotere bekendheid hebben, waardoor een grotere groep ontwikkelaars er mee gewerkt heeft. Daarbij zal er uitgebreide documentatie en kennisdeling te vinden zijn. In sommige gevallen wordt de bibliotheek actief ontwikkeld. Jouw feedback kan er dan voor zorgen dat de bibliotheek beter aansluit op jouw wensen. Allemaal redenen om op zoek te gaan naar een passende, beproefde bibliotheek.

Daarnaast wordt er vaak laatdunkend gedaan over ‘het wiel opnieuw uitvinden’. In het licht van bovenstaande argumenten lijkt ook moeilijk te verdedigen. Hoe kan ik als eenzame ontwikkelaar een soortgelijk product afleveren? Ik heb noch de tijd, noch de kennis, noch de vaardigheden om de gehele bibliotheek te evenaren. Laat staan dat ik het kan verbeteren. Het opnieuw uitvinden van het wiel is als het waanzinnige avontuur dat Don Quichot onderneemt. Waarom zou ik het wiel dan toch opnieuw willen uitvinden?

Het wiel opnieuw uitvinden dient volgens mij een ander doel. Als jonge software ontwikkelaar vliegen de buzz-woorden je om de oren. Hibernate, Spring, Struts, JavaServer Faces, DOA’s, CRUD, DDD, SQL en DSL’s zijn maar enkele van de termen die je hoort vallen. Het zijn ongetwijfeld mooie frameworks, technieken, talen en ideeën. Ze passen vast goed in hun niche. Maar voor mij lossen zij in eerste instantie een probleem op wat ik zelf nog nooit heb gehad. Hoe kun je een goede bibliotheek kiezen als je het probleem niet ziet, of niet goed kent?

Door het wiel opnieuw uit te vinden stel je jezelf voor een uitdaging. Je bent op zoek naar een oplossing voor een bepaald probleem. Door bezig te zijn met je zoektocht naar een oplossing, leer je automatisch het probleem beter kennen. Je stelt jezelf voor alternatieven. De keuzes die je maakt hebben gevolgen voor de ontwikkeling van je oplossing. Je komt tot inzichten. Die inzichten overtuigen je van je (verkeerde) beslissing. Door het wiel uit te vinden kom je tot belangrijke ideeën, die je anders niet zou hebben gehad.

Daarom ben ik van mening dat het verstandig is om het wiel opnieuw uit te vinden. Het kan namelijk inzichten opleveren die je anders niet had verworven.


Werken met ?
Kijk dan bij onze mogelijkheden voor starters en/of ervaren IT'ers.


Categorieën: Development, Professionele vaardigheden

Tags:


Reacties (5)

  • Het wiel opnieuw uitvinden is inderdaad iets waar jarenlang te hard tegenaangeschopt is. Wielen in ons vakgebied zijn namelijk maar zelden mooi rond, of als ze wel mooi rond zijn en je moet ermee door terrein rijden dan kom je vast te zitten; je hebt dan grover profiel nodig.

    Wat wil ik aangeven met dit rare metafoortje? Dat ‘standaardoplossingen’ maar zelden helemaal passen. Softwarebouw is vakmanschap, en als er speciale automatiseringsbehoeften zijn dan is het produceren van een eigen wiel – op welk niveau dan ook – altijd efficienter. (efficienter == goedkoper, Chris :)).

    Dus Daan: Goede boodschap!

    Geplaatst op 18 januari 2009 om 23:22 Permalink

  • Chris de Kok schreef:

    @Rob:

    Klinkt schitterend, nu alleen nog een klant die ervoor wil betalen..

    Geplaatst op 06 januari 2009 om 18:08 Permalink

  • Rob Vens schreef:

    Er is een virusinfectie die rondwaart in het bedrijfsleven, genaamd “Buy Before Build”. Deze infectie kenmerkt zich door een nerd-achtige fascinatie met “features”, en een fobie voor het zelf nemen van verantwoordelijkheden (je mocht het eens verkeerd doen … en als iedereen het doet kan het niet verkeerd zijn – of kan in ieder geval het vingertje niet naar mij alleen wijzen…).
    Alleen de “wijze” architect is in staat zich te beperken in wat een product als SAP allemaal kan. En de criteria waarop je kunt bepalen welke “features” je eigenlijk nodig hebt kun je zeker niet halen uit productpresentaties of aanbestedingen! Laat staan uit de binnengehaalde experts die nodig zijn voor de implementatie.
    Waar dan wel uit? Wat is wijsheid? Mijn advies, zeker voor de wat grotere organisaties, is: bouw het zelf. Vindt het wiel opnieuw uit.
    Wat? Bouw SAP zelf?
    Ja.
    Het is niet de bedoeling dit bouwwerk ook daadwerkelijk in productie te nemen, maar de truc is dit bouwtraject te benutten voor het op een onafhankelijke wijze in kaart brengen van de werkelijke in plaats van de gepercipieerde behoefte. De ervaring die hierbij opgedaan wordt is van onschatbare waarde bij het weerstand bieden aan de heerlijke verleidingen die bij het implementatietraject door de productexperts/consultants worden binnengedragen. Weten wat je wilt is toch vaak pas mogelijk na het zelf gedaan te hebben.

    Geplaatst op 06 januari 2009 om 15:58 Permalink

  • Daan Wanrooy schreef:

    @Ivo

    De reden die jij opvoert lijkt mij legitiem. Een bibliotheek moet een passende oplossing bieden. Wanneer er veel overbodige balast is, kun je misschien beter opzoek gaan naar een andere oplossing. Zelf doen moet dan tot de mogelijkheden behoren.

    Geplaatst op 03 januari 2009 om 9:40 Permalink

  • Ivo Limmen schreef:

    Wat ikzelf ook een reden vind om ‘het wiel opnieuw uit te vinden’ is om een product niet te groot te laten worden.
    Sommige libraries (bibliotheken) zijn zo groot en komen met zo een grote hoeveelheid afhankelijke software terwijl je maar een paar kleine onderdelen gebruikt.
    Een goed voorbeeld hiervan is ‘Dependency Injection’. Als je hier gebruik van wil maken pakt men snel Spring. Spring heeft een hoop afhankelijkheden en om problemen te voorkomen word vaak gebruik gemaakt van ‘spring-full’ (oftewel: alles) dit is 30 MB aan code. Als je alleen gebruik wil maken van ‘Dependency Injection’ kan je in dit geval misschien beter uitwijken naar Google Guice of hetzelf doen (zo moeilijk is het nou ook weer niet).

    Geplaatst op 02 januari 2009 om 12:05 Permalink