0

I'm working for a company writing ERP applications. My problem is that I have to write tons of boilerplate code. I came up with ideas to automatize/prevent the drudgery but only some of them were accepted. I have been told by the lead developer that my ideas tend to be go far afield and I should write code everyone can understand.

I had a discussion about this lately and it seems to me that this kind of code ramp is within java's philosophy. I have to write lots of code to achiveve simple things not because it is necessary but because this is the way most of the people at the company think.

Is this universally applicable to most of the companies out there using java or this is just my company's view? Do I have to get used to the drudgery if I keep working for java-based firms?

Improve this question
15
  • 2
    "code everyone can understand" - you still havent't tried having to maintain something you cannot understand yet?
    – user1249
    Commented Mar 23, 2012 at 10:31
  • 7
    and here I thought it is already the Java language itself which forces you to write all that boilerplate code...
    – Frank
    Commented Mar 23, 2012 at 10:39
  • 2
    @edem Reflection has a very serious disadvantage, namely that the compiler cannot detect when you do something wrong. Apparently your lead developer has been bitten by this.
    – user1249
    Commented Mar 23, 2012 at 10:57
  • 2
    @SK So if I wish to maximize the creative work and kill the drudgery then companies using only java may not be the right choice for me?
    – Adam Arold
    Commented Mar 23, 2012 at 11:49
  • 3
    "I'm working for a company writing ERP applications". A lot of enterprise stuff is pretty basic programming. You may have to have a good look round for interesting/creative work, whatever language you use.
    – Jaydee
    Commented Mar 23, 2012 at 12:12

5 Answers 5

Reset to default
8

We are talking about quite different things here. Replacing boilerplate code with a completely different way of doing things, such as reflection, can be hairy. There can indeed be very good reasons against doing this even if it simplifies programming for you, such as loss of type safety and security, runtime cost, increased understanding and maintenance cost for others, etc. No idea whether or not that is the case in your situation, but it might well be.

However, simplifying the generation of boilerplate code is quite another thing. If it's repetitive enough that it can be completely automated, then I'd say yes, it absolutely should be automated. There's just too much that can go wrong maintaining such codebases by hand, and just too much effort saved not to do it. And if co-workers can't even understand how a code generator works, then, well, they shouldn't be co-workers in my book.

Improve this answer
17
  • 1
    Source code generators have the very serious disadvantage that you cannot make compiled code point back to the original but only the generated source. This makes it harder to work with.
    – user1249
    Commented Mar 23, 2012 at 10:59
  • 1
    @SK-logic you are aware this is Java, right? If you generate source you cannot keep the metadata.
    – user1249
    Commented Mar 23, 2012 at 11:14
  • 3
    So you have essentially introduced a new homegrown language in your build environment to avoid some boiler plating. This is most likely what the OP's lead developer mean with "my ideas tend to be go far afield and I should write code everyone can understand."
    – user1249
    Commented Mar 23, 2012 at 11:27
  • 1
    @ThorbjørnRavnAndersen, what's wrong with the "homegrown" languages? I believe that everyone should use DSLs. There is no single domain which would not benefit from this approach.
    – SK-logic
    Commented Mar 23, 2012 at 11:33
  • 1
    I've been working with clojure for a few months now (on my own) and it looks really nice.
    – Adam Arold
    Commented Mar 23, 2012 at 11:41
5

This question brings this old quote to mind:

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. [Brian W. Kernighan]"

In a team environment this would need to be expanded so that if the smartest person on the team writes the cleverest code they can, then the dumbest person onthe team doesn't have any hope of debugging it.

Also just noticed this quote:

Simplicity is prerequisite for reliability. [Dijkstra]

Improve this answer
11
  • 1
    What's a point of keeping that dumb person in a team? It's counterproductive.
    – SK-logic
    Commented Mar 23, 2012 at 11:15
  • 6
    In any team, there will be a spread of ability. Just because they are the dumbest person "on the team" doesn't mean they are useless.
    – Jaydee
    Commented Mar 23, 2012 at 11:22
  • if, because of this dumb person, team decided to stop using practices which otherwise could have improved their performance 10x, then getting rid of that person makes a lot of sense.
    – SK-logic
    Commented Mar 23, 2012 at 11:32
  • 3
    "For every complex problem there is an answer that is clear, simple, and wrong." -- H.L. Mencken
    – Blrfl
    Commented Mar 23, 2012 at 11:36
  • 1
    Something about removing the dumbest member of the team seems illogical: function removeDumbest(team){ var dIndex = 0; var dIQ; for(var i=0; i < team.length; i++){ if(dIQ == null || dIQ < team[i].iq){ dIQ = team[i].iq; dIndex = i; } } team.splice(dIndex, 1); removeDumbest(team); }
    – threed
    Commented Apr 29, 2014 at 19:56
1

I dont believe that the use of 'boiler plate' code is related to a particular language, but rather that it is a design decision. For whatever reasons, the company you are currently working for has made that choice, possibly in relation to ease of maintenance or facilitating the operational support of the applications. 'Reflection is evil' is just a reflection on those reasons, an easy mantra to remember and put in practice.

Improve this answer
1
  • 3
    No, it is language-related. Boilerplate code is unavoidable with any language that does not support proper metaprogramming. Even languages like Haskell would suffer.
    – SK-logic
    Commented Mar 23, 2012 at 10:59
1

First off, you can have boilerplate code in software written in any language. It's not java specific. I've written and worked with big java applications which had almost zero boilerplate code.

Like in every other software, there may be some simple boilerplate code here and there. But usually, it's small and it's not really a problem to type the couple of extra lines, nor does it harm readability. On the other hand, it may help debugging, maintenance, etc...

That being said, the aim of all source code should be to strive for simplicity and ease of understanding. If the boilerplate is excessive and you have a much simpler solution, leading to more readable, maintainable, understandable code, then, by all means, do it. Show it to your superior, that it's simpler, safer, less code, etc. and if it's indeed that obvious, his decision should be obvious as well.

Now, on the other hand, if you want to make an super complicated inflexible unsafe construct just to save a couple of boilerplate lines, then, I agree with your boss. It may be a source of more complexity then it tries to solve. Remember that you don't code for yourself, you code for others.

Improve this answer
0

It's one thing to invent a new language that gets translated into the target language (think coffeescript->javascript) and a completely different thing to have a generator that only creates the first version of a source file.

The former is expensive and difficult to make, and should be left to people who know how to design and implement languages.

The later is helpful in environments where lots of redundant boilerplate code is required, and usually it's not very difficult to design and make. Using such a tool generates boilerplate code that looks like it was written by hand, just a bit more consistent and typo-free. Once generated, the source file is further worked on, edited, adapted, extended etc. The input-file for the generator is one-off; no attempt is made to allow round-trips etc.

To answer your question: Go for the second option, don't bother trying the first.

Improve this answer
5
  • Generating source code and then editing it may be necessary sometimes, but it can lead to a maintenance nightmare with lots of repetitive code. I think it's better to use generated code and handwritten code together, but in different files, without ever touching the generated code by hand. This way you can always re-generate it when it needs to grow.
    – Philip
    Commented Mar 23, 2012 at 12:16
  • Philip: If that is possible, sure, keep the generated code untouched. Anyway, if the only choice is between "generate" and "write by hand", I'd choose "generate" all the time.
    – user281377
    Commented Mar 23, 2012 at 13:39
  • Everyone have to learn how do design and implement languages. Because it is extremely easy, and it's the biggest single possible productivity boost for any possible programming domain.
    – SK-logic
    Commented Mar 23, 2012 at 14:40
  • SK-logic: You are assuming competent programmers. Go read Codinghorror.com. ;-)
    – user281377
    Commented Mar 23, 2012 at 15:03
  • @ammoQ, it is at least much easier than OOP and than coding in the "general purpose" imperative languages. And since these things are pervasively mainstream, everyone from that mainstream background should be more than capable of implementing and designing DSLs.
    – SK-logic
    Commented Mar 24, 2012 at 16:39

Not the answer you're looking for? Browse other questions tagged or ask your own question.