Nostalgia...
I recently came across a handful of post-project-review materials for one of the projects that I worked on in Germany in 2001. One was a draft of a paper that I co-wrote and an internal presentation that I gave called "Enfinity: The Good, the Bad and the Ugly" which reviewed our experience of using the Enfinity e-Commerce "platform" to implement a wine marketplace (xWine) for Italian winemakers and German retailers. The audience was the company's Frankfurt-based programmers/developers who had had little/no contact with Enfinity and, with one exception, no involvement in the xWine project. Both the paper and the presentation were intended for internal distribution only, but as
Much of the prose in the draft of the paper was written by my then-colleague Gregor Klinke, whose English is considerably better than my German. The draft is well and truly readable despite some of the, ah, improved grammar.
The slides that I prepared for the presentation were rather minimalist. One of the participants did work out that what I was using was a web-browser in fullscreen mode (showing no chrome at all) rather than, say, PowerPoint with the corporate template. It has been interesting to watch, over the last year or so, the growing backlash against using cluttered corporate PowerPoint templates, or in fact, using PowerPoint at all. I am no longer alone...
It is amazing (well, for me) to watch the video (379MB) five years on; I can't quite believe that my hair was so long at the time. It's sad that there wasn't a microphone closer to me (what was used was the built-in microphone on the camera, which was several metres away) and that the recording ended abruptly a couple of minutes before the Q&A ended, but it's adequate. If you, dear reader, do decide to watch it, then it's worth knowing that the only person in the room who did not have recent experience in implementing e-Commerce systems was my boss, Jürgen. He was also very much in favour of the use of Enfinity. He starts the presentation sitting on my left but, by virtue of taking a phone call during the presentation ends up on my right (actually to the left side of the projection screen, from the camera's perspective). Naturally it was while he was out that I was explaining why his favourite part of Enfinity (a flowchart editor) was, in reality, not so helpful.
I also found a draft of some sections that I wrote for IPM, the Integra Project Methodology. Most of it is a repeat of the above, but there was also a little on some mis-steps in sizing the project team; here is an excerpt:
For the xWine project, Integra Germany assembled a team of twelve developers, two of them front end specialists, ten to handle the back end. Of the ten, less than half had substantial previous programming experience and only one had ever worked in a programming team of more than four people. In hindsight, this was always going to be a difficult proposition, but some of the more serious difficulties that this created could have been avoided with a more careful assessment of the team's makeup.
- none of the German company that I worked for (Integra GmbH), its French parent (Integra SA) or the customer (xWine) still exist,
- none of this material is the implemented system itself
- Intershop's Enfinity is now at release 6 (we used release 2, which was their first Java release and was more or less a case study in Second System Syndrome) and therefore presumably no longer exhibits any of the described problems
Much of the prose in the draft of the paper was written by my then-colleague Gregor Klinke, whose English is considerably better than my German. The draft is well and truly readable despite some of the, ah, improved grammar.
The slides that I prepared for the presentation were rather minimalist. One of the participants did work out that what I was using was a web-browser in fullscreen mode (showing no chrome at all) rather than, say, PowerPoint with the corporate template. It has been interesting to watch, over the last year or so, the growing backlash against using cluttered corporate PowerPoint templates, or in fact, using PowerPoint at all. I am no longer alone...
It is amazing (well, for me) to watch the video (379MB) five years on; I can't quite believe that my hair was so long at the time. It's sad that there wasn't a microphone closer to me (what was used was the built-in microphone on the camera, which was several metres away) and that the recording ended abruptly a couple of minutes before the Q&A ended, but it's adequate. If you, dear reader, do decide to watch it, then it's worth knowing that the only person in the room who did not have recent experience in implementing e-Commerce systems was my boss, Jürgen. He was also very much in favour of the use of Enfinity. He starts the presentation sitting on my left but, by virtue of taking a phone call during the presentation ends up on my right (actually to the left side of the projection screen, from the camera's perspective). Naturally it was while he was out that I was explaining why his favourite part of Enfinity (a flowchart editor) was, in reality, not so helpful.
I also found a draft of some sections that I wrote for IPM, the Integra Project Methodology. Most of it is a repeat of the above, but there was also a little on some mis-steps in sizing the project team; here is an excerpt:
For the xWine project, Integra Germany assembled a team of twelve developers, two of them front end specialists, ten to handle the back end. Of the ten, less than half had substantial previous programming experience and only one had ever worked in a programming team of more than four people. In hindsight, this was always going to be a difficult proposition, but some of the more serious difficulties that this created could have been avoided with a more careful assessment of the team's makeup.
Three phases of the project are interesting here:
(Prelude: Six weeks into development, the development team was restructured, shrunk to ten people (seven of them backend developers, two of those seven were experienced developers) and all moved to a single city; a single room in fact.)
- During the first week after this move it was observed that the less experienced developers in the team were frequently having trouble completing the tasks that they had been assigned and were spending a very large amount of time stuck on a problem that, with help from someone more experienced could be solved in minutes. A "get help fast" rule was introduced. This increased productivity for the less experienced developers but promptly caused the people who were being asked for help continually to have trouble getting any work done at all.
- A happy medium was sought in which people needing help were to spend at least some time trying to fix the problem before interrupting someone else. We operated in this mode for another five or six weeks. This was still frustrating and difficult for the more experienced developers in the group who took to working odd hours, not attending meetings, etc. in order to gain some amount of uninterrupted time in which to get creative work done.
- At thirteen weeks, for contractual reasons, the development
team shrunk again to five (one front end, two experienced back end, one inexperienced back end and a technical-project-manager/developer) for the final four weeks of the project. During this period, output went up dramatically. Number of check-ins is a very coarse measure, and it is fair to say that we were late in the project so we were doing lots of small changes rather than creating new files, and we were working longer than normal hours, but number of Java file check-ins per developer per day went from about seven to about seventeen. The output of the team as a whole went up by about 25-30%.
The primary cause of this large shift appears to have been that the team's more experienced developers were more frequently able to work without interruption or distractions for longer periods of time.
Not apparent from the above is the impact that this situation had on the quality of the software that was developed. Several parts of the system required components to be implemented that were particularly complex, particularly abstract or both. These were typically beyond the reach of team's less experienced developers, but required long periods of uninterrupted focus for the team's more experienced developers to produce. During the second phase listed above, work of this type was frequently delayed for weeks. This in turn led to large amounts of code being written that worked around the absence of these key components which rendered the system as a whole larger, more complex, less consistent, less robust and less maintainable then it would otherwise have been.The lesson that we have drawn from this experience is that, whilst is tempting to bulk up a project team with less experienced developers, both from a revenue standpoint and for the opportunity for less experienced developers to learn a great deal, the results can be very damaging to the project itself. Certainly, having experienced developers out-numbered two or three to one by less experienced developers was excessive. We suspect that a ratio of about 1:1 is about right. This
- allows the team's more experienced developers time to create the more complex parts of a solution,
- still provides plenty of scope and support for less experienced developers to learn while remaining productive and
- avoids the costs associated with paying experienced developers to handle even the simplest parts of the implementation of a system.
<< Home