[DG: Open Forum] [Announcements] Sakai OAE

[Mark J. Norton]

Are you telling me it needs to be re-designed?

Thanks for sharing that, Zach.

- Mark

On 9/7/2012 2:33 PM, Zach A. Thomas wrote:
> On Sep 7, 2012, at 11:53 AM, Mark J. Norton <markjnorton at earthlink.net 
> <mailto: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/827b920b/attachment.html