Funny developer tale
by Jerome Kehrli
Posted on Thursday May 06, 2010 at 11:03PM in Computer Science
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 :
- 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.
- 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).
- 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).
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- We went back to the project management and showed them the prototypes. They appeared quite happy and decided to present them to the stakeholders.
- 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.
|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|
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.