Your Coding Philosophies are Irrelevant

I’ll assume you’ve got a set of strongly-held beliefs about software development. This is a safe bet; anyone who writes code has some personal mantras and peeves.




Maybe you think that PHP is a broken mess or that Perl is unmaintainable? Maybe you’re quick to respond in forums with essays about the pointlessness of the singleton pattern? You should always check the result code after calling malloc. Or wait, no, result codes are evil and exceptions are The Way. Always write the test cases before any code. Static typing is…well, I could keep going and hit dozens of other classic points of contention and link to arguments for each side.




Now imagine there are two finished apps that solve roughly identical problems. One is enjoyable to use and popular and making a lot of money. The other just doesn’t feel right in a difficult to define way. One of these apps follows all of your development ideals, but which app is it? What if the successful product is riddled with singletons, doesn’t check result codes after allocating memory (but the sizes of these allocations are such that failures only occur in pathological cases), and the authors don’t know about test-driven development? Oh, and the website of the popular app makes extensive use of PHP.




Or even simpler: pick a single tool or game or application you admire, one you don’t have any inside information about. Now just by staring hard at the screen, determine if the author favored composition over inheritance or if he’s making rampant use of global variables. Maybe there are are five-hundred line functions and gotos all over the place, but you can’t tell. Even if you pick a program that constantly crashes, how do you know the author doesn’t have exactly the same opinions about development as you?




It’s not the behind-the-scenes, pseudo-engineering theories that matter. An app needs to work and be relatively stable and bug free, but there are many ways to reach that point. There isn’t a direct connection between some techie feel-good rule and success. For most arbitrary rules espoused in forums and blogs, you’ll find other people vehemently arguing the opposite opinion. And it might just be that too much of this kind of thinking is turning you into an obsessive architect of abstract code, not the builder of things people want.




(If you liked this, you might enjoy Don’t Fall in Love with Your Technology.)