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.

Using getters in equals() method

I have an uncontrollable urge to refactor. To a fault. Most everything. If I was cleaning a campsite, I would be putting in indoor plumbing. So, when I opened an old class I changed the old hashcode and equals methods with our team’s standard use of HashBuilder and EqualsBuilder. (The reason for opening the class was to add a toString method.)

@Override
public boolean equals(Object obj) {
    if (this == obj) {
        return true;
    }
    if (obj == null) {
        return false;
    }
    if (!(obj instanceof ${enclosing_type})) {
        return false;
    }
    ${enclosing_type} other = (${enclosing_type}) obj;
    ${builderType:newType(org.apache.commons.lang3.builder.EqualsBuilder)} ${builder:newName(builderType)} = new ${builderType}();
    ${builder}.append(this.${field}, other.${field}());${cursor}

    return ${builder}.isEquals();
}

When I ran the application again (I was trying to find a bug) I wasn’t getting to the same place in the code as before. Stepping through with the debugger I noticed that I was no longer returning “true” during a comparison of the object I had just changed. So I went back to the old version of the equals method. I could not visually see a difference. So I wrote a JUnit test case to test the equals method, specifically for symmetry. That didn’t get me very far; everything passed as expected.

So I ran the program through the debugger stopping in the equals method for comparison. It looked like the passed in object had nulls for everything. I changed my JUnit tests to test for the same setup, but it worked as expected.

So I went back and created 2 equals methods. Then I had each run and if there was a difference between the old equals method and the new equals method, I would just exit the program:

@Override
public boolean equals(final Object obj) {
    // TEMPORARY!!! 
    final boolean newEquals = newEquals(obj);
    final boolean oldEquals = oldEquals(obj);
    if (newEquals != oldEquals) {
        newEquals(obj); // for debugging, I can step through the method again 
        oldEquals(obj); // for debugging, I can step through the method again
        LOGGER.error("newEquals (" + newEquals + ") doesn't equal oldEquals (" + oldEquals + ")!!!");
        LOGGER.error("this = " + this);
        LOGGER.error("obj = " + obj);
        System.exit(1); // TEMPORARY!!!
    } 
    return oldEquals;
}

I re-ran the JUnit test, but still no luck.

I re-ran the application and viola the equals methods were different and the app exited. But what was going on?

I added a breakpoint in the equals method and looked at the state of the variables again. That’s when I noticed the my object being passed in wasn’t what I expected, but some kind of proxy object. I expanded the object and found a target variable. I expanded that and saw the values matched the “this” object!

Equals Comparison Screenshot

I looked back at the equals methods. The original equals method has get() and mine had just the direct access to the member variable. I step throw the call to the get method and found the proxy will load the member variables to their real values.

So, the lesson I learned was that I need to be calling the get methods in my equals method for the object being passed in. I changed my equals template to add a long-winded explanation for the change. Here’s my Eclipse template:

@Override
public boolean equals(Object obj) {
    if (this == obj) {
        return true;
    }
    if (obj == null) {
        return false;
    }
    if (!(obj instanceof ${enclosing_type})) {
        return false;
    }
    ${enclosing_type} other = (${enclosing_type}) obj;
    ${builderType:newType(org.apache.commons.lang3.builder.EqualsBuilder)} ${builder:newName(builderType)} = new ${builderType}();
    // You want to use get() methods because ${enclosing_type} might by a "proxy" that libraries (such as Hibernate with CGLIB) will create. (Hibernate uses proxies for lazy loading.) And if the object is not loaded, then access to the fields directly will yield nulls. But calls to the get() methods are intercepted and the proxy returns the correct value. See https://forum.hibernate.org/viewtopic.php?t=946468
    ${builder}.append(this.${name}, other.get${name}());${cursor}

    return ${builder}.isEquals();
}

Thanks go to this post for helping me understand the issue.

Sublist not Serializable

I guess this was already known by some, but I didn’t know that if you sublist a List that was Serializable, you will get back a list that is not.


import java.io.Serializable;
import java.util.ArrayList;
import java.util.List;

public class SerializableSubListTest {
   public static void main(String[] args) {
     List list = new ArrayList();
     list.add(new Serializable(){private static final long serialVersionUID = 1L;});

     System.out.println("list instanceof Serializable = " + (list instanceof Serializable));

     List subList = list.subList(0, 1);

System.out.println("subList instanceof Serializable = " + (subList instanceof Serializable));
   }
}

list instanceof Serializable = true
subList instanceof Serializable = false

What I Learned At Barcamp

Slash
Biltboard.com will be launching a new app to capture your work in progress process.

Momomaha.com
You have to develop a thick skin to blog about your personal life. And not everyone will like you — accept it.

5 things you can do to motivate your team:

  1. Stand up
  2. Hurry up
  3. Shut up
  4. Pair up – not just programming
  5. Think up – think positively

How To Work with Your Spouse
Communicate! But don’t talk about work at home or home at work.
Having a 3rd person to settle debates is good.

Manage Users like a Roman Centenarian
Accept what is not in your control. Prepare for the worst.

They could charge double the price and it would still be a great deal!

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

List App

I have an idea for an online list making app. The list can be sorted on any number of attributes (or “sorts”). Attributes can be added at any time and once “activated” you can drag and drop your list to the order you want for that attribute. Then, if you go to another attribute, it again can be drag and dropped into order, but the order is remembered. So if you go back to the first attribute, the items are resorted based on that attribute.

Continue reading

Tech Lead Checklist

I recently read the article Tech Lead Checklist to Kick your Team into Gear, recommended by my tech lead. Here are some things our team does and does not do.

Daily

Require written standup reports each day Nope. We don’t do this. Once every other week I might write something up but it contains more than what I did that day. And other times when someone (one person in particular) can’t attend our scrum they will send an email.
Attend a daily chat Yup. That’s our daily scrum.
Resolve roadblocks Yes, I do this.
Look at individual detailed activity Really? I peruse Fisheye occasionally, but I don’t think I do any “detailed” investigation.
Move requests to ticket system Yea, I usually put in “issues” which can be turned into backlogs during sprint planning.
Let team members select their own tasks. We try to let our developers do that. But some ask what they should work on and I do assign tasks.
Watch for lack of commits and ask developers to break into smaller tasks I believe in atomic check ins. However, without a “quiet period” the continuous server will keep rebuilding. Plus it makes it harder to say “this commit was for feature X” when really there were 10 such commits. I’ve often wondered about using Git locally to make these atomic commits and then checking them to SVN.

Weekly

Review tickets I usually review ones that are specific to the project I’m most working on more frequently than weekly.
Ask specific developers to plan large tasks Done by me.
Post team tasks completed and what is planned for the next week I can’t say we do this.

Bi-Weekly

Find developers interested in new projects We often are asked what sounds interesting to us and we try to pass that on when talking about features of a project.
Do “onboarding” Our tech lead did a great job with this a year ago when I joined his team. I’ve tried to create Eclipse templates that others can use. We would need to work on this more if we were expecting any developer to join the team.
Evaluate trial developers We don’t have any trial developers but we look at our current developers and assess them. If we don’t think they are working out, we are willing to try other developers.

So what does this mean? It means I’m already doing a lot that a tech lead should be doing, so I’d be totally comfortable taking that position. (Hint, hint, wink, wink, nudge, nudge.)

First Scala

I was hoping for

def sayHello(name) {
  println("Hello, " + name)
}

("world", "Adam").foreach(sayHello)

but will have to settle for

def sayHello(name: String) {
  println("Hello, " + name)
}

List("world", "Adam").foreach(sayHello _)