[DG: Open Forum] [Announcements] Sakai OAE

[Zach A. Thomas]

On Sep 7, 2012, at 11:53 AM, Mark J. Norton <markjnorton at earthlink.net> wrote:

> Why is it taking too long?

Remarkably, Uncle Bob Martin told the whole story even before it happened, in episode 1 of his Clean Coders video series.[1] Here is the relevant portion. I've added footnotes to show where the OAE story deviates (it's not by much). We lived out versions of this story three times: when OAE started as Sakai 3, when we replaced Jackrabbit with sparsemapcontent, and whatever is going to happen next.

Zach

P.S. Disclaimer: I'm one of the developers who was downsized. It makes sense; I was relatively expensive.

> # The Productivity Trap
> ## © 2011, Uncle Bob Martin
> 
> Have you ever worked on a greenfield project? Do you remember how productive it was? Lightning would crackle from your fingertips as you got feature after feature working. You were going fast. Users would come to you and ask you for something new and you could have it to them in a matter of hours or days.
> 
> But the speed didn't last. A year or two later, things had slowed to a crawl. The harder and harder you worked, the slower and slower things seemed to go. And why? Because of the mess that had grown in the code. And slogging through that mess had really started to slow you down, and slow you down a lot. That high productivity you enjoyed at the beginning had now plummeted. Things that took you hours before took you days. Things that took you days before now took you weeks, months, or can't even be done at all.
> 
> Managers grew concerned. After all, they had based their plans on your high productivity at the start.[2] Now they faced a very scary gap in their business plans. The first strategy used to fill that gap was to put more pressure on the software developers. This served only to drive the developers to make even bigger and bigger messes, and despite heroic efforts, slow down even more.
> 
> Next, managers tried to add more people to the team. This, of course, caused productivity to plummet as the new people sucked the life out of the old people.[3] Then, the new people started working faster, making messes of their own, slowing everybody down even more. Adding man-power's not cheap. So now managers were faced with ever increasing cost and ever decreasing productivity.
> 
> In desperation, they turned to the programmers and asked the programmers what _they_ thought should be done. Of course, the developers knew exactly what to do. They'd been beating the redesign drums for months now. One of them said, “The best thing that could happen to this system is to walk into the machine room with a great big magnet. What this system needs is a major redesign.”
> 
> Managers were terrified of this option. They knew exactly how much this was going to cost, and they had no confidence at all that it would leave them in a better situation. But what else could they do? Reluctantly, they canceled any other plans they might have had, and they authorized a redesign for the whole project.
> 
> For the developers, it was as though a new day had dawned. We were gonna do a greenfield project again! We could get away from the mess and be productive! Oh, happy day! So we picked the ten best and brightest, the movers and shakers, the ones who would lead us away from the mess into the promised land of a new, greenfield project.
> 
> The rest of us hated those guys, because customers were not going to wait for the Tiger Team to finish whatever they were doing; Customers needed bug fixes and new features, so we were left to slog through the mess, while the Tiger Team was off doing some greenfield thing.
> 
> Meanwhile, the Tiger Team needed requirements. And where do you think those requirements were? You think there was a requirements document? Even if there was, do you think it was accurate? No, there were too many last-minute fixes and midnight modifications for the requirements document to really mean anything. The real requirements for the new system were in the old system, in the old system's code.[4]
> 
> And so now, the Tiger Team was forced to slog through the code of the old system, trying to figure out what the requirements for the new system were. And so began a race, like Achilles and the tortoise in Zeno's paradox. Every time the Tiger Team got to where the old system used to be, the old system had moved on with new fixes and new modifications. I've seen that race go on — for ten years.[5]
> 
> During those years, one by one, the members of the team were gradually replaced. The system became messier and messier, started getting twisted and warped. Eventually, even though it had never been deployed,[6] the developers on the team started demanding a redesign.


[1] http://www.cleancoders.com/codecast/clean-code-episode-1/show

[2] This wasn't true in our case. As far as I know, we never used our team's historic performance as a yardstick for making new plans. We were going to deliver our _first_ velocity calculation on August 30, but the NYU withdrawal occurred on August 28.

[3] I wouldn't go that far! It's too strong to say that growing the team "sucked the life" out of us, and I like the people we added to the team very much. But I'm pretty sure we didn't speed up.

[4] OAE is a little different in this regard, because we didn't set out to create a feature-for-feature copy of CLE, but many institutions had the (reasonable) expectation of a migration path from their CLE system to an OAE system. Four years later, we don't even remotely have a system that you could consider migrating to from CLE.

[5] Again, because OAE diverged and became a different kind of product, we didn't have the problem of chasing another team.

[6] OAE has been deployed, thank goodness! One of the things we got right was trying to shorten the release cycle.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/openforum/attachments/20120907/9cd7cd56/attachment-0001.html