For this next part, we now enter in to the .com boom where I was engaged to develop XSIQ, a hybrid media system for the education of schoolchildren. This was just on the edge of the Internet revolution, when we were still using modems and broadband was non-existent, with the closest thing being ISDN phone connections for the fortunate few. As a result, whereas today you’d just do this as an online application, due to the bandwidth restrictions at the time, the material would be contained on both CD and the Internet, which made for quite a complex system that resulted in patent applications. Again, I used iterative development with a small team of around 5. We were closely engaged with the VP, who I quickly taught to read Use Cases so we could talk with him about our high level requirements. We weren’t doing Scrum, but we did:
- Have a “demonstration server” that the VP and other management could use at any time – even the CEO used it and would sometimes give us feedback
- Do iteration planning and had “cycles” that lasted 1-2 weeks
- Get together pretty much every morning to talk about what we were going to do for the day
- Pair up to program or meet when necessary to work through any tough design problems
The deployment was successful, reliable and never had any performance problems. It was also on time and budget – it had to be as there was a national advertising campaign linked in to the whole thing!
Being a contractor though, I was off to the next big thing, which was developing a publishing system for Encyclopaedia Britannica, that involved a lot of Flash and was a lot more static than the XSIQ system. The project was started, but slowly flying off the rails, so the first thing I did (as the Technical Architect) was ask the PM (who was pretty young and inexperienced) if he minded if I re-cut his plan. To his credit, he said yes and about a week later, we had a plan with iterations (of about a month). Around this time, I came in to contact with Feature Driven Design from Jeff De Luca, which certainly helped achieve a successful implementation of the the project. All this was done in the context of a fully traceable and round-tripped design modeled in Together/J, which enabled me to do my “real job” – that of a Technical / Application Architect.
After a quick trip back to XSIQ the .com crash happened and it looked like all bets were off. Luckily, there were still a number of smaller companies doing some very interesting work, one of which was Jumbuck, who were only just starting their efforts in the Chat space using WAP (remember, this was 2000 – oh how quickly things have changed!). They had developed a prototype, but needed to take this to a commercial level for deployment to a major Telco in the United States. Due to the collapse of XSIQ I was then able to nab one of the best developers I’ve ever worked with to join me in this aggressively time-boxed task (2 months). Again, being “pre officially agile” we decided to go with what we knew, which was iterative development with a “cycle time” of a week. After a quick week of “drains up” (and some refactoring of some low-hanging code) on the existing code (which was totally non-scaleable) we were then able to come up with with a system that not only performed to a level so the guy could get his funding, but also to a level that we bought down the WAP gateway infrastructure of a major US Telco!
With the .com crash – I’m not sure how it happened in US, but in Australia it was more a “wind down”. It’s not like there was no work the next week, it’s just that there was less and less of it for fewer people. Luckily, as a coding Technical Architect, I could pretty much turn my hand to anything and the last “.com” era contract set the scene for what was to come. The company was WebM3dia and the project was using Flash with Web Services, before it was even out! Mike, the programmer from the previous project had run across these people and bought me in as the TA, but I ended up doing more than that. Technically, it was my first exposure to JBoss, which I did quite a bit of work with later and as mentioned, we were hooking it up to Flash before it really had Web Services capability to product one of the most amazing email and productivity apps I’ve ever seen! These guys were whizzes with flash and everything was pseudo 3-d with folders that “exploded” out your emails, stacks of items that compressed and expanded like accordions. Boy it was cool, but there was only one problem – no one really wanted it, plain old boring outlook and web mail was good enough.
It was the path to the slow death of WM that was interesting for me as I did two other things – I wrote about 150 pages of requirements for the system using Use Cases (my one and only time as a “real” BA) and I did some work with their development process, which was the really interesting thing. WM had a quite mature, “Agile like” process for doing their creative work and with their new predicted direction, wanted to incorporate software builds in to it. Using my knowledge of RUP, it seemed to make sense to incorporate an iterative approach to software and have client engagement as after all, that was what they did with their creative and advertising work. The actual process itself was graphically beautiful too as one of their lead designers had worked on it, so I just reused all the graphic elements for my extensions. I wish I had a copy of it somewhere, but like WebM3dia it too is lost in the sands of time. I had however gotten the “process bug” – I think I’d finally drifted in to the realisation that to fix the problems I was getting as a Lead / Architect it would be worth it to get a bit more serious as you’ll see in the next part…
PS Missed the first part? Read Agile Baby Steps – Iteration 1