Wednesday, February 25, 2009

Positive For a Change

I had intended when I first started this blog to include a bit more about the improvements we've been making in the development process at work to get things a bit more structured. The fact I have not is not indicative of any omissions on my part.

Now comes the positive bit. A couple of days ago I made a modification to the pre-commit hooks on the svn repository for the new project I'm on. Before my alterations, the script basically checked that the log message included a reference to an issue our issue tracking system (or at least something in the right format, actually checking for the issue's existence is on the todo list) and had some text in the message. Now, after a grand total of about half a day's effort I have modified the script to also load any modified java files and run checkstyle across them. Basically, it uses svnlook with the cat option to write the changed files out to disk, runs checkstyle across each file in turn, and then deletes the file, in a grand total of maybe half a dozen lines of python. It's currently using the strictest settings as laid down by the godhead of Sun, which are a little too strict for our purposes, but it's modified easily enough. The nice thing is that it's a fairly quick process that only adds a few seconds to the commit time.

The upshot of this is that a lot of the coding style guidelines that people are supposed to be following but which are ignored as soon as a deadline looms, are now enforced before the code is committed. Sure, there'll probably still be badly written javadoc, but at least there'll be javadoc written at all.

Next on my list: automating the creation of new version numbers inside Jira when creating a new svn branch. I don't think it will be quite as easy as the checkstyle.

Tuesday, February 24, 2009

Stop Hurting the Language

My least favourite corporate jargon has officially changed. "Moving forwards" will have to take a back seat to the truly awful "product visioning".

Sunday, February 8, 2009

No Hands for Beginners

In most large government contracts, the vendor specifies a target technology, at the moment in Australia this seems to be split pretty evenly between J2EE and .NET. Clearly there are considerations that need to be made when choosing what language, etc to use such as operating environment (if the client has a general Oracle licence, offering a SQL Server solution is a little silly). Beyond this, what the hell are clients doing choosing technology stacks? Let's have a look at a few of the normal excuses.

"X is a well-established technology, so it's lower risk than Y"
Aside from the fact that government vendors accept pretty much zero responsibility in large projects, in my sadly ever growing experience large government contracts can fail for a variety of reasons. Poor communication, people in over their head, in-fighting on either side, stubbornness and power-tripping are all excellent candidates. I am yet to see anything fail because a class had import statements instead of include statements.

"We won't be able to find anybody to support that"
One of the most pervasive myths of development is that the programming languages somebody knows is important. Maybe it was important at the dawn off programming, I don't know, I''m not that old. Any modern OO language can probably be picked up in a few weeks by a decent developer who knows at least one language. It might take a bit longer but it will definitely be less time than it takes to get to grips with a vast code base of uncommented, hastily written code in a language that wasn't really a good fit for the requirements.

"I read an article on the internet that said..."
I would like to respond to this particular argument in two ways, first: shut the hell up. I will find you an article that says the exact opposite if you give me five seconds. Second: there's a person on the project, probably with a role like system architect or similar whose sole job is to make these kinds of decisions. Failing that, maybe the people who spend forty hours a week or more writing code have slightly more informed opinions on such matters.

I guess what it boils down to is that if you don't know what you're talking about, take your hands off and trust the people who do to make the right choices.