Ini files and Apache Commons Configuration

Trashing old software

The project I’m currently working on uses a simplistic object store for persistence.  The original authors, in their collective wisdom, decided that whenever something needed to be saved they would save it to a hashtable, and use Java serialization to save that to a file.

In a way I can see why they did. It’s a quick way of getting a simple to use object store.  The project has been through several revisions since, but the data store stayed the same.  It should have been replaced with something more robust a long time ago.  I’ll explain more after the jump …

Keeping it Simple

Moleskine and Pen

George Bernard Shaw is quoted as saying, “The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man.”  While we all appreciate progress, I sometimes have to wonder at the way people look at the world.

Decisions, decisions, …

It is our choices. . . that show what we are, far more than our abilities.

So we’re beginning a new project, and it has come time to decide what we’re going to build. In many ways, we are spoiled for choice. There are many ways in which the existing software could be improved. Do we pay down some technical debt, include a new feature or support new hardware?

Pre-Merge Formatting

Merge Right

A problem with formatting code on a branch, is when you come to merge it back to the trunk, you end up having to work thorough lots of file changes which are really only formatting changes.  The larger your project size, the more work this involves.  I was faced with a similar task recently.

While editing file by file, I usually do the Ctrl-A Ctrl-Shift-F combo to ensure the file is formatted according to our corporate standards before saving any edits.  Since much of the code I touched on the branch was formatted under a different standard, and I touched a lot of files while introducing log4j logging, the end result was heading for a hairy merge.  What I really needed was a way to bulk format both the branch and the trunk versions of the code-base.

Luckily, I realised that that same formatter embedded in Eclipse can be used to bulk format Java source.  Here’s how …

Howto: Pause a Shell Script

Computer Data Output

File this one under “Another Nifty script-let”.  The problem this time is getting a shell script to pause for user input.  What I needed was a way to make a script stop, saying “Hit a key to continue..”, wait for the user to hit a key, then continue the script execution.  Here’s how:

Risky Business

Project Management Porn

Anecdotally, I had always known that Software Engineers are terrible at estimation.  I had never realised exactly how bad we are.

Some rules of thumb which seem to pop up now and again, is to take your engineers best estimates, and double them.  Then you’re actually in the ball park.

Swaying the Team to Innovate.

Innovation in Corporate America

As I mentioned in Between a Rock and a Hard Place, our team is currently on the horns of a dilemma.  I likened our situation to racing on a flat tyre.  Do you stop and fix, taking the hit of lost time, or do you make a best effort to keep pace, almost blindly disregarding the situation.

I’ve just finished reading Sway (Brafman & Brafman, 2008).  It offers some additional insights into our situation.  For example, all my engineering training has been around technology.  How computers work, how software works, how to create good software, how software design works, how the software process works, etc.  As far as I remember, no time was given to group dynamics.  Since most non-trivial software requires a team to collaborate, one would think that taking the group into account would factor into software design and engineering.

Installers Matter

InstallComplete

TG Daily reports that Mozilla have found that 50,000 people fail to install Firefox every day.  On one hand, I find this surprising, but on another, not so much.

Between a Rock and a Hard Place

red car red rim black tire flat

Jeff Atwood makes some good points regarding paying down your technical debt.  I certainly agree with many of his sentiments.

The problem is, refactoring takes time.  The best option is a little now, a little later.  Putting it off for long periods, will eventually come back to bite you.

I’m in the process of being bitten…

Life Lesson: The More You Write, The Less They Read

Fall-2006

Since I realised this, life has become somewhat easier.  Being a Software Engineer means that I often have to communicate with people with non-software backgrounds, such as Clients, Management or Marketing.  A difficulty we have in communication, are the multi-letter acronyms (MLAs) and other jargon which is prevalent in software, and other technical fields I imagine.

When it comes to documentation, the initial reaction of a reader who doesn’t understand what you’ve written, is to claim that insufficient information was present (whether this is true or not).  The typical responce from the Engineer is to provide even more MLA and jargon loaded text.  Essentially providing a larger maze of documentation for the reader to get lost in, resulting in a request for more documentation, and the cycle goes on …

The solution to this conundrum is not more documentation, but more consice and succinct documentation.  Avoid MLAs and jargon where possible.  Where this is not possible do your best to explain it simply.  Know your audience, and speak in terms they can understand.  Do your best to keep it short and to the point.

Finally if all else fails.  Suggest a GIYF.