Fear of Methodologies

In 1988 I graduated in geophysics, at Utrecht University. During my study, I was always drawn to programming. In the years after my graduation I worked as a field geophysicist, and when work was low I also did some programming. In 1990, my 2 year contract was not extended, mainly because the company had 5 field geophysicists and had only one crew in the field (a time of crisis in the oil business). After a few months I decided I'd make the switch to software development, and started at Cap Gemini.

This was my first confrontation with the horrors of the Waterfall model. Millions of guilders (now Euros) were poured into almost bottomless pits of top-down nightmare projects. The company was strongly involved with SDM (System Development Methodology) - a methodology still existing today. A methodology still making life difficult for legions of poor software slaves around the world.

I learned a lot in that year (actually a bit less than a year - I couldn't stand working there longer), and in many ways I transformed myself to a real software developer there. Of course there's a lot of useful knowledge in the fat books that go with such grand methodologies. When I left Cap Gemini for a geophysical software company, I knew much more about the whole process of making software, and also even much more about how things should obviously not be done. We are talking about 1992, the term Agile wouldn't be around for a long time. After, this, I went to the TNO (one of the Netherlands' national research organizations). In the three years there I read tons of books by the gurus of OO, and years of JOOP and C++ report. I got quite familiar with Object-Oriented software development.

At that point in time I could see essentially three ways in which people go about attacking a project:

1. The top-down, waterfall, project-management-driven way
2. Priority-driven, first-things-first solution-oriented
3. Unstructured hacking, technology-driven

At Cap Gemini, I had seen the blatant failure of  (1), and at TNO (3) was 'tested' many times. TNO asked themselves: why are we so bad at making software? They had traditionally been on path (3) a lot and they had hired people to try (1), which led to even higher costs and even less success. I myself had seen (1) fail miserably in the past, and was being put on projects where (3) wasn't leading to any real product. I started working, on instinct, on some sort of (2) route. This led to some actual successful products in the Oil&Gas software group, something they were not familiar with (and not prepared for BTW). The last one was the 'GeoProbe' project, which Paul and I took with us to found dGB.

At that point in time, newsgroups became popular, and I spent lots of time on comp.object. There, you could see something happening, although most of us could not foresee the Agile manifesto coming. I remember the discussions like the one about 'cowboy coders' (later renamed to 'cowhand coders' because of politically correct pressure). I also remember repeatedly advocating things like influence of architecture on the process of analysis, requirements negotiations, implementation-centered working, and so forth. Always opposed especially by a guy called Elliott (don't forget the 2nd 't' at the risk of being flamed for weeks), who was (and is AFAIK) always talking about a 'holistic' approach. I thought our camp would never amount to anything, because the Waterfall people were in power and nothing would ever change.

In 1998 I had major surgery because of a leaking heart valve. Because of that, I completely missed the Agile manifesto and everything around it. Moreover, I decided to no longer invest my precious time in people like Elliott - people thinking that making software is the same as making the perfect analysis and the rest just a semi-automatic road down to testing. So I quit the newsgroups completely.

In 2003 I came across the term 'Agile development' by chance. When I followed the links (the search machines were there by then) I could see: this is in fact the way we're working (by then, I wasn't the only software developer in the company anymore, we had a real team!). So, I signed the manifesto and from then on dTect (later OpendTect) was made using Agile methods. We did actually learn new things, but in general, we carried on like we did before.

Looking back, one of the major allergies I retained was for anything that calls itself a 'methodology', or that behaves like one. And I don't get intimidated by big wording anymore, especially after my second and even larger surgery in 2006 that nearly got me killed (I now have two artificial heart valves) - I simply try to avoid everything that looks like the old stuff in a new package. That is exactly what the project-management-driven people do. They know how to market their product, and simply claim to comply with the latest trend. Now who can guess which new trendy methodology I think does just that?