blog.sanderhoogendoorn.org

Why software estimation is an ongoing process

Maybe you recognize the following situation: you are asked to estimate a new project. So you dive into the - often incomplete and unclear - specifications. After trying to understand the specifications and hopefully having a lot of meetings with the customer and end users you create an neat Excel spread sheet with a work breakdown structure, and some formulas and nice estimation figures. You did a great job! Well done!

Next the project starts, and the project team now has the challenge to deliver software meeting up with your estimates. However, a number of issues surface. The project team looks at the specifications and might interpret these differently. Or even worse, they, or the customer, might come up with new requirements. Or just make different assumptions on the complexity of the software to build. Or the technology used is not as straightforward as people assumed - often the software architects. There goes your estimate.

Challenges in estimation

There are a number of challenges when it comes to estimating software development projects that arise from this small anecdote:

Initial estimates are hard. Making an initial estimate for a project is hard, as requirements are often incomplete, unknown or difficult to grasp.
Requirements changes. During a project, new requirements come up, requirements change or are even dropped.
Technology bias. Technology often turns out to be more complex (and sometimes simpler) then vendors and architects make us believe. Implementing software in a service oriented architecture is a good example.

Concluding: estimation is not an simple activity that needs to be executed at the start of a project. It is ongoing business. Not only do we need to make a plausible initial estimate of the project, just to start the work. New estimates need to be made when changes to requirements, complexity or technology surface. Why? Well simply because these changes will effect the project planning. It’s better to be aware of such effects as soon as possible.

Versatile

Therefore, the techniques used to estimate the complexity for software development projects need to be versatile. Think of:

Transparent. Creating an estimate should be dependent on some high-brow certified expert, but should rather be a team effort, accessible to all team members.
Swift. If creating an (improved) estimate takes a week, or even several days, it is unlikely that new estimates will be set up during a running projects. There just isn’t the time to do so. Hence, your project will not benefit from new insights. However, if re-estimation only takes an hour, or a few hours, it is not unlikely that this becomes a natural step in your iteration, e.g. at iteration start or end.
Repeatable. Two different estimates for the same project should be equally sized. That is, they don’t have to be equal, but they will have to be in the same range.
Unbiased. Estimates made by people with different levels of expertise, or different technological backgrounds should not differ too much. Estimates must be unbiased. It is therefore of great importance to use an abstract scale to estimate complexity, rather than estimate effort in hours (or even ideal working days).

Smart estimation is the technique where the complexity of software development projects is estimated based on smart use cases. Smart estimation uses an abstract scale (1, 2, 3, 4, 5, 8 and 10), and smart use cases can be stereotyped according to the functionality they execute. The factors above, such as transparency, swiftness and bias can be met using smart estimation.

Core [in Dutch]

Het is maandagmorgen. Er schijnt een waterig zonnetje over Ede. Ik parkeer mijn auto op het parkeerterrein van de Reehorst dat verlaten oogt bij de start van de nieuwe werkweek. Ook vandaag is de Reehorst het toneel voor een Software Developers Event. Één sessie in het bijzonder heeft mijn interesse: Addressing non-functional requirements with aspects.

Waarom nu juist deze sessie? Het verhaal gaat over PostSharp, een aspect oriented framework, en wordt gegeven door Gael Fraiteur, de bedenker van het framework. PostSharp is geschreven in C# en is een hele cleane, voor reguliere developers begrijpbare implementatie van aspectoriëntatie. Nadat in mei op een conferentie in Zurich al een presentatie over PostSharp had bijgewoond, schreef ik op een terras meteen al mijn eerste aspect. Heerlijk eenvoudig!

Frameworks. Ik kan er niets aan doen. Ik hou gewoon van frameworks. Heerlijk om te zien hoe developers, teams en project hun generieke problemen oplossen. Of eigenlijk, zoals ze keer op keer dezelfde problemen oplossen. Want wie maakt bijvoorbeeld het id aan van een nieuw domeinobject? De applicatie of de database?

Trechter

Soms levert het kijken naar code uiterst aangename middagen op, zoals bij een recente code audit die ik samen met een collega uitvoerde op een enterprise portal voor een wereldwijd bekend merk. Laat ik het anoniem houden. Een schoolvoorbeeld hoe het niet moet. Meer dan een miljoen regels code. De ontwikkelaars hadden getracht een servicegeorïenteerde software architectuur te implementeren. Waarschijnlijk op aanraden van de architectuurafdeling van het bedrijf. “Wij ontwikkelen hier altijd onder architectuur. Een service georïenteerde uiteraard.” In deze portal betekende dat alle bedrijfsfuncties vanuit de webpagina’s als web service werden aangeroepen. Op zich nog niet verkeerd, al gaf het deployment model in te uitgebreide documentatie geen aanwijzingen voor de noodzaak hiervan. Bijzonder fraai was dat al deze services – 354 in totaal – allemaal op een en dezelfde klasse waren geschreven. Met recht een trechter.

Vorige week verzorgde ik in Antwerpen een tweedaagse training in het pragmatisch toepassen van UML. Ik kom graag in Antwerpen. Fijne terrassen, prima bier. En zo belandde ik aan het eind van een hectische eerste cursusdag op een terras op de Melkmarkt met twee cursisten.

Cafe Pelikaan op de Melkmarkt in Antwerpen

Beiden werken voor een klein bedrijf in Utrecht dat software ontwikkelt voor zorginstellingen en ziekenhuizen. Deze software, zo verhalen de twee functioneel ontwerpers, wordt ontwikkeld in PHP. Ooit gestart door twee techneuten met een goed idee voor een onontgonnen markt en voldoende kennis van PHP is het bedrijf nu vijftig man groot. Maar bij de start gebeurt het! Je schrijft je eerste code en ontdekt dat sommige software herbruikbaar kan zijn. “Hé, we hebben een object Patient en een object Operatiekamer en die worden beide opgeslagen. Laten we dat isoleren.” En voor je het weet ontwikkel je je eigen framework. Met alle bijzondere principes en eigenaardigheden vandien.

Jaloers

Het ontwikkelen van frameworks vergt een heel eigen vocabulaire, patterns en best practices. Al eens naar het patroon layer supertype gekeken? Ook model-view-controllers zijn er in overvloed. En gebruikt niet ieder project een object relational mapper? En of dat nu Microsoft’s Entity Framework , Hibernate of wellicht een eigen implementatie is? Alles is mogelijk! En wellicht maken uw projecten gebruiken maken van dependency injection – het mechanisme waarmee pas op runtime afhankelijkheden worden gelegd. Gebruikt u ObjectBuilder of zijn opvolger Unity? Of dan toch liever open source? Probeer Windsor. Ook bij Microsoft lusten ze wel pap van het schrijven van frameworks. Microsoft – of meer specifiek Scott Guthrie – heeft zich onlangs alweer van zijn beste kant getoond. De beta van Silverlight is de deur nog niet uit, of Scott verlustigt zich al aan zijn volgende framework, getiteld ASP.NET MVC.

Soms ben ik daar stiekum jaloers op. Op de ontwikkelaars van het framework in PHP in Utrecht die daar een op ziekenhuizen gerichte eigen variant van Outlook mee ontwikkelen, als op Gael Fraiteur met zijn PostSharp, maar ook op Scott Guthrie en de andere bedenkers van frameworks bij Microsoft.

Catchy

Er is namelijk niets leukers dan het schrijven van een nieuw framework. Gewoon van scratch af aan. Verzin een catchy naam. Django of Zend. Start met een nieuwe solution in Visual Studio en maak je eerste items aan. Zou ik nu starten, dan zou ik eerst een assembly Core en een assembly Domain aanmaken. En dan een interface IDomainObject definiëren en een klasse DomainObject, die deze implementeert. Met een property Id schat ik in – een value object uiteraard – en een property Title, zoals ook het NakedObjects framework doet voor het eenvoudig representeren van domeinobjecten. En voor de zekerheid overschrijf ik ToString() zodat deze dan mooi Title retourneert. Misschien begin ik vanavond nog wel!

Maar ook voor frameworks geldt: er is een tijd van komen en een tijd van gaan. Op een gegeven moment is de rek uit je framework. De ooit briljante ideëen zijn ingehaald door nieuwere frameworks, die hipper zijn, open source, en uitgebreid gedocumenteerd. Wat te doen? Een complexe keuze. Ontwikkel ik verder aan mijn eigen framework? Implementeer ik daarbij nieuwe features die andere frameworks al kennen? Hoeveel aanpassingen moet ik daar voor maken? Of ontwikkel ik een nieuw framework, dat al deze nieuwe features al standaard in zich heeft, en natuurlijk beter is dan wat de markt nu te bieden heeft. Of stop ik helemaal met het opzettten van frameworks, en ga ik alleen gebruik maken van frameworks van anderen? Of stoten we meteen maar al het ontwikkelwerk af naar India?

Laat ik me er voorlopig maar niet over buigen. Een tijd van gaan? Inderdaad. Tijd om Word af te sluiten en Visual Studio te openen.

Published in SDN Magazine, July 2008.

Posted on June 26th, 2008 by shoogend
Filed under: Frameworks, Smells of bad code, Design patterns, .Net, Software architecture | No Comments »

May 28th: Conference smart use cases

On May 28th, Capgemini organizes a free conference on the topic of smart use cases at Capgemini’s Conference Building in Utrecht, the Netherlands.

Smart use cases represent a far more structured and equal-granular technique for modeling requirements than “regular” use cases do, based on Alistair Cockburn’s model of levels of use cases. In this model smart use cases comprise the sea and fish level use cases. Smart use cases are therefore smaller, and all have more or less the same size (comparable to that of user stories, those being far less structured than smart use cases).

Smart use cases are a good (small) unit of work in projects, and especially work well in agile projects. Associated is a clear and pragmatic estimation techniques, called smart estimation. During the conference on May 28th, these subjects are well discussed, not only by Capgemini speakers, but also by speakers from end user organizations that rely on smart use cases. Over 150 delegates have already registered.

More info on smart use cases can be found at: wiki.trinidadplatform.org.

Registration for the smart use case conference: www.nl.capgemini.com/smartusecases.

Posted on May 26th, 2008 by shoogend
Filed under: Smart estimation, Smart use cases, Agile | No Comments »

Starbucks

Het is half vier ’s middags als mijn vliegtuig in een zachte motregen landt op het vliegveld van Seattle Tacoma. Omdat ik deel uitmaak van de Visual Studio Advisory Board ben ik op weg naar de campus van Microsoft in Redmond, het overbekende slaperige voorstadje van Seattle. Maar behalve dat Seattle de reuzen Microsoft en Boeing huisvest, kent ook koffieconcern Starbucks zijn oorsprong in het centrum van de stad, nabij Pike Place Market. Nu drink ik graag koffie, en dus sluit ik nog niet lang na de landing aan in een rij in een van de ruim honderd Starbucks winkeltjes in het centrum van de stad.

Starbucks is een fenomeen. Nog altijd ben ik er niet uit of ik hun koffie lekker vindt of gewoon een warme bak troost. Maar wat me altijd opvalt als ik in een van hun winkels ben, is de bijzondere werkwijze die men hanteert wanneer ik een simpele beker koffie bestel. Degene die de bestelling opneemt, roept deze door naar een collega, die een beker klaarzet en daar iets opschrijft met een zwarte marker. Een andere collega pakt de beker op en vult die met koffie. Dan wordt de beker opgepakt door weer een andere medewerker, en voor mijn neus neergezet. Zo zijn er drie a vier Starbucks-medewerkers nodig om één beker koffie te maken. Knappe samenwerking. Of ik nu in Seattle, Zurich, Honolulu, Amsterdam, Sydney of Kuala Lumpur ben. De werkwijze is identiek. Onwillekeurig denk ik aan die oude mop over hoeveel Belgen er nodig zijn om een gloeilamp in te draaien. Dat moet efficiënter kunnen.

Hok

Helaas zijn wij in ons vakgebied nu niet bepaald een toonbeeld van efficiëntie en samenwerking. Ter lering en vermaak een paar voorbeelden. Ooit maakte ik frameworks voor PowerBuilder. Typisch client server. Totdat we besloten een model view controller te implementeren en zo het opzetten van een laag voor bedrijfslogica te faciliteren. Om dit fraaie stukje technologie te ontwikkelen sloten mijn collega Wim en ik onszelf op in een hok met twee whiteboards en een laptop. Toen we na een week of vier het hok weer uitkwamen waren de whiteboards vol en hadden we een prachtige meerlagenarchitectuur aan ons framework toegevoegd. Jammer alleen dat de ontwikkelaars in de projecten hun werkwijze niet veranderden en ons fraaie werkstuk nooit gebruikt hebben. Ach, we hadden ons in elk geval vermaakt.

Handen geven

Een paar jaar en een werkgever later werd ik gevraagd een audit te doen in een project bij een grote financiële instelling. Ik was dus gewaarschuwd. Nu was dit project zo’n beetje het eerste dat daar met Java werd uitgevoerd. Om een lang verhaal kort te maken: het project telde zo’n honderd medewerkers. Twintig analisten, twintig ontwerpers en natuurlijk ook twintig Java ontwikkelaars. En de nodige overhead: managers, secretaresses, projectbureau, en o ja, niet te vergeten de WebSphere beheerder.

De ontwikkelaars hadden het niet erg druk. Eigenlijk hadden ze niets te doen. Er was namelijk nog geen ontwerp. Maar omdat Java ontwikkelaars extreem schaars waren in die tijd – halverwege de jaren negentig – had de financiële instelling ze maar alvast ingehuurd. Stel je voor dat er geen ontwikkelaars zijn op het moment dat er software gebouwd moet worden. Maar ook de ontwerpers hadden een probleem. De analyses die werden opgeleverd door de analisten waren door de ontwerpers maar moeilijk interpreteerbaar. Geschreven in een taal die ze niet beheersten. En de analisten? Die konden niet anders. Ze hadden het nu eenmaal zo geleerd. En dus werd er in het project geen software opgeleverd. Nog geen regel.

Als advies stelde ik de manager van het project voor in iteraties – van zes weken – te werken waarin kleine brokken van de functionaliteit zouden worden geanalyseerd, ontworpen en gebouwd. Inderdaad. Tegenwoordig noemen we dat agile software development, en doen we dat in iteraties van twee weken. Maar voor een grote financiële instelling halverwege de jaren negentig was dit niet heel erg gebruikelijk. En nog steeds niet, als ik kijk naar de projecten die grote financiële instellingen ruim tien jaar later uitvoeren. Maar goed. Terug naar het project. We besloten om workshops te organiseren. Multidisciplinaire. Terwijl ik het brown paper het schilderstape aan de muur hang voor de eerste, druppelen de deelnemers binnen. Twee analisten, twee ontwerpers, en een ontwikkelaar. Opvallend genoeg geven ze elkaar een hand. “Dat is een goede gewoonte,” zeg ik glimlachend en naïef. “Doen jullie dat hier iedere dag?” De analisten en de ontwerpers kijken mij verbaasd aan en daarna elkaar. “Nee hoor,” zegt een van de analisten dan. “Dat doen we alleen maar omdat we elkaar nog niet kennen.” Het project liep al ruim een jaar en kostte ruim honderdduizend gulden per dag.

Nodeloos toe te voegen dat tijdens dit project nooit software is opgeleverd. Tijdens de eerste iteraties proberen we twee schermen te ontwikkelen – ja, u leest het goed: twee schermen, in zes weken, met twintig ontwikkelaars. Tevergeefs.

Fooien

Kan het nog erger? Ach. Er is altijd een overtreffende trap. Nog niet zo lang geleden kreeg ik van een vriend via de mail een document toegestuurd. Een use case. Van ruim zestig pagina’s. Nu is dat wat veel voor een enkele use case. Ik blader door het document en worstel door tientallen scenario’s. En een dozijn schermen. Dat wordt weer een feest voor de ontwikkelaars. Gelukkig bevinden die zich in India. Anders dan in het vorige voorbeeld is tijdens dit project al wel software geproduceerd. Er zijn ongeveer tien schermen gereed. Maar ja, het project loopt ook pas een jaar. Kosten? Anderhalf miljoen euro per scherm.

Dus wie ben ik om Starbucks te bekritiseren over hun werkwijze? Ik pak mijn koffie van de toonbank en verlaat de winkel. Happy end? Nee, helaas. Het verhaal heeft een staartje. In dezelfde week dat ik in Seattle ben, word bekend dat managers van het koffieconcern in Californië meedeelden in de fooienpot. En dat vond een rechter niet goed. Nu moet Starbucks maar liefst honderd miljoen dollar aan fooien herverdelen. Zo erg is het in ons vak dus nog niet.

Posted on May 20th, 2008 by shoogend
Filed under: Project management, Anti-patterns, Agile | No Comments »

Verwachtingen

Vanmorgen bracht ik met mijn jongste zoontje Boet – net drie – een bezoek aan de dichtstbijzijnde kinderboerderij. Zijn eerste bezoek aan een kinderboerderij. Een openbaring. Toen ik hem na afloop, vlak voor zijn middagdutje vroeg of hij het leuk had gevonden in de kinderboerderij, antwoordde hij heel gedecideerd: “Ik vond het niet leuk in de kinderboerderij. Er waren geen leeuwen, er waren geen tijgers en er was geen krokodil.” Teveel dierentuinen gezien. Een duidelijk geval van gemankeerd verwachtingsmanagement.

Het werkelijke leven biedt zo alweer een knappe metafoor voor het vakgebied software development. Hoe vaak gebeurt het niet dat de klant niet datgene krijgt wat hij eigenlijk nodig heeft. Misschien mag ik – alhoewel het inmiddels toch langzamerhand bekend mag worden verwacht – het onderwerp nog eens terugbrengen op het watervalmodel. Naar aanleiding van een recent seminar dat ik verzorg over agile software development herlas ik onlangs nog eens het prachtige white paper Managing the Development of Large Software Systems van Winston Royce dat hij publiceerde in de Proceedings of IEEE Westcon in het legendarische jaartal 1970. Dit beroemde artikel wordt nog altijd gezien als de bakermat van het watervalmodel. En inderdaad, in het white paper treffen we de bekende afbeelding van het model, met de fasen analyse, ontwerp, bouw en test. Destijds baanbrekend.

De strekking van Managing the Development of Large Software Systems werd pas goed duidelijk toen het Amerikaanse ministerie van defensie door een engineer op basis van het white paper de standaard voor software development uitschreef, onder de nietsverhullende titel DOD-STD-2167. Het is deze standaard die model heeft gestaan voor de verspreiding van het watervalmodel in tal van overheidsinstellingen, banken, verzekeraars en andere bedrijven die zich in 1970 al druk maakten over het uitvoeren van software development projecten.

Helaas, helaas voor ons vakgebied zag de auteur van DOD-STD-2167 een aantal cruciale opmerkingen van Winston Royce over het hoofd. Ik citeer. “If the computer program in question is being developed for the first time, arrange matters so that the version finally delivered to the customer is actually the second version.” Wat Winston Royce eigenlijk beoogde met zijn white paper is dat de eerste versie van software zelden volledig en correct is, en dat je er ten allen tijde rekening mee moet houden dat er verbeteringen en wijzigingen komen. Precies datgene wat in een traditioneel project wat getracht uit te bannen. Winston Royce zegt dat wijzigingen onvermijdelijk zijn als “there are novel elements and unknown factors.” En zeg nu zelf, wanneer is dat nu niet het geval in een normaal project? Royce promoot dan ook een do-it-twice approach. Later, in interviews verklaart hij zich groot voorstander van iteratief ontwikkelen en zegt hij dat het hem altijd heeft gespeten dat het ministerie van defensie zijn white paper zo beperkt heeft geïnterpreteerd. En datzelfde zegt overigens ook de engineer die DOD-STD-2167 heeft gefabriceerd.

En toch. Tijdens een workshop UML die ik eerder deze week deed gaan er nog altijd stemmen op voor waterval. “Wij doen al jaren watervalprojecten, en met succes,” spreekt een deelnemer zich uit. Terug naar het onderwerp van vandaag. Verwachtingsmanagement. Uit onderzoek blijkt dat tijdens een gemiddeld project de requirements met zo’n 25% wijzigen – ja ook in watervalprojecten. Een onderzoek dat in 1999 werd uitgevoerd over ruim vierhonderd DOD-STD-2167 projecten toont zelfs aan dat 45% van de van te voren opgestelde requirements (zoals dat hoort in waterval) nooit wordt gebruikt wordt, en 19% maar zelden. Overigens beschouwt datzelfde onderzoek dat ruim 75% van deze vierhonderd projecten is gefaald. Het is maar dat je het weet. Te vaak een dierentuin beloofd, maar een kinderboerderij gekregen.

Zie ook: http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf

Posted on April 17th, 2008 by shoogend
Filed under: Waterfall, Anti-patterns, Agile | 1 Comment »

Best oursourcing location?

On Plaxo, a networking website, someone started a poll that was issued to answer the question: which region is the best one for offshore IT projects? Besides this being a fairly subjective question, none of the multi-choiced answers matched my opinion. The list lacked The Netherlands.

You will find the poll at: http://pulse.plaxo.com/pulse/events/show/39328239. And since the poll’s author requested comments, I couldn’t help leaving some.

Although there’s certainly a lot of repetitive work that can be outsourced, from my area of expertise, software development, I doubt that this will lead to the best results. Software development is creative work and benefits from close cooperation between customer en developers. I still think that software development can best be done at the customer - not 5.000 miles away, no matter how cheap or high qualified people seem to be elsewhere on the planet. So, if my customer is in the Netherlands, the best outsourcing location will be the Netherlands. The same goes for Belgium, the UK, Sweden, India, South Africa, Australia, etc.

Posted on March 21st, 2008 by shoogend
Filed under: Outsourcing | No Comments »

Smells of bad code [1]

Can’t help it. Looking at someone else’s code is just plain fun. Especially when it’s not that well architectured. It seems that I keep running into nice fragments of how not to code. Well, to be honest, my colleagues tend to help out, and send me all kinds of code examples.

Have a look at the tiny fragment below.

If HttpContext.Current.Session(“UserID”) <> “obama” And HttpContext.Current.Session(“UserID”) <> “h.clinton” Then Response.Redirect(“../../default.aspx”)

Brilliant, isn’t. Of course I changed the names, as you might expect. This is a cruel example of authorisation. At first, the developers (being the two persons who do get authorized) will probably have thought: this is ok for now, we’ll refactor it later before the application gets deployed. Unfortunately, they forgot. This code was found in a web application in production. Moreover, it had thousands of users. Now imagine the trouble the people administrating the application will have. “Why do I have to login as obama? Who is he anyway?”

There’s another explanation. Although less desired. It’s that the developers just didn’t know any better that to write the user name in a session variable named UserID. Let’s hope this scenario is not the case. It would scare me to see that this could well be exemplary for the quality of the code.

Posted on March 17th, 2008 by shoogend
Filed under: Smells of bad code, C#, .Net | No Comments »

Homesourcing [in Dutch]

Omdat de grijzende stewardessen van Air Canada op de nachtvlucht van Honolulu naar Sydney nu eenmaal niet de Volkskrant rondbrengen, besluit ik genoegen te nemen met de Herald Tribune. Direct valt mijn oog op een bericht linksonder op de voorpagina. Het artikel wordt geflankeerd door een foto van een Indiër in strak pak, met dito stropdas en dito kantoor op de achtergrond. “India tries outsourcing its outsourcing,” verontrust de kop me. Hier was ik al bang voor. Ze krijgen het door in India: software bouw je het best waar je klant is.

Laat ik een paar stappen terugzetten in mijn carrière. Vroeg in de jaren negentig van de vorige eeuw startte ik bij CMG. Nadat ik een aantal dagen was blauwgespoten – vakjargon voor kennismaken – stuurde mijn toenmalige manager mij naar de klant. Tijdens mijn studie had ik al gelezen over dat geheimzinnige begrip. Ik kon het dus moeiteloos plaatsen tussen andere vaktermen die ik nog niet van dichtbij had gezien. Vierde normaalvorm, functioneel ontwerp, kosten-batenanalyse, object-relational-mapping, klant.

Daar zat ik in mijn blauwe pak in de fabriek van een grote platenmaatschappij aan de rondweg van Uden. Of ik een applicatie kon ontwikkelen waarmee gebruikers inzicht kregen in hoeveel exemplaren er van een bepaald product – meestal de nieuwste Phil Collins – waren geleverd, wat de levertijd was of wat de gemiddelde productietijden waren. En dat dan per land, per regio, per type product en per afnemer. Om het makkelijk te maken bevond alle data zich op een lokale AS400. Tegenwoordig heet dit business intelligence. In die tijd bouwde ik dat gewoon lekker met PowerBuilder.

Feedback

Mijn project bij deze platenmaatschappij was een doorslaand succes. Waarom? Ik deelde een kamer met de projectleider, de gebruikers van de nieuwe applicatie bevonden zich in drie kamers links naast de onze, en mijn directe opdrachtgever bewoonde de kamer rechts van ons. De lijntjes waren kort. Snelle beslissingen nam ik over het bureau heen met de projectleider. Een paar keer per dag ging ik bij de gebruikers langs om de nieuwste schermen te demonsteren, waarop ik dan meteen feedback kreeg. Een paar keer per week viel ik zelfs mijn opdrachtgever lastig met deze exercitie.

Het gevolg van deze directe communicatie was dat de software snel groeide en ik fouten er vrijwel direct uithaalde. Uiteindelijk leverde ik de applicatie weken eerder op dan gepland, was alle oorspronkelijke functionaliteit en meer gerealiseerd en was de klant blij. Aan het eind van het liedje liet een tevreden opdrachtgever mij tien CD’s uitzoeken in de personeelswinkel.

53 kilometer

Pas in mijn eerstvolgende project kreeg ik te maken met het fenomeen outsourcing. Terwijl onze klant in Nieuwegein zat, werd de software ontwikkeld op ons kantoor in Rotterdam. Het verschil in communicatie met mijn vorige project was direct zichtbaar. Hoewel er tussen Rotterdam en Nieuwegein maar 53 kilometer snelweg ligt, was communicatie met de klant een stuk complexer. Even een schermpje aan gebruikers laten zien en dat vervolgens direct aanpassen was er niet meer bij. Some much for usability.

Feitelijk betekende deze afstand van 53 kilometer dat men vond dat de specificaties gedetailleerd moesten worden uitgewerkt, voordat er werd geprogrammeerd. Dit maakte directe communicatie namelijk overbodig, zo redeneerde de projectleider. Onder water was het zo bovendien mogelijk te schuiven met mensen in het project. Jonge ontwikkelaars konden zo ervaring opdoen, zonder dat de klant hiermee werd lastiggevallen. Dit is niet nieuw voor u toch?

Natuurlijk werden er op basis van deze gedetailleerde specificaties precieze afspraken gemaakt over hoe de applicatie moest worden ontwikkeld, hoe lang we er over zouden doen, en wanneer het spul werd opgeleverd. Om een lang verhaal kort te maken: er was nauwelijks interactie met de klant, en nog minder feedback. Aan het einde van het project bleek dat de applicatie voor geen meter aansloot op de wensen van de klant. Bovendien werd de software te laat opgeleverd, en kostte het project ruim drie keer meer dan begroot. Tel uit je winst.

Voor mij het bewijs dat je software altijd zo dicht mogelijk bij de klant moet maken. Gek genoeg hebben managers van grote ondernemingen met het vertstrijken der jaren hun geloof in het ontwikkelen van software op afstand alleen maar vergroot. Maar ja, wat merken managers van onbruikbare applicaties, of van gemiste deadlines. Outsourcing, nearshore, rightshore en offshore development zijn hip. Van Rotterdam naar Roemenië, van Pakistan naar India. En nu weer naar China, Mexico en Zuid-Afrika. Wat van ver komt is lekker.

Totdat het lijntje breekt. En dat is nu precies wat in India begint te ontdekken. “India tries outsourcing its outsourcing,” meldt de Herald Tribune, die nu uit het vakje aan de stoel voor me bungelt, terwijl de zon opkomt boven de Pacific. En waar outsourcen ze dan naartoe, vraagt u zich misschien af? Zo’n beetje naar de rest van de wereld. Naar Phoenix in Arizona bijvoorbeeld. Of naar Polen en Tsjechië. Wat zegt de Herald Tribune? “The need for workers in their clients’ time zones or for workers who speak languages is challenging the (outsourcing) model.” A ha.

Gewoon Nederlands

Dus: medewerkers in de buurt van de klant, die ook nog eens de taal van de klant spreken. Wie weet openen Tata en Infosys straks een kantoor in pakweg Uithoorn of Gouda en gaan ze projecten uitvoeren in Nederland, met medewerkers die Nederlands spreken. Er glooit hoop aan de horizon! Misschien ontdekken onze Indische vrienden wel dat het nog slimmer is om die mensen in Nederland die toch al Nederlands spreken een keer bij de klant te stationeren voor een volgend project. En dan deze ontwikkelaars en testers laten praten met de klant en met de eindgebruikers. Opdat we eindelijk eens bruikbare applicaties gaan ontwikkelen. Een trend die wij allang hadden moeten ontdekken. Homesourcing.

En misschien, ik acht dat niet uitgesloten, ontdekken ze dat in India nog wel sneller dan wij. Het zijn slimme jongens hoor, die Indiërs. Vertwijfeld blijven wij dan achter in onze steeds leger wordende high-tech kantoren in Utrecht, Nieuwegein, Veenendaal of Amstelveen. Of missschien werken we tegen die tijd al lang allemaal voor Tata, Infosys of Wipro. Prettige vlucht nog!

Posted on March 5th, 2008 by aahoogendoorn
Filed under: Outsourcing, Agile | 1 Comment »

Mosaic

In the beginning in November, I was in Barcelona. Apart from the fact that the Microsoft TechEd took place there, Barcelona is obviously in itself a landmark. One of my favorite places in the metropolis is the Sagrada Familia, the famous temple by Antoni Gaudi. Frequently used as a metaphor for colossal and never ending type of software development projects especially government bodies and financial institutions seem to have patented. However, inside the dark bowls of the Sagrada other, much more interesting processes, take place.

Apart from the complete models in the basement of the template, on the ground floor hard workers you might encounter small teams of construction workers, complete with helmets and fags, concentrating on miniature activities: creating mosaics of tiny tiles. The first highly focussed construction worker signs the tile, the second one cuts it and passes it back to the first who then tries to fit it in the mosaic on the drawing board. Wonderful. I suspect that after a long day of work both construction workers happily glazing enjoy the subway ride home. Fine work, even without any view what so ever on the overall progress of the project. There’s no better analogy for developers who try to find little solutions for miniature problems in everyday software development. Identifiable right?

Earlier this week I wanted to create a number of link buttons dynamically on an ASP.NET web page, and then allow the Click event of these buttons to be handled by that page. Although that seems rather obvious, it requires quite a lot of reflection. A little mosaic.

Step one is a piece of cake. First create the button you want. Preferably do this from the OnInit event as it requires re-creation on post back!

LinkButton button = new LinkButton();

Now you will need to track down the EventInfo for the Click event. You need this to add the delegate handling the event. So

Type buttontype = button.GetType(); EventInfo clickeventinfo = buttontype.GetEvent("Click");

The most difficult step in this mosaic is dynamically creating the delegate. The easy way to do this is based on the name of the method on the webpage that should handle the event; which I’ve called ButtonClick. Original name isn’t it? My creativity sometimes abandones me. In addition, you must know what type of delegate should be created.

Type delegatetype = clickeventinfo.EventHandlerType; Delegate delegateinstance = Delegate.CreateDelegate(delegatetype, ph.Page, handlername);

Another tile further. I have a delegate. Now I will have to pass the delegate to the event, so that, when I click the button, the method on the page gets triggered. This is a tricky one. Fortunately, the EventInfo class contains a method to take care of adding a delegate to the Click event. So, next I extract the MethodInfo for this particular method execute it through Invoke(). Additionally, I add the delegate as a parameter to this method.

MethodInfo mi = clickeventinfo.GetAddMethod(); Object[] args = { delegateinstance };
mi.Invoke(button, args);

Now my little mosaic is almost done. Now I only need to add the button to the list of controls on the web page (or in my particular case to the list of controls of the placeholder ph on the user control on the web page) and I’m done.

ph.Controls.Add(button);

I feel like a happy construction worker at the Sagrada Familia site. Tired but satisfied. I’ve added a beautiful little mosaic as a tiny component of the application I’m working on. Writing code is still the best job in the world. With a serene smile I get into my car and get stuck in traffic.

Posted on February 14th, 2008 by aahoogendoorn
Filed under: C#, .Net | No Comments »

Testing-after-all-coding-is-done

In a blog post my former collegue Anko - who is a tester - states that “… in discussions with testers … there seems to be only one belief: the fact that structured testing can only be done based on detailed, documented specifications and test execution-after-all-coding-is-done.” As Anko is very familiar with agile testing he knows better than this, and hence he ends with wondering: “why don’t we, as test professionals, have more answers than just one to structured testing?”

Well, I think there more than one truth out there. Agile and iterative development methodologies all embrace the idea that testing is a vivid part of each of the iteration. During each iteration a number of (similar) work items are produced, such as (smart) use cases or features.

In fact, testing already takes place before code has been written. We, for instance, test our smart use cases using a similar technique as TMap proposes in process cycle tests. But, here we test based on minimal use case description - and as a part of getting concious about the requirements for our use cases.

This presents our testers with a totally different role in projects - being the prmary designer for the project that is. Hence we approach testing not based on fully specified documentation (whatever that is, and whenever it’s produced - mostly never) but testers play an important role in our projects.

Having the illusion that testing should only be done on fully qualified documentation places testers in a very dependent position at the end of a project, and often in a very destructive role, as you are about to bash on the work of all other team members…

Anko Tijman’s blog post can be found at: agiletesting-anko.blogspot.com.

Posted on January 9th, 2008 by aahoogendoorn
Filed under: Testing, Agile | 2 Comments »