Technological Thoughts by Jerome Kehrli

I've been working a few years ago on an architectural concept for some very specific piece of software my former company had to develop. The technical challenges were huge and the field was pretty complex. In addition, the timeframe was very little and we have had to rush a lot to get it ready and prototyped in time.

In the end we screwed up ... totally. The concept was miles away from what was required and we pretty much had to start it all over. Months of work were just good enough to be thrown away with the trash.

Not used at all to such failures, I decided to take some time to understand what happened, what went wrong.

My investigations led to the following story, a pretty funny though quite common developer tale :

1. First there was the IT management which wanted to replace old technologies which were soon going to lack a proper support from the editors with brand new cutting edge technologies. They decided to build a team intended to replace the legacy system by a new one, taking that opportunity to refactor a few things the company was suffering with the legacy system.
   The IT management designated a project management for the team and told them to go seeking for information on what needs to be done by the new system and how to do it.
   
2. The project management put in place a few meetings with various stakeholders.
   They first met the business users trying to get the business needs. Business users are busy people. They don't have time to spend days in meetings. So instead of telling about the legacy system and what it's doing, they told about what they wanted differently in the new system and what they wanted in addition (that leap not being obvious of course).
   
3. A bit puzzled, the project management then went to the sysadmins of the legacy system. The guys all have long beards and white hairs and were really not enthusiastic at all about replacing the system they were working on for the last ten years and they knew so well. They were definitely not open to provide any help in getting rid of what gives them a job And feeds their family (that reluctance not being obvious of course).
   
4. More puzzled, the project management went to the team leaders of the development teams working on the legacy system. The guys all only had a very scarce view of the system functionalities, the big picture being spread amongst all the development teams. Even worst, in their own private field, they had obsolete views on pretty much everything. The system growing in complexity and their respective teams growing in head count, it soon became impossible for them to stay aware of what was being implemented on the system. Yet they are the funder of that system and not willing at all to admit their knowledge is obsolete.
   Being nice guys, they spent all the required time with the project management feeding them with wrong information most of the time and obsolete in any case.
   
5. Finally, the project management spent time finding all the documentation they could about the legacy system. Yet again, that documentation was either inexistant or obsolete (I mean not just a bit, the latest document they found was 6 years old) and wrong.
   
6. And so they figured they did all they could and that it was about time to get the project moving. They took quite a great deal of time writing specifications with what they understood. Then, sure as hell the document is as complete as possible, they went to the architecture team.
   
7. This is where my team kicked in. The project management came to us with the specification document and asked us to come up with an architectural concept enabling the future development teams to start the migration of the legacy system to the new technologies. We were all quite experienced and smart engineers cumulating all together a lot of experience.
   I do believe experienced architects have one serious drawback (although lots of qualities as well). They tend uncounsciously to fill the voids in specification with what they already know on the kind of the system they are trying to build, assuming they know how it should work and what it should do. This is unfortunately very rarely the case and I know now that one of the most important values an architect should embrace is not to leave any room to uncertainty.
   Nevertheless we took good care in reading the specifications and discussing the document with our management. Once we figured we had a pretty clear view of what we've been asked to achieve, we put ourselves at work.
   
8. A few months later, we were there staring at our architecture, damn sure everything is well thought out and quite clever. So we went further to the developers and built a little team which we asked to write a few prototypes on top of this architecture. We're smart guys, right ? Why the hell should we need specifications for these prototypes ? Let's be agile.
   
9. Finally the development team put itself at work. They wrote the prototypes in a few weeks and got back to us when they were done. We looked at those prototypes and, besides a few things, we figured they were more or less in the scope, at least definitely enough to be presented to the stakeholders.
   
10. We went back to the project management and showed them the prototypes. They appeared quite happy and decided to present them to the stakeholders.
    
11. The presentation was set up. This time, in addition to the grinchy sysadmins, the development team leaders and the busy business users, a lot of the legacy system developers were here as well. The presentation began and all went ugly, really really bad. The concept was so far from what it was supposed to be and do, it all turned to a giant riot. People were shouting, yelling and very soon no one was happy anymore.

And how could it have been any different ?

There has been what was told to the project management, what the project management understood, what the project management told us, what we understood, what we designed, what we explained of the design to the developers, what the developers understood, what the developers implemented, and finally what was presented to the stakeholders ... How can such a project eventually succeed ?

They say a little picture is worth a thousand words. I found this pictures which I believe summarize pretty good this very issue :

How the customer explained it	How the project leader understood it
How the Architect designed it	How the Programmer wrote it
How the Business Consultant described it	How the project was documented
What operations were actually installed	How the Customer was billed
How it was supported	What the customer really needed

(I haven't been able to find who these pictures belong to so please contact me in case of copyright infringement)

Happily there have been a lot of trends in the last decade aiming at preventing such failures to happen again, let's just thing of XP or Agile to name only those two.

We should definitely have integrated from scratch two key people in the architecture/development team : a business user and an experienced developer from the legacy system. These two persons could have pointed out from the very beginning the mistakes in understanding or interpretation and they would have kept everyone's mind on track.

A good starting point with XP I would recommend is Kent Beck's classical "Extreme Programming Explained: Embrace Change"
http://www.amazon.com/Extreme-Programming-Explained-Embrace-Change/dp/0201616416

Integrating these people was eventually what we did and thanks to them we succeeded in architecturing and designing the new system, too bad it's been 2 months late and after being laughed at by the whole IT. The migration process is now running well.