Sunday, July 12, 2009

Test Cricket or Programming?

  1. It bores most people, but those who are interested are fanatics
  2. Fashion is not a strong suit, and vests are common
  3. Being a bit slow and a bit overweight is perfectly acceptable
  4. Regular breaks for energising drinks are mandatory
  5. 5 days of intense activity can produce no result
  6. Everyday words have been co-opted to indecipherable jargon
  7. India is totally mad for it

Tuesday, June 9, 2009

Other People's Problems

One of the nice things about being a developer, the core thing if you will, is the problem solving aspect. Problem is there's classes of problems.
  1. Technical problems. Trying to get bandwidth usage or load times down, fitting more polygons on screen, other non-optimisation technical problems too. These problems are fun to solve because, unless you aren't familiar with Google, they haven't been solved before.
  2. Domain problems. Whatever it is you're trying to implement. This could be corporate business rules, streamlined email interface, shooting aliens in the face in a satisfying manner. These problems are fun to solve primarily because they are the goal of the software. Solved correctly they should make users happy, which is always nice.
  3. Other people's problems. External interfaces that don't conform to the documentation, invalid HTML, malformed data from legacy systems. Perfectly robust, usable, elegant code gets filled with exceptions and conditional branches that are only necessary on Feb 29 every third leap year. They are other people's problems because if the original author had done his job properly, it wouldn't be my problem now.
I thoroughly dislike other people's problems. They routinely put me off from hobby code projects. I'm more than happy to spend dozens of hours working on odd little projects in my spare time. What I'm not willing to do is spend dozens of hours dealing with the fact that 90% of people can't get their websites to be valid SGML, let alone valid HTML. Sadly other people's problems fill an inordinate amount of the project time in corporate land. They call it "systems integration" because it sounds better than "fiddly annoying crap." I think a lot of other people's problems would go away if web standards were more like other industry standards and you could get sent to prison or at least sued for ignoring them. I guess if the standards actually made sense and didn't change every eighteen months, they might be easier to conform to as well.

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.