Vooruitgang bij Octavalent

In 2008 schreef ik de onderstaande regels. Ik vind het altijd grappig om dit soort lijstjes weer tegen te komen en te zien welke vooruitgang we geboekt hebben. Toen was het schijnbaar nog nodig om deze regels op te schrijven. Hoe staan we er nu voor, twee jaar later?

  1. Alle code moet worden opgeslagen in het SVN versiebeheersysteem
  2. Voor je een versie opslaat, update je working copy en verifier dat alles werkt
  3. Alle tekst in het intranet moet meertalig zijn, via de text service
  4. Geen handmatige wijzigingen in de databasestructuur; gebruik migrations
  5. Voeg commentaar toe aan je code
  6. Doe geen werk dat niet op het scrum board staat
  7. Volg de nieuwe naamgevingsconventies (geen prefixes)
  8. Alle style in CSS, regels zijn gebaseerd op classes niet op id’s
  9. Respecteer de kantooruren
  10. Vul je urenregistratie netjes in
  11. Als je iets niet zeker weet: vraag het dan

Het is goed om te concluderen dat de punten 1 tot en met 8 er goed in zitten. Het is ondenkbaar dat iemand deze regels niet volgt. Daar mogen we best trots op zijn. Jammer dat er over de punten die goed gaan niet zoveel gezegd kan worden. Nou uh: vooral zo doorgaan!

Regel 9 gaat goed, al is het soms lastig om op maandag je kind naar de kinderopvang te brengen, afscheid te nemen en op tijd op kantoor te verschijnen. Maar dat geldt alleen voor de papa’s en mama’s onder ons. Op dinsdag tot en met vrijdag verwachten we iedereen om half tien voor de daily stand-up. En als je je dan nóg verslaapt, dan ben je best een soepkip. Dat gebeurt dus nooit.

Urenregistratie blijft lastig. Bijna iedereen vult het in, maar vaak niet op tijd. Uiteindelijk klopt het allemaal wel (daar maak ik mij niet zo’n zorgen om), maar het zou prettig zijn als we dit strakker in de hand kunnen krijgen. Suggesties zijn welkom. 😉

Puntje 11, de communicatie, gaat goed. Ontwikkelaars zijn van nature introvert het werk vereist een grote mate van concentratie. Die combinatie kan dodelijk zijn voor de communicatie. En dat is jammer, want je kunt zoveel van elkaar leren waardoor het werk zoveel beter gaat. We zijn op de goede weg!

Al met al is de organisatie in twee jaar tijd enorm gegroeid. En dan doel ik eens een keer niet op omvang, maar op professionaliteit. Proficiat allemaal. Ik toost nu al op mooi 2011, dat we de lat telkens iets hoger mogen leggen.

De Octavalent-ontwikkelstraat

Iedere dag werken we bij Octavalent hard aan de opdrachten voor onze klanten. Dat gaat niet zonder een goed proces en goede hulpmiddelen. Hierbij een beschrijving van dit proces. De nummers verwijzen naar de afbeelding.

  1. Sales & Marketing verwerft opdrachten.
  2. Deze opdrachten worden beschreven in User Story’s en bewaard in de Scrum Room.
  3. Iedere maandag worden de story’s voor de wekelijkse Sprint ingepland.
  4. Research & Development gaat vervolgens aan het werk om de User Stories op te leveren.
  5. Zodra een wijziging is gemaakt in de software wordt de nieuwe versie geplaatst in het versiebeheersysteem.
  6. Het versiebeheersysteem meldt het kwaliteitssysteem dat er een nieuwe versie is.
  7. Het kwaliteitssysteem verifieert of de nieuwe versie voldoet aan alle kwaliteitseisen.
  8. Bij problemen wordt Research & Development direct op de hoogte gesteld.
  9. Bij akkoord wordt de versie opgeslagen in de Release Store.
  10. De Release Store is  een archief van alle versies van de software (inclusief alle tussenversies en maatwerk voor klanten).
  11. Sales & Marketing kan middels het Deployment Dashboard zien wel versie van de software in welke omgeving is gepubliceerd.
  12. Sales & Marketing publiceert de nieuwe versie vanuit de Release Stores naar de Test en/of Preview Webservers.
  13. Na acceptatietests wordt de versie gepubliceerd naar de Live Webserver.
  14. De Test en Preview Webservers staan in Delft bij Octavalent op kantoor.
  15. De Live Webserver staat Op Schiphol in een beveiligd Datacenter.

Dit zijn de tools die we gebruiken:

  • Heel veel post-it’s voor de Epics, User Story’s en eventuele bugs
  • Scrumborden (dunne houten platen) waar we de post-it’s op plakken
  • Visual Studio 2010 Premium met ReSharper en VisualSVN
  • Subversion als Version Control System
  • CruiseControl.Net als Continuous Integration Server
  • De Release Store is gewoon een map op de fileserver
  • Het Deployment Dashboard is zelfontwikkelde software

Make-or-buy model

De make-or-buy beslissing in softwareontwikkeling kent drie vormen. Allereerst is dit het zelf bouwen van het systeem. Hierbij heeft het bedrijf de volledige vrijheid om het systeem zo te bouwen, dat de bedrijfsprocessen optimaal ondersteund worden. Uiteraard moet het bedrijf de ontwikkelingskosten dan volledig zelf dragen. Deze kunnen fors oplopen. Desondanks is het maatwerk bouwen van systeem nog steeds vaak toegepaste mogelijkheid. Voornamelijk in niche markten, zoals overheidsinstellingen waar men met specifieke wetgeving te maken heeft.

Een tweede mogelijkheid is de inzet van een geïntegreerd systeem, zoals een Enterprise Resource Planning (ERP) systeem. Denk hierbij aan SAP, Baan of Exact. Belangrijk kenmerk van een geïntegreerd systeem is dat het een systeem is, dat ontwikkeld is voor de gemene deler van alle bedrijven in het marktpotentieel van de softwareleverancier. Dit houdt in dat de kans dat het ERP systeem zonder aanpassing ingezet kan worden bijna nihil is. Het zal altijd specifieke inrichting vragen (customizing) en regelmatig aanvullend maatwerk om, delen van, het ERP aanpassen aan de bedrijfsomstandigheden.

Het best of bread model gaat uit van een systeem dat is opgebouwd uit verschillende componenten, eventueel van verschillende leveranciers. Bij de keuze van de componenten wordt per functionaliteit bepaald welk component, van welke leverancier, het beste aansluit bij de wensen. Denk hierbij aan een systeem dat naast het verwerken van transactie de mogelijkheid moet bieden om gegevens te analyseren. Men zou dan kunnen kiezen voor software van Baan, aangevuld met componenten voor specialistische berekeningen en het pakket Crystal Reports voor de nodige analyses. Op deze manier wordt het systeem samengesteld uit bestaande componenten.

Het is wellicht overbodig om te vermelden dat hier een behoorlijke partij maatwerk voor gepleegd moet worden om de verschillende componenten op een juiste manier samen te laten werken. Wanneer alle componenten worden verkregen bij dezelfde leverancier dan is er sprake van een deels geïntegreerde oplossing, deels best of bread oplossing. Denk hierbij aan SAP die naast haar standaard modules ook componenten aanbiedt voor bijvoorbeeld customer relationship management (CRM).

In de loop van het afgelopen decennium is de keuze tussen maatwerk, geïntegreerd of best of bread verschoven. Het is de verwachting dat door middel van Application Service Providing een veelvoud van services aangeboden gaat worden. Hierdoor krijgt het best of bread model steeds meer potentie.

User stories in 11 stappen

Disclaimer: deze post is wellicht alleen begrijpbaar als je bekend bent met software-ontwikkeling op basis van de SCRUM methode. 🙂

Om het verwerken van stories en de communicatie te verbeteren hierbij een recept.

  1. Kies die story die niemand sneller en beter kan dan jij
  2. Ga rustig zitten filosoferen over de betekenis en mogelijke oplossingen
  3. Bij beschikbaarheid, of enige twijfel: roep de product owner
  4. Roep je code partner *) en bespreek de oplossingen en aanpak
  5. Voer een korte doch pittige discussie met je code partner
  6. Maak een afspraak met je code partner over wat je ga doen
  7. Doe wat je heb afgesproken (dit is het leeuwendeel van het werk)
  8. Zodra je beren op de weg tegenkomt: ga terug naar stap 3
  9. Bij afronding roep je je code partner en doe je een code review
  10. Verbeter en refactor de code waar nodig na de code review
  11. Commit je code en zet de initialen van je code partner in de comments

*) Een code partner is een persoon met wie je samen werkt. Dit is vergelijkbaar met Pair Programming.

De productiviteit van softwareontwikkelaars

Het ontwikkelen van software is voor leken vaak een mythische aangelegenheid. Jongens met t-shirts en brillen zitten dagen achter elkaar achter een computer ingewikkelde tekens in te kloppen. Ze stoppen alleen voor cola en pizza. En als je maar lang genoeg wacht dan is de software plotseling klaar. Degene die eerder met ontwikkelaars werkten, weten dat het zo niet gaat.

Programmeurs zijn serieuze  mannen die serieus met hun vak bezig zijn. Ja, er zijn in de westerse wereld relatief weinig vrouwen die software maken. Ontwikkelaars hebben in de afgelopen decennia geleerd dat de buitenwacht een beetje transparantie op prijs stelt. Die combinatie van professioneel werken en de vraag naar openheid heeft geleid tot een scala aan manieren waarop de opdrachtgever mee kan sturen in het ontwikkelproces. Maar hoe meet je nou of een ontwikkelaar productief is?

Productie wordt vaak uitgedrukt in stuks per uur, als in: een persoon plukt 20 kilo tomaten per uur. Productiviteit kun je dus uitdrukken in de hoeveelheid output die je krijgt bij een bepaalde hoeveelheid input. Werkt dit ook voor programmeurs? Wat produceren ontwikkelaars dan, wat is hun output? Een aantal mogelijkheden: het aantal regels code, het aantal computerprogramma’s of bijvoorbeeld het aantal nieuwe functionaliteiten of verholpen bugs.

Volgens Microsoft oprichter Bill Gates is het meten van productiviteit in regels code een onzinnige exercitie: “Measuring software productivity by lines of code is like measuring progress on an airplane by how much it weighs.” Een groot programma heeft inderdaad veel regels code, maar veel regels code wil niet zeggen dat het programma groot is. Het kan ook gewoon slecht ontworpen zijn. En daar komt nog bij dat het aantal regels code de opdrachtgever niets zegt.

Softwareontwikkelaars produceren geen regels code, maar functi0naliteiten. En die kun je tellen. Je kunt heel grof het aantal tellen, en je kunt dit verder verfijnen door functionaliteiten in te delen in groepen: klein, middel en groot. Als je een stapje verder gaat kun je iedere functionaliteit een waardering geven. Bijvoorbeeld van 1 tot 100. Zo heb je een kleine functionaliteit van 12 punten en een grote van 64. Samen goed voor een productie van 76. En als de ontwikkelaar daar 4 dagen mee bezig is geweest dan is zijn productiviteit 19 punten per dag.

Deze methode lijkt bijzonder (dat is hij ook), maar wordt eigenlijk al heel lang toegepast. Vroeger noemde men dit een functiepuntenanalyse, de tegenwoordige veel hippere term is scrum-punten. En dan maar zeggen dat programmeurs niet trend-gevoelig zijn! Hoe je het ook noemt en wat de subtiele verschillen ook mogelijk zijn, het idee is het zelfde: presenteer een functi0nele vraag aan ontwikkelaar en vraag hem hoeveel punten de bouw kost. Aan de hand van bepaalde tellingen kan vrij nauwkeurig een aantal punten worden bepaald.

Een softwareontwikkelaar levert functionaliteiten op waarbij de hoeveelheid uitgedrukt wordt in punten. Dit meet je iedere week om een gevoel te krijgen van de productiviteit. En daarmee dus ook wat de productie voor de komende week zal worden. Door met punten te werken is het mogelijkheid om redelijk exact te schatten hoeveel werk er af kan komen in een bepaalde periode. Of omgekeerd: hoeveel tijd nodig is om een bepaalde functionaliteit te bouwen.

Deze verbluffend simpele truc werkt in de praktijk erg goed en steeds meer ontwikkelaars passen hem toe. Te crux blijft echter zitten in het continu meten om een goede statistiek op te bouwen. Meten is weten.

De rare mens-computer dialoog

Ons brein en een computer zijn twee heel verschillende en van elkaar losstaande dingen die allebei op een eigen manier werken. Hierdoor kunnen we ons brein niet zomaar inpluggen op het internet. Om op het internet te surfen hebben we een toetsenbord, muis en beeldscherm nodig. En eventueel zelfs speakers en een microfoon voor het geluid. We hebben onze zintuigen nodig om met een computer te communiceren.

Mens en computer werken als volgt samen. Stel: we willen het laatste nieuws op internet weten. Deze behoefte zetten we om naar een handeling (typen op een toetsenbord). De computer gaat aan de slag en toont ons de nieuwspagina (op het beeldscherm). Het licht van het beeldscherm valt op ons oog waardoor de aangeboden pagina in ons brein omgezet wordt naar hersenactiviteit. Deze activiteit bevredigt uiteindelijk onze behoefte. Zo beschouwd is dit een heel rare dialoog, hoe noodzakelijk ook.

Bij het schrijven van software streeft de programmeur er naar om het geheugen- en processorgebruik van de computer zo beperkt mogelijk te houden. Hierdoor werkt de software sneller. Programmeurs hebben namelijk geleerd dat gebruikers hier blij van worden. Wij mensen worden echter niet zo zeer blij van snelle software. We worden blij van snel bevredigde behoeftes. En niet minder belangrijk: met een zo klein mogelijke belasting van ons geheugen en zo min mogelijk hersenactiviteit.

Softwareontwikkelaars zouden eigenlijk niet alleen de processorcycles van hun computer moeten meten, maar ook de cognitieve cycles van de mens. En dit zien als één integraal onderdeel. Nou kunnen we in de dagelijkse praktijk al veel, maar helaas… zo ver zijn we nog niet.

Software-ontwikkeling wordt volwassen

In de goeie oude tijd kon je software nog lekker in elkaar rommelen. Letterlijk. Software was buggie (vol met fouten), crashte regelmatig (herinnert u zich het vastlopen van Windows) en onveilig (ik noem hackers die creditcardgegevens zomaar op straat gooien). De software-industrie is zich tegenwoordig bewust van de verantwoordelijkheid die zij heeft. De lat ligt hoog, kwalitatief goede software is de norm.

Veel van de problemen met ‘slechte’ software ontstonden vanuit gebrekkige planningen. Klanten staan te dringen om nieuwe functionaliteit per direct beschikbaar te hebben, tegen de laagst mogelijke kosten. Ontwikkelaars voelden de hete adem in de nek en onder druk van deze en gene gaven ze onrealistische planningen af. Als slagroom op de taart volgende vaak ook nog eens onderhandelingen of de planning niet toch nog een stukje strakker kan. Ondertussen weten we beter.

De snelste manier naar een goede planning, is te vertrouwen op inschattingen van ontwikkelaars. Over het algemeen zijn dit loyale mannen die echt wel hun best doen om iets goed neer te zetten. Historisch gezien kunnen we stellen dat schattingen eerder te optimistisch zijn, dan te conservatief. Onderhandelen met ontwikkelaars is tegenwoordig uit den boze. Hierdoor hebben ontwikkelaars meer ruimte gekregen om hun werk in één keer goed te doen en tools in gebruik te nemen die helpen bij het bewaken van de kwaliteit.

De eisen die de gemiddelde ontwikkelaar stelt aan geschreven code zijn hoog. Even snel iets in elkaar flansen gaat echt niet meer. Softwarebouwers realiseren zich dat het ontwikkelen van goede software tijd kost. Men onderhandelt niet met de klant. Sterker, de balans is doorgeslagen. De opdrachtgever wordt geacht met duidelijke specificaties te komen. Er wordt geen code geschreven voordat duidelijk is wat de bedoeling is. De ontwikkelaar heeft tegenwoordig simpelweg geen zin meer om iets te bouwen wat later niet de bedoeling blijkt te zijn.

In zekere zin heeft de R&D afdeling een bastion voor zichzelf gebouwd en legt zij de verantwoordelijkheid bij haar klant. Echter, er wordt ook kritisch naar de eigen prestatie gekeken. Aanpassing en toevoegingen van functionaliteit moeten passen binnen de softwarearchitectuur. Nieuwe programmacode wordt getoetst door een hele batterij geautomatiseerde testscenario’s. Die dienen bij iedere wijziging opnieuw groen licht te geven. En dit zijn slechts enkele voorbeelden. Het gebruik van allerlei gespecialiseerde tools is gemeengoed. Denk aan moderne ontwikkelstraten met buildservers die en-passant diverse kengetallen meten, van code coverage tot cyclomatic complexity.

Mocht de software in kwestie een product zijn dat door velen gebruikt wordt, dan zijn de eisen nog hoger. Niet alleen moeten de specificaties duidelijk zijn. De nieuwe wensen moet functioneel passen in het product. En het moet door veel mensen makkelijk te leren en eenvoudig in gebruik zijn. Tot slot is het fijn als de documentatie en trainingsmateriaal wordt bijgewerkt, en alle gebruikers op de hoogte worden gesteld. Je kunt gerust stellen dat functies die in de jaren negentig in de ban gingen, zoals functioneel ontwerper en documentatieschrijver, nu hip en retro zijn.

Dit alles betekend dat softwareontwikkeling robuuster, en ook minder flexibel is geworden. Paradoxaal genoeg zijn de kosten gedaald. Dit komt doordat er minder fouten optreden en ontwikkelaars minder tijd besteden aan het oplossen van problemen – één van de duurste onderdelen van softwareontwikkeling. Softwaregebruikers zijn daardoor in de loop der tijd meer tevreden geworden over software. Software is beter en goedkoper. Maar inderdaad: nieuwe functionaliteit kost wel meer moeite. Ach, je moet iets te klagen houden.

What’s next for a C# web developer: C++, Python, Haskell, F#?

This text is a reply to a question on StackOverflow.com. The person asking the question is a web developer who is fluent in the .NET framework and JavaScript. He asks what would be the next language of choice that could benefit an engineer in his career.

Like a kid in a candy shop

First of all: C++ is not recommended. Not even by the experts. As one of the reasons for C#, the lead architects at Microsoft state: “C# was invented because C++ was too hard.” There is no good point in torturing oneself is there? For in depth background informative I recommend watching the Visual Studio Documentary.

For some hard job market data have a look at this website on language trends. It shows demand and supply for a number of popular languages. The advice: “Go away from Java (or well, from everything else for that matter) and start on .NET!” There is a strong demand for PHP developers, although paradoxically PHP hourly rates are low.

If you want to learn a functional language I would suggest F#, although the language has been released only a few years ago. I do expect F# to catch up; in the end of the day Microsoft always does. If you wish to learn F#, Visual Studio 2010 in combination with the free online book ‘The F# Survival Guide‘ is a good start.

There are many functional programming languages. Still I believe that for a C# developer an investment in F# is a good choice. Three reasons: 1) it is a different language paradigm 2) you can leverage your existing knowledge of the (uninteresting) support libraries and 3) C# has some functional programming features that you might better understand after learning a real functional language. What I am basically saying is: learn F# to improve your C# skills.

Learning a new paradigm is a good thing since it broadens your understanding of computer science as whole. But also learn available tools, framework and libraries. Examples are: Microsoft Message Queue, Microsoft Enterprise Library, ASP.Net MVC, Code Contracts, StyleCop, FxCop or unit testing with PEX.

Microsoft has done a good job with the .Net framework and C#. It has good performance; it is a multi-purpose language and there are continuous improvements. Even as important: the framework, language and tools are very well supported through an active community, books and certification. There is no need to run away from C#. The neighbor’s grass will not be greener.

One could criticize Microsoft for not being an innovator. Apart from its very first product – BASIC – It has never been. Not even with Windows. But one thing is for sure. You can also trust Microsoft to be Microsoft: a slow starter who is very good at catching up. Business value is not always achieved using the language du jour. If you are fluent with C# and the .Net framework, stick with it and strive to become even better. Even for C# experts there is still a lot to learn.