A friend of mine has been roped into doing some web-design for a project with some friends of his from school. It’s a relatively simple project, and they’re paying him decent money (not good, but decent). Over the last few weeks, though, he’s slowly started to realize just how big of a mess this project is. It seems to be some students that are doing most of the coding, and they’re doing it all in ASP and C-sharp, while they’re not particularly proficient with either. The fact that they held up development for 2 days while they tried to get Visual Studio to work should indicate the caliber of development we’re talking here.
Today he was telling me some of the horrors he’s seen in the code (I’m still trying to convince him to submit some to WorseThanFailure.com), and it started to dawn on me what’s really going on here. It’s a classic problem that pretty much every programmer falls into in his first big project: Overmodularization leading to "Black-Box" designs.
Let me explain. All through school & training, we’re continuously told that "Design for Code-Reuse" and "Module design is good", and they’re right. A piece of code that you’re going to use over and over again needs to go in a function, rather than suffer the ravages of cut-n-paste. But, it does have a limit. Nobody tells you that part. I’ve fallen into this trap myself, everyone has at least once. Here’s an example (from my friend’s project): I’m going to use a table-less design, all divs, in this webpage. So rather than scattering the div tags all through the code, I’ll write a "writeDiv" function that accepts a string and automatically puts the div tags around it. Sounds good right?
It’s a trivial example, but it’s a classic starting point for the type of failure we’re talking about. You start with a basic "writeDiv", and scatter it all through your code. Then you realize that not all Div’s are the same, some need CSS class specifiers. What should happen is that you would modify the original writeDiv to accept a class argument, but we think it’ll be more efficient if we have a "writeTitleBarDiv" and "writeBorderedBoxDiv" functions instead. Afterall, we’re just gonna be passing the same argument to all those anyway, right? This goes on and on until you’ve achieved maximum modularity, but absolute zero code reuse. The entire application is encapsulated in functions that are each called a single time because they’re too specialized to be used more than once.
That alone is bad enough, and a perfect example of Over-modularization. But, for alot of new programmers it doesn’t stop there. (I’ve done this myself, I’m ashamed). Since the resulting system that you’ve designed is so incredibly "modular", it’s a bit difficult to work with. So, we’ll just encapsulate it as an engine that you can feel a short input to and get your desired output. This is exceptionally prevalent in web-page systems. Rather than writing HTML, you write some small script that somehow describes the page, and then the parser engine takes over and generates the actual page. This could be a text file full of strange Wiki-like symbols, or it could be an ASP & C# script that uses no C# functions, just calls hundreds of methods of the "ParserEngine" object. However, because of how the system is designed, writing this weird input language is easily several orders of magnitude more complicated than writing the raw HTML would be. Not to mention, when the existing "Engine" fails in some way, good luck trying to debug it.
Such systems are typical of new "rookie" programmers, and there’s no telling how many of these poorly designed systems wind up becoming production tools. Experienced programmers can see these things coming and make changes to avoid them. It takes experience to know when to modularize and when to just write it there. Be it in DSP microcode or web-page design, it takes experience. Modular design is good from a code-reuse and maintainability perspective, but it does bring overhead in increased function calls and push’ing/pop’ing stack arguments. Where to put the line is something that only comes with experience.
So, how many of these "Black-Boxes" have you built in your day? How many programmers did it take to "fix" it?
[tag:badcode][tag:programming][tag:modular]