Projects

I do like the idea of software designers showing portfolios of their creations. After all, methods, processes and tools are very interesting in themselves, but what is the bottom line? What did we get built for our users? What business issues did we help address with our skills? And what lessons did we learn?

Here is a brief description of my portfolio and its associated lessons, in a chronological order, starting from 1996.

1. Virtual reality interface for the preparation of teleoperation missions
2. Rich user interface based on Gantt charts for a geological explorations planning tool
3. Interactive simulator for the validation of a subway's supervision system
4. Server managing topological information for GSM telecommunication networks
5. CORBA Object Request Broker (ORB) implementation for a C++ communication framework
6. High performance / high availability server for low-level communication with telecommunication network nodes
7. Advanced provisioning system for telecommunication networks
8. Financial portfolios analysis system

1996 - A virtual reality interface for the preparation of teleoperation missions

This was my professionnal internship project, conducted in a robotics research department of the French Atomic Energy Commission (CEA). The goal of the research project I was working on was to explore new means for teleoperators to prepare maintenance missions involving the remote control of robots in nuclear installations.

This project was downright fun. I was working with cutting edge technology, with all sorts of weird equipment: virtual reality goggles, a spaceball for navigating the virtual space, etc. But it was also really useful: the researchers and PhDs I worked with were very pleased with the prototype, which allowed them to improve their vision of what the system could be and also to perform tangible demonstrations of their research.

This project ignited my passion for user interface design. Working in a 3D environment, we had no predefined GUI components or methods to work with. We were trying to invent new means for the users to interact with the tool. I learned then to see user interface design as a means for creating a rich experience for people living in different contexts than mine, rather than just putting together a bunch of widgets and wiring callbacks in an editor.

1997- A rich user interface based on Gantt charts for a geological explorations planning tool

This was my first project as a software professional. I was the sole developer on a fixed time/fixed scope project, responsible for creating an usable interface for an existing constraints resolution module. The purpose of the whole application was to optimize the use of expensive equipment based on an evaluation of the probability of finding gas resources in various geological sites.

This was a short project (4 months), but I learned my first lessons about software rot. I clearly lacked programming experience, and I was having too many "segmentation fault" failures at the end of the project to be back home early at night... I then resolved to learn more about the programming language I was using (C++), and also about software design - it is then that I first read the Design Patterns book, something that definitely changed the way I saw my job.

In spite of these difficulties, I completed the project on time, and the customer was visibly very satisfied with the product - but it had cost me too much overtime to consider it a real success.

1997 - An interactive simulator for the validation of a subway's supervision system

This was also an outsourcing project with a fixed time/fixed scope contract, but this time I was not alone - I was joining a 3-people team on a project that had started several months ago, and that was supposed to be finished soon. Or so they thought.

The product was a simulator based on a graphical representation of the railway network. It was designed with two goals in mind: validating the supervision system of a subway, and training the railway operators in using that system.

Had I read The Mythical Man Month at that time, I would have known that being added to a late project was not such a good idea. I won't go into much detail here, I will just say I now have a very clear picture of what a deathmarch project can be. Eventually, we stabilized the software and shipped it.

This project has had a deep influence on me. At that time, I resolved to understand what had gone wrong, and how I could prevent my future projects from sharing the same fate. I guess this is what made me so receptive to XP afterwards.

1998 - A server managing topological information for GSM telecommunication networks

This project was taking place in a large telecommunications company. I was working on the maintenance of a C++ server that was part of a large GSM supervision and configuration system.

The work in itself was not very exciting, but it was nonetheless a very important period for me since at that time I further explored the patterns books (GoF, POSA, and those of Christopher Alexander), I acquired a much better understanding of the subtleties of C++, and I learned the design principles described by Robert Martin on the Object Mentor website. And one day, while searching for still more articles about object oriented design, I discovered a website called "Armaties", where a group of american consultants were talking about a new methodology where people were writing unit tests and coding in pairs. We were in 1998 then, and Extreme Programming was being invented.

After maintaining for a year a software that wasn't far from being definitely unmaintainable, I had the opportunity to rewrite it - and then my readings on object oriented design were put to good use.

1999 - A CORBA Object Request Broker (ORB) implementation for a C++ communication framework

I was part of a 15 people team that was working on a CMISE-based C++ communications framework used by about 40 development teams around the world. Within that team, I was working with 3 people to implement a standards-compliant CORBA broker on top of the existing framework. I worked on the design of the stubs and skeletons that were to be used by the framework users, and I also implemented a number of standard CORBA services such as a Naming Service or a service supporting CMISE-CORBA interoperability.

With this project, I had the opportunity to understand the innards of a communications framework, and I learned about the specific challenges of developing APIs for others. I also integrated unit testing into my work habits. But something was still missing: I was getting tired of always working alone in fragmented teams.

2001 - A high performance / high availability server for low-level communication with telecommunication network nodes

I was working in the software development department of another large telecommunications company. This department was responsible for developing a supervision and configuration system for 3G mobile telecommunication networks.

I was assigned a kind of "SWAT" mission: I was to lead a "virtual team" constituted for a predefined time with people from existing teams, and our goal was to redesign the "lower" part of the architecture, namely a number of applications that were responsible for the low-level TCP-IP communication with network nodes (but which were not very successful at that). We had tight plans and no room for failure: we had to deliver on time, and our applications were to be rock-solid right from the start. This was a tough assignment, but also a major opportunity since we were allowed to use the Extreme Programming process despite the fact that we were evolving in a very large industrial setting, within a waterfall-based process.

We spent nine stressful and exciting months on this project, trying to put together all our XP practices in a coherent whole and to meet our deadlines at the same time. And it worked. We shipped on time, and the validation teams found very few defects in our software - about a dozen for a 50 men-month project, which was an unprecedented event in the departement. We were all hooked on automated testing!

2002- An advanced provisioning system for telecommunication networks

This time I was to build a software allowing operators to quicky and confidently configure the millions of parameters that need to be set when putting up a 3G telecommunications network. We had two challenges facing us: coming up with GUI solutions for working efficiently with huge sets of data, and finding a way to model and implement the numerous engineering rules needed to build and check complex network configurations.

I spent the first year of that project with two developers, incrementally designing and building the new application. After that, our managers gave their approval for the industrialization of the product, and then the real challenge began. It was a difficult challenge because we had to replace an existing tool that had a large feature set, and we had to propose our customers a product that was at least equally mature - and naturally, we had to implement it in a fraction of the time it had taken to build the first one, even though the new application was completely different from the first.

Six months later, there were 25 developers on the project, split into two teams. Both teams were using the Extreme Programming practices, with minor adaptations designed to maintain some compatibility with the official process. And it also worked. It even worked very well: six months later, we shipped on time, with low defect figures, and the product was named "best in class" by our first customer. Four years after its inception, this project is considered a major success, and the product is becoming a standard in the company.

I have learned two important lessons in this 4-year adventure. First, I have gained a deeper insight into the mechanisms by which an application can be grown over a long period of time and still retain a clean and very flexible code structure. Second, I have come to fully realize how the success of a development project is tied to the relationships of the people in the project - the words " The team is the product " that I read in Software For Your Head a few years ago come to me increasingly often these days.

2006 - A financial portfolios analysis system

I am now working in the finance sector, helping a startup reap the benefits of a successful implementation of Extreme Programming practices. But since this is still work in progress, I won't delve into too much detail now. Stay tuned!