Registered: Sep, 2003
Posted: Sep 4, 2011 6:25 PM
> I feel like I've been all over the place, so I want to
> boil down my arguments:
> Axiom 1
> The biggest source of trouble in software is code that
> programmers don't understand.
> There are several places to get such code, and it's useful
> to identify those sources and root them out as much as
I disagree. I think the the biggest trouble in software is domain knowledge or requirements. I thought that was a pretty much a given. With a debugger it's not hard to figure out code...or even printfs if need be.
> Axiom 2
> Any code in your project is your responsibility,
> regardless of where you got it.
I'll agree there. Ownership of code and bitterness when constructive code review happens does nobody no good.
> Axiom 3
> Anything that convinces programmers that they understand
> code when, in fact, they do not, is a one-way ticket to
> the inner circle of Hell.
I'm sure I'm misunderstanding you, but in general we never understand any significant piece of code. We just don't. There's too many permutations of any significant piece of code to do that.
> My complaint about auto-generated code comes from applying
> these principles. The fact that you know which version of
> a tool and which settings you used in generating code does
> not, in fact, mean that you understand the code in
> question. And, odds are, you will one day need to.
Do you have a problem with ORMs then? Typically they autogenerate code.
> As an example; some projects I work on use Protocol
> Buffers. Protocol Buffers generates pretty solid code and
> has great documentation. Until you want to do something
> not mentioned in the documentation -- say serialize
> various NaN values or denormalized floats in one language
> and deserialize them in another. If you try to see if
> this will work by stepping through the auto-generated
> code, you can kiss your sanity goodbye.
> I have to assume that the hairball of code that Protocol
> Buffers spits out is a hairball because it's easy to
> generate; but I can't call it anything other than a
> massive hairball (please note that the API that the
> generated code exposes in not a hairball; I'm referring to
> the internals of the generated code). The structure of
> code is far from obvious, there is no way to determine
> invariants, and the only comments in the files are -- not
> surprisingly -- statements that you should not edit the
> files if you ever plan on rerunning the Protocol Buffer
> Alternatively, I know that I'm not the only programmer
> who's ever had auto-generated code throw a null pointer
> exception. And the only way to determine whether there is
> an error in the generated code or in my code calling it is
> to find out what details are being swept under the rug by
> the generated code (i.e., to understand the generated
> code). And, again, generated code is easy to generate,
> not necessarily easy to read.
We fought over whether to use the Entity Framework. We actually do Java and .NET development. The argument against the Entity Framework was that there was too much magic underneath. That's understandable. But now that EF 4.1 has come out we can trust the code generation. In java world, I'm assuming the same is the same in NHibernate world.
> On a different note, I'm fascinated by several tools that
> don't generate code; static analysis and modeling tools
> are prime examples. But most modeling tools seem to think
> of the problem at a level that's not useful for
> implementing a solution. They give people unwarranted
> optimism, and when things fall apart you have nothing to
> guide you out of the swamp you've been dumped in.
I'm a big, big, proponent of tool thats help BAs and developers narrow the conceptual and implementation gap, but I hear your point. EA sucks.