Joel Spolsky criticized the senior engineers who architect projects or platforms from a very generalized, abstracted, high-level viewpoint. But doesn’t this abstracted viewpoint lead to modular, scalable, maintainable code? Isn’t that what we are taught are all good aspects of programming? Was Joel wrong? No, no he wasn’t. In fact, this is one of Joel’s best points in his blog. Beware the architecture astronaut’s project!
The issue fundamentally boils down to whether the project is worth it. First, is the problem actually *useful* to solve. Second, is the ROI worth it? If the end result is an improvement but it results in a garbled, over-engineered, overly complicated product or platform, then no, it’s not worth it. Also, if it took 18 months to design this “beautiful”, abstract framework that could have been done by a python script in less than a day, then no, it’s not worth it. Is it borderline genius? Perhaps. But if it doesn’t solve real problems simply, then I’m not impressed. Be careful as architecture astronauts are generally incredibly smart engineers, with strong opinions who are often very persuasive, and, unfortunately, they are also often quite arrogant. Their projects are easy to identify as these projects are often hailed as revolutionary, breakthrough, and game-changing. Meet the engineer who claims the Linux interface is poorly designed and has too many gotchas. He then seeks to design a framework to improve all of Linux by himself … because Linux, through all its history and amazing engineers is substandard. That’s arrogance. Good, pragmatic programmers are humble enough not to claim such things and definitely do not force their white whale projects onto others. Good engineers often know that the better solution is incremental change. Boring, simple, incremental improvements.
Joel extols pragmatism well when he summarized architecture astronauts, “Tell me something new that I can do that I couldn’t do before or stay up there in space and don’t waste any more of my time.”