Green Moon Software, LLC

The Best Confidence Builder is Experience

What stops a lot of people from trying something new? Fear of failure and lack of confidence are two that come to my mind. Failure and “failing fast” has been a popular topic in the recent years. However, I do not see a lot of articles about confidence. To me, being confident in oneself eliminates a lot of fears.

How does one build confidence? Through experience. Experience is not something that you have when you are born (obviously). It it gathered over time. Often through repeating the same thing. Drills are one way to gather experience. Drills build muscle memory. When I was training for my pilot certificate, I had lessons that only practiced take-off and landings. These lessons were three to four times a week and included up to 10 landings per session. My instructor kept hammering the fundamentals until they became second nature.

The best way to gather experience in software development is to write software. Often times, though, simply writing software on-the-job only gets you experience using the tools, languages, and ideologies that your company has approved. If you are still writing software the same way you were a one, two, five years ago, it might be time to expand your toolbox.

A common suggestion is to commit to open source projects. I personally have no experience with that due to a lack of ambition of my part. It feels like it would require a lot of prerequisites. I would have to find a project needing help, read through the developer guidelines, find an issue that I can fix, submit a pull-request, and so forth. To me personally, that seems like a lot of work. If I am coding for fun, it should be fun.

Therefore, I suggest writing software that scratches your own itch. If there is a problem that you wish a computer could solve for you, try writing it yourself. I have written 20+ software projects for my personal use. Most of them have been thrown away after a while, but what I learned while writing them has stayed with me. I have found that writing a “real” product while learning a new language or framework is ideal. Having a real product with real features keeps me interested in continuing development. I get bored writing a TODO app simply to learn a new language.

Once you have a good baseline confidence in yourself, you should not be afraid of attempting anything. This transcends software development. Every aspect of life is better when you are confident in yourself.

The title of this post came from the Star Wars: The Clone Wars Season 1 Episode 5 moral

Groovy Database Resource Handling

I am a big fan of using SQL in java and C# software. I typically dislike the usage of ORM frameworks like Hibernate. I feel that ORMs tend to hide a lot of of issues. They also tend to have a higher learning curve. I am not sure that the ROI on deeply learning an ORM is sufficient enough to use. However, there are a lot of pitfalls that come with being so close to the SQL. The largest of which is proper resource handling. If database connections are not closed properly, the application will soon become starved of available connections.

This post contains a simple example of using Groovy Categories to help manage the resource management of database connections. There are a lot more robust solutions (ie: GORM), but sometimes you only need a quick implementation.

To accomplish our goal, we will be using a static closure defined below. The OpenDatabase class is merely a container for the closure. I think the final implementation of the code reads nicely because of the name.

The DbConnection class is a simple interface for creating the groovy.sql.Sql object.

Below is the sample usage of these two classes.

The database connection will be closed after closure exits. Simple, easy resource handling. The groovy way.

Code Archaeology

I love sitting down to review a new codebase. Depending on the age of the codebase, it can be a little like archaeology. There are often distinct sections that have not been touched in many, many years. Sometimes you can almost see rings around the codebase similar to the rings on a tree. One section might be written in one framework, but another section is implemented in a different, newer framework. The following describes how I spend the first hour with some new code.


First Impressions

The very first thing I typically notice is the style of the syntax. Does the code use the correct industry standard for the given language? Or is this C# project written in the Java style (or vice-versa)? If I see non-standard syntax, I tend to assume that the code was written by novices1. First impressions come quick and are hard to change.

A lot of projects have a “utilities” package or namespace. These packages contain tweaks and helper functions to aid with the rough edges of the language. Prior to Java 8, how many java projects have special classes to handle date/time manipulations? These packages provide some insight on the level of knowledge the original developers had of the language. It is often enjoyable to see how others have solved similar problems. Sometimes they solve it in a similar way I have seen. However, often times it is solved in a completely different manner. Seeing those differences helps me grow and evolve.

Digging Deeper

After getting the initial peek, I look at the dependencies. What external frameworks are being utilized? This gives me a some landmarks to visit. I research any dependency that I do not immediately recognize to determine the approximate age and level of support.


A common sore spot in application development is accessing databases. In my experience, database access has been the largest performance bottleneck in most applications. In addition, incorrect handling of connections can cause memory leaks and bring an application down. I look to ensure proper connection handling as well as review the usage of ORM or other database mapping frameworks.

If the application is a web application, I will look at the general configuration. Whether that is the web.xml in Java or the global.asax in dotNET. I am looking for the general entry point for most requests. I follow up with reviewing how the chosen web framework has been implemented. Are the defacto standards followed?


I tend to learn something new regardless of the age of the software, the original developer’s experience, or the chosen language. Often I will see a language feature that I never knew existed or a method on a class that I have never seen. I enjoy reading code almost as much as I enjoy writing it.

1 The original developers may have only been novices in the chosen language. They could very well have had many years of software development.

Product vs. Project

There are many ways for a business to release software. Two common approaches are projects and products. They sound similar but are vastly different.

Project releases are often big-bang, all-or-nothing style of releases. Projects can often take months or even years to release. The software tasks are typically tracked with gantt charts and is often managed in a waterfall-style. The schedule is typically considered the most important component in this model. In addition, projects typically require vast amounts of documents prior to the first line of code being written. These documents include requirements, high-level design, detailed design, use cases, test scripts, and countless others. Project releases are often used by “enterprises” to release software.

Most of the projects I have worked on have failed. Those projects that were successful typically failed within a year. When a project completes, the organization will move their human resources to a new project leaving noone to maintain the software. Software is rarely done. Projects seem to encourage software developers to take shortcuts to make the due date.

Product releases on the other hand, typically do not have a finite end date. Software is released in feature and bug fix increments. A software roadmap help guide the development effort. These roadmaps provide a general idea of when features will be implemented. Since there is no end date, the software developers can evolve the codebase. This helps create a clean, maintainable source tree. Developers typically take more pride in their work. They know that the shortcuts they take today will affect them in the near future. The most important component is this model is working software.

In my experience, software managed in the project model feel heavy and slow. Whereas, the product model seems a lot lighter and quicker. I prefer to work on products and not projects. What type of release model do you prefer?

Legacy is a Four-Letter Word

The term “legacy” has mixed meanings in software development and I am personally trying to remove it from my vocabulary. It often has a bad connotation. Many developers use it to describe code that they did not write and do not like. It is often used to describe code that may not have used the best developmental practices. Software developers may also take offense to their code being called legacy.

Youthful software developers tend to dislike legacy code. I was once one of those developers. I thought I could easily rewrite a section, feature, or even a whole program in less time than it would take to make minor changes to it. I finally learned my lesson after many, many, m-a-n-y failures (and one success1).

Now, instead of using the term “legacy”, I try to substitute with “existing&#“. I don’t shy away from existing code. I embrace the fact that the code has many battle scars. Those scars are years of bugs that have presumably been killed. The intrinsic evolution of features and nuances that make the product what it is today. I no longer have a craving to slash and burn code to simply start with a greenfield.

I prefer working on an existing codebase. I love fixing issues that the client has had for many years. I enjoy incrementally making software better one refactor at a time. It is also a lot quicker to see the software I’m writing get in the hands of end-users and make a real impact.

I would like to tell all of the developers that think they are stuck on a legacy project:

Contrary to the term, things aren’t always greener on a greenfield project.

We should all simply enjoy the code we get to write. I know I love writing every line that I can. If you focus on keeping things clean and concise, your legacy will be appreciated by those who follow.

1 I actually did rewrite an entire program in one day. However, I was scared out of my mind when the Vice President of Information Technology actually called me on my brazen promise. I ended up working late into the night. I learned a valuable lesson about having a big mouth. That was also the last time I made any more “bold rewrite” statements.