Wilhelm isn't really much of a smiler. Nor was he much of a laugher. Nor a crier, scowler, or high-fiver. He seemed to only be capable of two emotions: "emotionless" or "asleep."

He's of the opinion that programming has gotten too easy in recent years, not like it was back in his day when programmers were programmers. A time before garbage collectors, transactions, protected memory, fancy IDEs with fancy integrated debuggers — nowadays developers have it too easy.

One of his company's core applications had been rushed out the door with most maintenance being of the "quick patch" variety, with the intention that everything would be cleaned up later. Because of this approach the overall design of the system wasn't totally consistent — duplicate code, instance methods that should be static, classes with tons of extra properties that aren't even really used anywhere, etc. With all of the extra objects floating around in memory, OutOfMemoryExceptions were the rule rather than the, er, exception. Some of the time the errors would magically fix themselves, but with increasing frequency, a developer had to step in and restart the site to release resources.

Once it got to the point that this was happening daily, management realized the problem couldn't just be swept under the rug. When Wilhelm caught word that they'd get a chance to resolve some of the memory issues, he jumped at the chance to lead the project. He had the skillset as far as he was concerned, since he cut his teeth on Commodore 64 development where he had 64KB of memory and was happy about it. And how different could memory management be nowadays? With some competent staff and his experience with efficient memory management, he could dramatically reduce the application's memory footprint. Wilhelm was given four developers to help with the task.

First step: analysis. Wilhelm and staff prepared spreadsheets, charts, and graphs out the wazoo. Running profilers and stress testing tools they were able to identify trouble modules, unreleased resources, and unclosed connections.

Second, branching the code and tweaking algorithms, static-izing what used to be instance methods. The team worked day and night on small refinements, creeping closer and closer to their goal. Changes had a tendency to delay development, as some parameters were being set too conservatively, breaking something else down the line. Some of the developers complained, but it didn't bother Wilhelm — the sissies hadn't suffered through the hardships of programming on older hardware, and this was molding them into something closer to real programmers.

After five months of grueling optimization and fixes, the team had finished. Admirably, they had succesfully reduced the application's memory footprint by more than 50%! His team still complained about some of the work, but Wilhelm knew they'd eventually adjust to the new programming style.

So Wilhelm, known for his emotionlessness, had a huge smile on his face when he summoned everyone into the conference room for a meeting. "First the good news," he began, "The memory footprint is now 46% of what it was before." He started doling out impressive-looking packets with detailed graphs and overviews of big changes to the system. "Now if you'll all turn to the second page, I'd like to go over some of the architectural changes. Before that, though, any general questions?"

Jake C. happened to be at this meeting with a new intern named Bob. Bob raised a finger and said "Yes, I have a question — this graph shows the percentage of the memory footprint reduction, but what are the actual numbers here? How much memory is in the production server?"

"512MB," Wilhelm replied.

"Ahh, OK." Wilhelm scanned the room for more questions. Bob raised a finger again. "So why not pick up another 2GB of memory for fifty, sixty bucks and install that in the server?"

Wilhelm was taken aback. With a light stutter, he replied "Yeah, I guess that would've been an option too..." After a brief but intensely awkward pause, he continued with a quivering voice "...but no web application should ever require more than 500 megs."

Wilhelm continued with his presentation, his face a bright shade of red. His manager's face turned a similar color.

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