At a previous company, my team was working on building complex communication products, which had components on a variety of platforms, including Linux-Arm, Linux-x86, Windows, and WinCE. On one particularly hectic month, we were working hard to finish up the "communications protocol" component so the 4 major platforms could interoperate. We were scheduled to do a customer installation in just 3 weeks, and we still had a few small, but important, features to implement.
At one point, I went to check in with a particularly eccentric developer, Fried, who was holed away in a large, but distant, room. Dozens of shiny silver CD's were strewn all around the room, two or three deep near his desk. I just had to ask.
Fried replied that he was finishing up the next iteration of our internal build and release tool, code-named Tonka. Tonka already checked-out clean code from the repository, labeled the build number in the repository and incremented the corresponding number in the build number config file, and built all targets in all configurations for all platforms. It then compiled the unit tests, and ran them either locally or dispatched to a remote machine, depending on the target platform. All problems were logged, posted to the intranet, and emailed to appropriate parties. The resulting binaries were then zipped up, labeled, and stored in a file server. Then Tonka took the installer program, built the installer apps, and made sure that they would run smoothly, with no errors, on a clean system with default settings. Once that was done, Tonka was supposed to build an ISO, store that onto the file server, burn it onto CD, reboot, verify the CD autoran the installer, and when all was well, open the CD drive so the operator would know that everything was done. Phew!
The problem was, as Fried diligently explained to me, that the reboot, verification, and subsequent ejection of the CD weren't quite working. He could either get the reboot and clean install from CD to work, or the CD to eject. But it didn't want to eject after a reboot. Thus the CD's all over the room.
Now, the deployment we were scrambling to be able to do did not need an install CD. And from the number of CD's on the floor, it was clear he had been attacking this problem for hours! If I were more hot-tempered, I might have broken his neck. While everyone else was working at a furious pace to finish up the required features and making sure all the platforms behaved as expected, Fried was working on the tool to build the install CD, which the customer did not need.
But in reality, I was impressed. Fried was exhibiting, in the words of Perl's inventor Larry Wall, the three great virtues of programming:
I was impressed because Fried knew that as we got closer to this and other ship dates, the number of required build cycles would grow. And the chances for each developer, immersed in the excitement of the fray, to make a stupid mistake building the product was high. Worse, as we got closer to the critical release moment, the cost in time and frustration of each mistake would become extreme.
Tonka already had a feature allowing developers to submit a job of their local code, which would get built and tested and wrapped up and smothered with gravy. But then the developer would have to deploy the results on the various OS's and platforms by hand -- a mistake prone chore. What Fried was working on would eliminate the possibility for making mistakes. And would make it much easier for the developers to be lazy. Fried was reducing the number of steps to test a deployment, and the time to get there.
There was another way Fried's laziness was exemplary. Fried wanted to make sure that all stupid, repetitive tasks were automated, so he wouldn't have to do the same stupid, repetitive tasks over and over again. He also wanted developers to know quickly and regularly if new code worked cleanly. But testing was another stupid, repetitive task. He preferred to let the computer do the work. Computers are great at doing stupid, repetitive tasks. In fact, I could have written this paragraph just by cutting and pasting the phrase "stupid, repetitive" several times and filling in surrounding words. Computers are great at that because they're consistent and don't get bored by stupid, repetitive tasks. Fried was being quintessentially lazy by offloading stupid, repetitive work to a computer.
Upon seeing the dozens of CDs on the floor, I sent Fried home. He was lazy and impatient, all right, but his hubris wouldn't let him leave till he solved this last problem. The next morning, Fried thanked me for telling him to quit. He had solved the problem with only three more CD's on the floor!