On 15 February 2012 12:12, H. S. Teoh <[email protected]> wrote: > On Tue, Feb 14, 2012 at 11:47:52PM +0100, Timon Gehr wrote: >> [...] >> It does not hurt at all if your code base is more flexible than >> necessary. > [...] > > This needs to be taken in moderation, though. > > I've had to work with code that was unnecessarily flexible. (I.e., > over-engineered.) So flexible, in fact, that almost none of us knew how > to use it, and the code ended up deteriorating into a morass of hacks > attempting to bypass an overly-general framework that nobody understood. > > One particularly bad example was that part of the system had a whole > hierarchy of database-access classes, intended to replace having to > write SQL directly. The problem was that it was so poorly documented, > and so difficult to understand, not to mention requiring a instantiating > a whole bunch of objects just to do something as simple as "SELECT * > FROM some_table;", that eventually people just resorted to writing a > function for executing SQL directly, thus bypassing the entire > over-engineered mess. > > And that was only a small part of it. There were other beautifully > designed, fully OO, and fully generic classes, that accomplished > everything from the most trivial of tasks to the most advanced > high-level abstractions. Like the IPC mechanism, for which at one point > I had to write code to get through *six* layers of abstraction just to > call a single function. One layer of which involved fwrite(), fork(), > exec(), and fread(). Such was the result of the original code base being > much too flexible than it needed to be. > > > T > > -- > Why are you blatanly misspelling "blatant"? -- Branden Robinson
Basically, flexibility is good, but you have to make sure you are actually writing a program, not a platform or framework, or worse a COBOL. (COBOL being COmmon Business-Oriented Language, intended for "business people" to use, and let programmers get back to writing device drivers <.<)
