Ask Slashdot: What Are Some Bad Programming Ideas That Work? (infoworld.com)

snydeq writes: Cheaper, faster, better side effects -- sometimes a bad idea in programming is better than just good enough, writes InfoWorld's Peter Wayner: "Some ideas, schemes, or architectures may truly stink, but they may also be the best choice for your project. They may be cheaper or faster, or maybe it's too hard to do things the right way. In other words, sometimes bad is simply good enough. There are also occasions when a bad idea comes with a silver lining. It may not be the best approach, but it has such good side-effects that it's the way to go. If we're stuck going down a suboptimal path to programming hell, we might as well make the most of whatever gems may be buried there." What bad programming ideas have you found useful enough to make work in your projects? Don't be shy or ashamed, we all want to hear your responses!

Comments

Bad Idea #1

[Lodragandraoidh]

Allowing (or forcing) application programmers to do system programming. If your language forces the programmer to reinvent the wheel - he will invariably do it badly. The corollary to this: poor libraries/frameworks/abstractions built by aforementioned programmers then let bad programmers spread even more bad code.

This, by the way, is the source of all zero days.

If you have to do system programming - make sure you have a bona fide systems programmer - preferably who has a thorough understanding of secure programming - on the team; either as a reviewer, or designer.

Given that there aren't that many real system programmers out there - those that are should focus on building tools that keep application developers from shooting themselves in the foot (so they don't have to be there to keep the carnage from happening). In this instance, I am all for gun control. You don't give a child a loaded gun, and you shouldn't give an application programmer one either.