When you’re in Open Source your error longevity is nearly eternal

When you have a startup you ego-surf a lot. It isn’t for the normal reasons people ego surf (indeed there is something inside of me left over from my punk adolescence that dies a little every time I do this). It is for the reasons that PR firms ego search. To informally report how effective you are at making noise for your firm. In the process I discovered this vision document which explains why we (myself and Marcus Johnson) were creating a project that eventually became POI, a project hosted at Apache. I was curious so I looked around. It appears to me that this is a course on doing software the wrong way. I predominantly taught myself to program in 3rd grade after a short introduction at the now closed Howey in the Hills gifted center where the county sent all its old computers to die (TRS-80s, Apple-IIs and IIIs). I didn’t learn to write software “the wrong way” until I started taking college courses later on.

The wrong way involved a “Big Design Up Front” which assumes that you can learn and research everything before you start coding. It would take me a few years to unlearn this methodology. I’ve worked for several companies that used this methodology that was debunked in 1970 by Royce as well as partly in 1975 by The Mythical Man Month. They call this the “System Development Life Cycle”, draw it in a circle, and avoid calling it the Waterfall Model. These methods misunderstand software development to be like building a building or something physical. I noticed that most of the projects I was on at these big companies were “political successes”. That is to say they completely failed miserably but with no real effective way to measure failure except in the hands of those who had no interest in doing so, they were hailed as a success. When you bury people in meaningless process documentation, no one notices that you failed to meet any of the objectives in the Vision document. Because of my observations, I started unlearning this bad way by attempting to buy into the idea that this could be done “iteratively”, but later grasped on to various Agile methods to develop software.

Ironically, I was somewhere in between when I started POI. Still today I write various formal or informal vision documents at the start of a project. The point is to have something that a developer (not to mention bill-payer) can read and at least know what and why he’s working on the project — so far as we know. However, the POI vision document focuses on a now-defunct Cocoon Serializer as being the main point of the project. Fortunately, predominantly Dr. Stefano Mazzocchi stopped me from doing this. We split the project into the XML part (which I found out MUCH later that a few people actually did use and never spoke up) and the API part (which saw massive adoption in every financial institution in the world, governments, nuclear power plants [gulp] and later even the US Department of Homeland Security [gulp gulp]). Imagine what would have happened had we wasted a bunch of time doing a big up front design for that part before we really understood how most people would use POI?

Having that vision was massively useful for starting the project, the vision itself was crap. The unfortunate thing about Open Source and the Internet is that my sins live on in the archive for everyone to see (especially before I learned how *not* to communicate by email). The fortunate thing is that I get to warn students in “ece521” at the University of Alberta that they should pay only enough attention necessary to pass their tests and forget it all afterwards. Then grab The Pragmatic Programmer or this book (even if you don’t do pair programming). Then join an open source project and write some unit tests, fix some bugs and implement a feature or two. Finally, ignore what everyone says about Open Source, just like bad business models (selling less colorful ads on the internet) make profitable companies, less up-front design makes better software (this does not mean NO design).