Difference: ProgrammingNotes (13 vs. 14)

Revision 1403 Nov 2003 - TobyCabot

Line: 1 to 1
 
META TOPICPARENT name="TechTips"
(back to TechTips)
Line: 60 to 60
 A guy that I once worked with wrote a research paper that went into extreme detail about the differences between different types of uncertainty in software development, i.e. the difference between "I don't know" and "I know that there's no answer". Actually, I didn't understand much beyond the abstract but my co-worker spent some time explaining it to me.

A related topic is the difference in relational dbms terms between null and 0, but that's a different discussion.

Added:
>
>

Other People are Smart, too

I've noticed the same antipattern on several projects that I've worked on. It manifests itself in code that's intended to simplify standard mechanisms, usually by wrapping the standard mechanism (e.g. HTML, JDBC, JMS) in something that's "easier to use". These wrappers are built with good intentions, but they're based on a fallacy that's very similar to the "noblesse oblige" from the previous centuries. In those times, people of a higher station were required by nobless oblige to care for those who they believed were inferior to them. Now, people who write these libraries try to care for others who they believe aren't as smart as they are. In most cases they're doing themselves a disservice by hiding the mechanism from other users. A better alternative is to write code that simplifies the use of the mechanism while exposing its operation. This allows everyone to learn how it works.

The benefits of this approach are many, but the primary benefit is simplicity. The wrapper code, like all code, will have bugs, and even after they've been found and fixed, it's another layer of code that needs to be learned and executed, and these wrappers can be grossly inefficient at run-time especially if they use mechanisms like reflection to do their work.

Another benefit is that when you're hiring people, you can interview them to find out if they understand the standard mechanism, and if they do they can jump in and write code with very little learning. It's pointless to interview them to see if they know your proprietary wrapper, because of course they don't. They'll have to spend time learning how it works, even if they already know how the standard mechanism works.

So next time you're about to write some code that "simplifies" a standard technology, ask yourself if maybe your time wouldn't be better spent writing some documentation that will help people learn how the technology works. Sure, it's more satisfying to think that you're smarter than other people, but in the long run it's better to swallow your pride.

View topic | History: r25 < r24 < r23 < r22 | More topic actions...
Copyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding The Caboteria? Send feedback