Some folks use Waterfall. Some use Agile. A. W.'s team uses Waterfagile. Now you might ask, wtf is waterfagile? Well...fasten your seatbelts...

A. W.'s manager was charged with designing a black-box replacement for an existing system that was over-engineered, over-complicated, over-interfaced, over-configured and utterly incomprehensible. The highly paid consultants who wrote it have all long been let go. Before they could write up user guides, developer guides, architecture diagrams, or pretty much anything else. All of the records of the licenses for the third party libraries used by the project were lost or misplaced. When something went wrong, the only plausible answer was: sorry, we can't fix it, so incur the loss.

The new system had to be bullet-proof. It had to be scalable by 4 orders of magnitude. It had to crunch all that additional data in less time than the current system. It had to be fully configurable, so users could enter a new task-name in a web form, and the application would magically perform the described action.

Naturally, the developers pushed back to dial down the lunacy to the realm of merely theoretically plausible.

Faced with a near revolt on his hands, the manager decided that the best way to handle all of this was to combine the best attributes of waterfall and agile methodologies. To this end, he had A. W. and another architect designing the main features and control structures. Then he had the junior developers following behind them doing the implementations. However, since there were so many tasks to do, he would hold a special scrum with the architects every three weeks to plan out the next sprint. He would essentially go down the list of tasks in the waterfall project plan, and dole them out based upon the number of available hours for each person.

However, he had each person available at 90%. Hmmm, that means 4 hours of other stuff each week. However, he scheduled each person with 10-12 hours of meetings each week, including the daily 60 minute scrum, during which each of 12 developers would spend 5 minutes talking about what was, what will be, and blockages. When the consultants started rolling up the billable hours, he ordered them to limit it to 40 hours per week. Of course, then the work wasn't being finished on time.

After numerous meetings to discuss why work wasn't being finished in the allotted time, he was finally convinced that the excess of meetings, limited hours and basic arithmetic added up to the problem. His solution? Work more hours but don't bill for them. The consultants in Kerbleckistan knuckled under and did it. The more senior folks in the office decided that if they couldn't leave after 40 hours and they weren't being paid for over 40 hours, that they'd just run all of their errands during the day.

This went back and forth for a while until they finally tried to run the very first load test for the new software. It turned out that 84% of the CPU time was spent in one routine. But this was no ordinary routine. No. It was the access control list to set state variables. You see, it was important to control who could call the public setter for each state variable in each class. Lists of classes and methods were mapped to each state variable in each class. Thus, instead of simply setting a state variable, each setter had to first call a routine that would look up a class, then the state variable in that class, and then look to see if the class that wanted to change it had permission, and then if the method in that class that actually wanted to call the setStateXyz(...) method had permission to call that method. All of that just to set a variable. Each and every time. Billions of times.

The rewrite is now undergoing a rewrite.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!