Why new developers should work on legacy applications and seasoned developers on new projects

or

Why my job sucks

My job sucks.

I’ve been moved to a different team again.

Evidently, I’m the shit-polishing guy.

Yes, the guy who loves taking large piles of crap and maintaining them.

Well, the co-workers, pay, benefits, etc., those are all fine. But it’s the work. It hasn’t always been that way, but lately I’ve been busy doing “technical evolution” (my boss’s words, not mine). What does this entail you ask? This is the work necessary to move very old applications off of unsupported hardware onto the currently supported and approved frameworks — read: not the latest and greatest; the stuff that has been approved for 5 years or so. And let me tell you, it isn’t fun. The technology is old. So old that I have to re-learn the stuff. (Throwback every-day-of-the-week anybody?) But that’s not the worst part. It’s the crappy code: poorly written monstrosities that I have to read.

I don’t think clean code was a thing back then.

What I see, and hopefully it is only at my job, let there be a god, is new programmers writing all of the code! New development must be the only way to lure new programmers. (I can’t think of any other reason at the moment.)

I see two reasons poor code is produced by inexperienced programmers.  The first is they don’t realize the importance of maintainable code, or, the second reason, they think they are writing maintainable code.

Let’s discuss the second reason first.

New developers write code that is easy to understand for them. They are under the misconception that the code they are writing is very easy to understand. This is usually because they are the only one looking at their code and it was very recently written. They don’t have the experience of what to do and not do. They don’t know what it means to develop code for maintainability.

Seasoned developers have seen many different projects and learned what works and what doesn’t work. They are more realistic about designing a system. They have witnessed the pitfalls and are less likely to make them.

To address the importance of maintaining code, I suggest “allowing” new developers to support legacy apps. They gain the experience and appreciation of what “bad” (and good!) code can look like and not make the same mistakes. (And at the same time they might gain some business knowledge!)

The other reason I contest my job sucks is because all the new developers get to write code using cutting edge technologies and frameworks and tools. I, on the other hand, don’t get the opportunity to work with this stuff except at home. (Whereas a new developer might not have the same time commitments outside of work and have the time to learn new stuff.) What’s this mean? I am falling behind the times and becoming less relevant.

In conclusion, let the new developers gain the appreciation for and the knowledge how to create maintainable code by maintaining apps and let the experienced developers write new code that the noobies won’t mind maintaining.

Serialization, Beans and PMD

There is a PMD rule that checks for mutators (getters and setters) on Java Beans: BeanMembersShouldSerialize. I have a lot of these violations in my code. I’d rather understand the issue than just turn it off, but I’m struggling with what it means.

What I learned is: being Serializable does not make a class a Java Bean. And, to be Serializeable, you don’t need mutators.

But PMD thinks my object is a bean. Why? Continue reading

Performance = Optimization?

From http://www.javacodegeeks.com/2011/07/top-97-things-every-programmer-or.html:
It’s never too early to think about performance – Rebecca Parsons

From Effective Java:
More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason—including blind stupidity.

—William A. Wulf [Wulf72]

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.

—Donald E. Knuth [Knuth74]

We follow two rules in the matter of optimization:

Rule 1. Don’t do it.

Rule 2 (for experts only). Don’t do it yet—that is, not until you have a perfectly clear and unoptimized solution.

—M. A. Jackson [Jackson75]

When I started programming I thought the goal was to produce code that was fast. So I wrote concise code without regard for readability. Now, I lean toward readability. I guess I’m just trying to differentiate performance and optimization. Performance is good. (Premature) optimization is bad. I struggle with this because I find it easier and more enjoyable working with the details and not at a system level.