Coding Standards – Quality From The Ground Up

Posted in: Software Development Best Practices

Coding styles are THE religious debate of the Software Engineering industry. Everyone has an opinion, but no one has an iron clad argument as to why their ideas are better than someone else’s.

It doesn’t matter what language you write your code in or what company your work for or even what open source project you contribute too, the topic of coding styles will sooner or later raise its head. The debate can range from the banal, like which line the curly brace goes on, to the overly subjective, like how to name variables.

In the end most of the decision points are pretty subjective and it is somewhat irrelevant what you choose, as long as everyone agrees and you are consistent. But don’t be mistaken, a consistent coding style is an important consideration on any project, from the solo developer to the multi-national team.
Continue reading »

SoCal Code Camp Los Angeles II

Posted in: Software Development Best Practices

SoCal Code Camp is back, November 21st & 22nd

Code Camp is a place for developers to come and learn from their peers. This community driven event has become an international trend where peer groups of all platforms, programming languages and disciplines band together to bring content to the community.

Who is speaking at Code Camp? YOU are, YOUR PEERS are, and YOUR LOCAL EXPERTS are…all are welcome! This is a community event and one of the main purposes of the event is to have local community members step up and offer some cool presentations!

Upgrades, upgrades, upgrades everywhere

Posted in: Enterprise Java

We are bombarded with hype about new versions of tools (like IDEs), or new libraries (like a new JDK), or a new software package (like a new object-relational mapper) all day long. But do we even need them? Can’t we basically create what we need to complete these mundane everyday tasks with the tools we already have? Aren’t most of these new releases just a way to sell new software licenses? Even when it comes to opensource software, upgrading to a new release has an inherent cost that needs to be weighed.

Here is a real world example. I am currently invovled in a project that involves upgrading the code base from JDK 1.4 to JDK 5 as part of the scope. My Engineer brain says that this upgrade is not only necessary, but just a plain good idea. There are some new language features in JDK 5 that we can take advantage of, so there is a benefit. But what are the costs? There is definitely a cost involved in doing an audit of the existing code and seeing if there is any code that is incompatible with the new JDK and putting together a plan and effort estimate to address those issues. There is also a optional cost of retrofitting the existing code to take advantage of the new language features (like enums for example). There is a learning curve cost. Perhaps there is a confusion cost for some junior engineers (I am thinking of the autoboxing feature). There is a cascading cost that we now also have to consider upgrading our application server environment to support the JDK 5 code.

So is all of this cost worth it? Will the benefits outweigh the risk and give the company some kind of ROI? I think in most cases, the answer is actually a defiinite yes.

Take the Java 5 upgrade example. Apart from the obvious technical benefits, there are a whole host of trickle down posiitve benefits. For starters, I think many companies underestimate the importance of keeping the geeks happy. Engineers like to use new tools and stay on the cutting edge. They like to be able to read articles in the latest journals and be able to apply the lessons learned straight away. Happy Engineers are good employees. They are more productive. They are more collaborative. They tend to not be looking quite so hard for that next dream job. They tend to be more forgiving of working conditions that might not be ideal. Engineers are creatures who like to learn and keep learning. Working on the same code and project and tools for year after year will be the death of an Engineer and you will end up with just mediocre Coders left on your team as the Engineers will be long gone.

So before you decide on your next upgrade, think about all of the costs involved, there are many hidden ones you may overlook at first glance. But then make sure you also think about all of the benefits (both short and long term). Not every upgrade will make sense, but I bet that a majority of them will.

Are our tools built for problems most people don’t need to solve?

Posted in: Enterprise Java

Not everyone is working on projects for the Defense Department where milliseconds could mean the loss of thousands of lives.

And not everyone is working on the backend for the stock exchange.

And most people are not writing their own application servers from scratch.

What are most people working on? Well that is a little hard to quantify, but it is a pretty safe bet that it is not a sexy application that they are bragging to their friends about. If you believe the 80/20 rule (and I do), most people are actually working on maintenance activities more than inventing something new from the ground up. Those who are inventing things from the ground up are more likely to be building a .com site for their company to show off their wares – it might even have an element of ecommerce to it, but then again, probably not.

So we are bombarded with hype about new versions of tools (like IDEs), or new libraries (like a new JDK), or a new software package (like a new object-relational mapper). But do we even need them? Can’t we basically create what we need to complete these mundane everyday tasks with the tools we already have? Aren’t most of these new releases just a way to sell new software licenses? Even when it comes to open-source software, upgrading to a new release has an inherent cost that needs to be weighed.

Here is a real world example. I am currently invovled in a project that involves upgrading the code base from JDK 1.4 to JDK 5 as part of the scope. My engineer brain says that this upgrade is not only necessary, but just a plain good idea. There are some new language features in JDK 5 that we can take advantage of, so there is a benefit. But what are the costs? There is definitely a cost involved in doing an audit of the existing code and seeing if there is any code that is incompatible for the new JDK and putting together a plan and effort estimate to address those issues. There is also a optional cost of retrofitting the existing code to take advantage of the new language features (like enums for example). There is a learning curve cost. Perhaps there is a confusion cost for some junior engineers (I am thinking of the autoboxing feature). There is a cascading cost that we now also have to consider upgrading our application server environment to support the JDK 5 code.

So is all of this cost worth it? Will the benefits outweigh the risk and give the company some kind of ROI? I think in most cases, the answer is actually a defiinite yes.

Take the Java 5 upgrade example. Apart from the obvious technical benefits, there are a whole host of trickle down positive benefits. For starters, I think many companies underestimate the importance of keeping the geeks happy. Engineers like to use new tools and stay on the cutting edge. They like to be able to read articles in the latest journals and be able to apply the lessons learned straight away. Happy engineers are good employees. They are more productive. They are more collaborative. They tend to not be looking quite so hard for that next dream job. They tend to be more forgiving of working conditions that might not be ideal. Engineers are creatures who like to learn and keep learning. Working on the same code and project and tools for year after year will be the death of an engineer and you will end up with just mediocre hackers left on your team as the engineers will be long gone.

So before you decide on your next upgrade, think about all of the costs involved, there are many hidden ones you may overlook at first glance. But then make sure you also think about all of the benefits (both short and long term). Not every upgrade will make sense, but I bet that a majority of them will.