Don't blame the UI design for your bad code

A couple of days ago I was in a meeting where one of the subjects was

 Why does this swing code suck?"

The code we had was messy, had logic spread all over the place and was a nightmare to maintain.

The answer from one of the developers actually responsible for creating this crappy code was

 The UI design changed during the development of the UI

To me this is a really bad excuse.


One of the first things I learned about UI programming is to always create a good model. If you have a good model, implementing the actual UI part should be a piece of cake. In this piece of code the model sucked. The developer explained that this was caused by the ever changing UI design. Have you never heard about refactoring? One of the key stones of agile development is to always do refactoring. If your model no longer matches the UI, then refactor it! Don't blame the changing requirements or design for your crappy code.

Why I hate Maven

Yes, I admin that Maven has improved the development of Java programmers because the tons of dependencies each project brings.


So, why do I hate it so much? 


Thousands of network calls
One of the main reasons is because of the thousands of network calls to remote servers to

• check versions
• check md5
• download pom files
• download jar files

To keep the internal repositories up-to-date Maven has to check all the dependencies in the internal repository daily and each Maven user has to pay the latency cost of downloading a lot of files all the time. A workaround for this problem might be to install nexus or Jenkins on a server on the local network, but you still have the problem with latency on the internal network.

A workaround for me is to do 'mvn clean install' each morning, then go and fetch coffee...

Simple tasks is hard

Simple tasks as creating an executable jar or building a new version of an application should be a piece of cake, but it isn't. All this can be done by using a lot of plugins, but the major problem with these plugins is the lack of documentation. 

You are forced into creating a bunch of Maven modules

Separating your code into different modules is good programming practice, but I don't like separating it because the build tool requires it. Creating a simple Maven project often requires you to create 4 or 5 maven modules and that's just to much.

Repeatable builds

Do I really trust Maven to give me repeatable builds? No. I do not trust that downloading dependencies from the internet will give me the same versions of the file each time. A better solution would be to fetch all dependencies from a revision control system.

Don’t interrupt my colleague

You are in the office, deeply concentrated on solving a problem. Then someone approaches your desk and wants to ask you for a solution to a different problem. What do you do?

Do you give him the answer to his problem?

Do you tell him to come back later or send the question in an email?

This is a situation I guess most developers experience several times a day. Most developers are nice guys and gives a proper reply immediately, but is this really what we should do?

In my early years as an developer I always said “Yes, hang on and I’ll find a solution for you”, but lately I have changed my answer to “Send me a mail and I’ll give you some feedback later”.

The reason behind this is that I want to get rid of all the 100 context switches each day. When someone asks you a question, you have to start thinking about that problem instead of the problem you were working on. When the guy leaves you as a happy man 5 minutes later, you might think: what was I doing 5 minutes ago? It might then take 10 minutes before you are back on track and can are productive again.

If you instead tell him to send you a mail, you can finish off whatever you are working on and then later give him a proper reply. This will make you finish your task sooner, and an added bonus is that your reply might also be better.

Interrupt rules:

1. Only high pri crises should be answered immediately
2. Send questions on mail or IRC
3. Set off specific time of day to answer questions, for instance just after lunch and before you leave for the day.

Java generics, collections and reflection

Generics are a facility of generic programming that was added to Java in J2SE 5.0. It allows a method to operate on objects of various types while providing compile-time safety. A common use of this feature is when using a java.util.Collection that can hold objects of any type, to specify the specific type of object stored in it.

Generics is one of the new features in the Java language I really like. It makes working with collections easier and the compile-time checking reduces the risk of run time errors.

Lately I have been playing around with a legacy dependency injection system relying on reflection to inject properties into objects. This was when I discovered one of the drawbacks with generics: Reflection and generics are not the best match

This is for instance the code needed for retrieving the generic type of a method returning a generified java.util.Collection

Class<?> getGenericType(final Method pMethod) {
  Type[] genericTypes = pMethod.getGenericParameterTypes();
  if (genericTypes.length == 0) {
    throw new IllegalArgumentException("Method has no generic parameters");
  }
  Type genericType = genericTypes[0];
  Class<?> propertyType = Object.class;
  if (theType instanceof ParameterizedType) {
    ParameterizedType parameterizedType = (ParameterizedType)genericType;
    propertyType = (Class<?>) parameterizedType.getActualTypeArguments()[0];
  }
  return genericType;
}

As you can see it’s not the prettiest code in the world, but luckily it works.

The Programmers Bill of Rights

1. Every programmer shall have two monitors. With the crashing prices of LCDs and the ubiquity of dual-output video cards, you’d be crazy to limit your developers to a single screen. The productivity benefits of doubling your desktop are well documented by now. If you want to maximize developer productivity, make sure each developer has two monitors.
2. Every programmer shall have a fast PC. Developers are required to run a lot of software to get their jobs done: development environments, database engines, web servers, virtual machines, and so forth. Running all this software requires a fast PC with lots of memory. The faster a developer’s PC is, the faster they can cycle through debug and compile cycles. You’d be foolish to pay the extortionist prices for the extreme top of the current performance heap– but always make sure you’re buying near the top end. Outfit your developers with fast PCs that have lots of memory. Time spent staring at a progress bar is wasted time.
3. Every programmer shall have their choice of mouse and keyboard. They are the essential, workaday tools we use to practice our craft and should be treated as such.
4. Every programmer shall have a comfortable chair. Let’s face it. We make our livings largely by sitting on our butts for 8 hours a day. Why not spend that 8 hours in a comfortable, well-designed chair? Give developers chairs that make sitting for 8 hours not just tolerable, but enjoyable. Sure, you hire developers primarily for their giant brains, but don’t forget your developers’ other assets.
5. Every programmer shall have a fast internet connection. Good programmers never write what they can steal. And the internet is the best conduit for stolen material ever invented. I’m all for books, but it’s hard to imagine getting any work done without fast, responsive internet searches at my fingertips.
6. Every programmer shall have quiet working conditions. Programming requires focused mental concentration. Programmers cannot work effectively in an interrupt-driven environment. Make sure your working environment protects your programmers’ flow state, otherwise they’ll waste most of their time bouncing back and forth between distractions.

About me

This site is all about Java and the daily life of a Java programmer.

Who am I?

• A Java developer with 12 years of experience
• Started out as a novice programmer with the responsibility of creating a rich Java client using Java 1.3.
• As time goes by I have gradually converted into a hard code server side programmer and architect.
• Currently working as a senior server side developer and architect for a large software company.