Ted O'Grady

Agile Developer and Team Leader

home - resume - building software - projects - contact information -blog

Projects: A Brief History of Ted 

I have had a lengthy career, beginning with programming FORTRAN on punch cards as a teenager at Ottawa University. I went to Carleton University when object oriented programming was first emerging. I was fortunate to study under people like Dave Thomas, Wilf Lalonde, Paul White, and John Pugh. It was an exciting time which eventually led me away from the usability career I had planned and moved me into hardcore technology. That new career really began with OTI.

OTI - Agile Techniques and Asynchronous Callout

Dave Thomas and his wife Margaret Thomas founded Object Technology International (OTI) to build "objects everywhere". He had been the best professor at Carleton University and when I was offered a job at OTI, I jumped at the chance. Most of what I learned about building great software, I learned there. Unfortunately, I was too junior to contribute much, but I watched and learned other people build solid reliable code. One day I would like to return and contribute as much as I received to OTI.

I have tried to bring a piece of OTI wherever I go, to make great software in a great environment. I have since realized how really difficult that is. I have a deep respect for Dave Thomas.

OTI used agile techniques, before the words existed. There was extensive testing and communication in the organization to ensure the product was always up to snuff. There was also a great deal of respect for everyone and for how they contributed to the team. Even as a junior developer I was able to contribute the first cut of asynchronous callout (which I hope someone rewrote) for VisualAge for Smalltalk. 

RightsMarket - Building solid software

RightsMarket was a chance for me to stretch my wings. I had been through OTI where I was taught to build solid software, and I had just joined a company that, to my surprise, did not understand the importance of quality. They had a demo system running that was extremely fragile and required great care to make work.

Merv Matson and Lindsay Moir trusted me enough to let me co-lead the project with Alan Covington. At one point, it turns out there was just the two of us, writing IRAP grants to get our own salaries. 

Alan taught me the importance of simple architecture. I learned a lot about writing very simple protocols from him and simplifying the system. Between us we managed to get a Digital Rights Management system up and running in under a year.

Alan and I scoured books on Extreme Programming and Microsoft processes trying to come up with a process that would work for us. We used a combination of design notes, stand up meetings with management, and extensive testing to creating a working product on limited resources. We created our own nightly build to check our progress and moved everything (including the Smalltalk source) into CVS. In the end FatBrain began funding the project and RightsMarket was able to raise significant capital.

TeamWave - Building solid product

I had introduced Fred Yee from RightsMarket to a friend, Mark Roseman, who was just starting up a new company based on his thesis work at graduate school. Fred provided a level of business expertise that Mark did not have, and was able to fund the company. Once it was funded, they offered me a position. How could I refuse? I had done my own thesis work in the area.

It was a chance to work on the bleeding edge of technology. We were making an collaborative application that had a very small download footprint (<100K). It also had to download in your browser - no install. There was lots of innovation that made this client server application work. 

I myself got to lead the team, teach others about process and mentor junior members. I met Raymond Yip there. I was able to practice agile methods, adapting them to the new working environment. I introduced people to the testing methodology.

We learned an interesting lesson at TeamWave. Building good software does not necessarily build a good product. Fred Yee guided us through the painful process of turning the software into a product. When we got it right the company sold quickly. I remained in the company for another year or so, helping the product mature. Sonexis has the product for sale.

EFA Software - Turning around a project in trouble

EFA was an interesting place. I was given an opportunity, required to prove myself and my teams ability at every turn, and then had all the successes dashed when the company fell into receivership.

Alan Covington (from RightsMarket) called me up to tell me he was on a project in trouble and would I like to help. From my conversations with him, it appeared the problems were not technical (as in difficult to implement) so much as process and architecture related. These were things I felt I could help with. An independent consultant (ClearStream) had heavy criticism for the project indicating that it would fail.

Alan and I begin by critically reviewing the current architecture and process and looking for solutions. We were able to convince upper management that the system was amenable to a much simpler architecture and could be run with a pure extreme programming process. The problem space (many small bits of business logic) was suitable to this type of solution. 

We were given a small team (6 developers) to prove this with. Alan Covington, Nathalie Veerwal, Jane Robarts, Shaun Smith, Greg Cook, Ralph Bohnet and myself (as team lead) began the XP team. We used ClearStream to mentor us in pure XP. In 6 weeks we had demonstrated the core fundamentals of the system. We were able to collect statistics to demonstrate our progress, and had regular deliverables of such high quality that they left Chantal Schultz (our QA team) flabbergasted.

This eventually led to the Extreme Programming process being used to develop the software in the project. I scaled the team up to 12 highly skilled developers and we began delivering high quality code while tuning the process to the teams needs. An independent audit by the customer found the new process would deliver a working product in a timely fashion.

Unfortunately, because of the burn rate of the previous attempt and the resulting loans, the company went into receivership before we could deliver product.

Presslogic - Interesting Dilemnas

What do you do when you're asked to help a team improve their productivity but their client is happy and about to go live?

It was a multi-year project with a small number of skilled developers already working on the product. The application was a full J2EE application (using entity beans v1.0). The developers had written a bunch of code. Although it was written in Java, very few object principles were being followed, it was a cross between PL/SQL and objects. This made development slower and more painful. The team however had figured out how to work and be productive in this environment.

Changing things in such an environment had some successes: I managed to bring in automated tests, and richer tools, such as eclipse and Junit, but was unable to bring the environment any closer to XP. Not having contributed significantly to the environment, I left. A few months later they had a successful release to their customer.

ClearStream - Small Agile

A small agile team building an application called InformAlberta. Nine months of test driven development on the customers site, some pair programming, several good developers, each different skills (Gerard Mezaros, Andy Czerwonka, & Dale, later on Darryl Dafoe & Raymond Yip). We worked hard to build the application.

An interesting challenge on this project was the number of customer companies on the project - three. Learning to manage needs and expectations with the limited budget was interesting. One of the most effective tools was the "orange bar" on the burn down chart. It represented the last feature we thought we could get in for the money available. As our velocity changed or new features were added the customer could see the effect on the product wish list.

CGI - Large Agile

Now I'm leading a project with Joseph King and Colin Jones. We're building a production accounting system. We have a team of 12 developers (soon to be 17). We are replacing an application that has been developed for 20 years in Cobol. We have 4 customers (Inform Alberta was useful training!) each of which have given us 2 production accountants (8 live customers on site ALL the time!).

We're practicing Agile development: standup meetings, test driven development, monthly releases, just in time design, just in time architecture, pair programming, stories & constant communication with the customer. Our customer actually provides us with the test before we begin coding. Sweet.

We have thrown in a couple of wrinkles - a QA team for exploratory testing (something I learned the hard way from InformAlberta), fewer unit test ala Brian Merrick and more Business driven examples. This leaves the code more malleable (technical facing tests make your code harder to change).

Right now we have 2200 tests. The running bet is we get to 10,000...