Write Run Rue

Comprehension.equals(null)

2010-07-22T16:56:00.001-07:00

This summarises the quality of the java code I'm working on at the moment:

if(this.getConfiguration(key).equals(null))

It's not complex, or obfuscated, it just shows a fundemental misunderstanding of the langauge.

Wrong, Sun. Very Wrong.

2010-06-01T17:20:00.000-07:00

Sun Microsystems, Inc. respects your desire for privacy. Personal information collected from this form will not be shared with organizations external to Sun without your consent, except to process data on Sun's behalf in connection with this transaction. We will use your personal information for communications regarding your account and your subscriptions.

I just wanted to download an older version of your SDK so I could do some development work. Why the hell do you need my name, email address, country of origin and affiliated organisation? I know Oracle do this with their commercial products, but making me receive a download link in an email for a free SDK of a language that you are presumably trying to encourage people to use is the height of stupidity

Now excuse me while I go find a download mirror that doesn't ask for my personal details.

Test Cricket or Programming?

2009-07-12T06:56:00.000-07:00

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

Other People's Problems

2009-06-09T02:17:00.000-07:00

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.

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.
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.
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.

Positive For a Change

2009-02-25T02:26:00.000-08:00

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.

Stop Hurting the Language

2009-02-24T15:02:00.000-08:00

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

No Hands for Beginners

2009-02-08T17:58:00.000-08:00

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.

Good, Bad or Ugly?

2008-11-26T01:00:00.000-08:00

A lot of people in my office complained long and hard (but not loudly, of course) when the CEO suggested we come up with a set of benchmarks to objectively measure the quality and quantity of code that developers produce. I'm still forming my opinion on the whole matter, but the argument from many developers was that it's not possible to objectively measure who are the most productive developers because software development is different and special.

Remarkably, the same people don't seem to have any problem saying that they can tell you who in their team writes bad code (everybody but them) and who writes code too slowly (everybody but them again). To try and help out a bit I'm going to put forward the following set of measurements to gauge code quality.

1. Can you understand it?
This might look at first blush to be more a measure of the reader than the writer. After all, surely a decent programmer given sufficient time will be able to figure out even the most misguided and obfuscated code? Well, that's probably true, but there's a catch. If you're writing code to specification for a client then time is your perpetual enemy. If it's code you could understand after re-reading half a dozen times, stepping through using a debugger and a few terse emails with the author then you can't understand it in the context required by your job. In the time that took you would have been expected to find the code, understand it and fix the bug that's been reported in under the time in the project SLA. I don't care whether the code is extensively documented, self-documenting, uses line by line logging to describe its process, or whatever other method you prefer. If your company has a stated policy then it's probably best to use that, but the important thing is clarity.

2. Does it work?
This one is simple to define. Does the code fulfill its required purpose and nothing else? Figuring out whether or not it works is a lot more difficult. Working most of the time is not the same as working. That O(2^n) algorithm so many developers find abhorrent doesn't bother me at all as long as it works. Of course if the code in question can have n=1,000,000 and it needs to run in under a second then my guess is that it doesn't work. If it makes a call to an external system without safeguards and you can't guarantee the external system has 100% up time and is bug free, then the code doesn't work. Before deciding the answer to this question I suggest making sure you have a test process in place that can actually let you know whether the code works.

That's all of them. I know it's not entirely objective, but if the answer to these two questions is "yes and yes" then you're looking at good code. Not necessarily great code or perfect code, but good code.If you've got time to worry at code that is "only" good then I want your job.

I'm not saying that there aren't hopelessly incompetent developers out there, and if they're in your company then they need to be out of there as soon as possible. If somebody is committing code that breaks the build every day, doesn't write or update unit tests and hasn't had a positive code review in six months then I'll agree with you: that person is has to go. If the tests all pass and their code reviews are positive (and no it doesn't count if the negative code reviews come only from you) but it's not how you would have done it then I would advise you suck it up and get back to work. If you're getting mad at them because you have to look at their bad code under the pressure of fixing a critical bug reported by the client at 5 o'clock on a Friday then the correct thing to be angry at is the process that let the code get out into production in the first place.

On Time vs In Time

2008-11-08T20:40:00.000-08:00

Making the release date is generally regarded as a cause for celebration as the project has been delivered on time. A bigger cause for celebration would be if the project is delivered in time, by which I mean "in the number of hours we said it would take."

Quick Question

2008-10-25T20:08:00.000-07:00

At the point the software goes live, any design issues found get raised as change requests which the client has to pay for because they signed off on the design. The very same clients signed off on user acceptance testing but any defects found at this point are covered under warranty. Why aren't design mistakes covered under warranty in the same way as code mistakes?

Not Exactly Correct, More Its Opposite

2008-10-25T19:05:00.000-07:00

One of the problems with code reviews is that the recipient of the review can get a little, uh, defensive. Assuming that the review isn't combative and makes valid points, why would this be? After all, a bit of constructive criticism should always be welcome.

While this is more or less true, consider that day to day life of a developer in consultant software projects consists of talking to various groups for clarifications and any other information required, writing code, and finally, being on the receiving end of something a bit like this:

First, the project manager lets you know that your estimate of two months was wrong, because you've only got six weeks. Then your own code or someone else's tells you over and over again that you're wrong (unit tests, compilers, etc). Next the code goes to the testers, people hired full time to explain in detail just how wrong you are. After this, it's off to the client project team for another round of testing. Finally, it goes live, the end users get their hands on the software and you can be damn sure they'll tell you that you're wrong. Guess which frustrated question you hear from end users?

"Who designed this crap?"
"Who signed off on this crap?"
"Who wrote this crap?"

Hint: most end users don't know that there's a design phase or sign off.

Yes, this is an exaggeration, but all I'm saying is that maybe developers are not the prima donnas they seem to be when they overreact to code reviews. Maybe it's just that adding yet another group of people to tell them they're wrong can be a bit annoying the first few times.

Content? Happy? Passionate?

2008-10-17T04:02:00.000-07:00

For everyone else, starting next Monday we're going to ten hour days. Eight of those hours have to be between ten and six ... so we're just basically going to be crunching company-wide... and then on Saturday it's core hours, so 1:30 to 5.
- Rod Fergusson, Producer Gears of War

I was watching my bonus content disc from the Gears of War collector's edition when I heard the above quote, which was made four months before the game went gold. You can't tell from the quote alone, but nobody is surprised or obviously annoyed about the announcement. The assumption seems to be that this is simply how the industry works, and it's a reasonable trade-off to work six day weeks in exchange for creating one of the landmark titles of the year.

The quote above is followed by "No limit on what your duration of time beyond that is, but we need need you at least here on Saturday at core hours." People are going to be voluntarily working more than the mandated 53.5 hours a week, and they're being reassured that they're not going to be pressured about working too much.

Now, sure the games industry is a different beast altogether to corporate software development , but consider this: what would be the reaction in your workplace if your project manager came in and said a six days work week was not only expected, but mandatory? In my situation I'm pretty sure it wouldn't be met with indifference and people asking if they could work more hours.

What's the difference? People who make games want nothing more than to make games, People who make corporate software have a job. There simply doesn't exist an outcome from a corporate software contract that is worth 27 unpaid days' work over four months. If everything goes perfectly to plan the best result is that nobody will complain. There are three basic reasons why people will work mandatory overtime:

They need the job. For whatever reason, be it family or mortgage or whatever, the employee can't afford to lose their job by refusing to work the overtime.
There's a payoff at the end. I don't mean overtime pay, I mean millions of dollars of stock options in an IPO or similar.
They are passionate about the work. The person wants nothing more than to see the project get released on time and to the highest level possible. There are a number of motivations for this passion, but the fact that the passion fuels the work remains unchanged.

Can you think of a situation in your job where you'd happily work an extra 30% in unpaid overtime for four months just to get the product out on time? I can't, and I really wish I could.

Snowflake Specifications

2008-10-10T02:26:00.000-07:00

One easy mistake to make when making preliminary estimates is picking one method as the sole basis for estimates, for example functional areas. Although it's tempting to think that you know what's required when a functional requirement like "add a new user" or "report on daily revenue" shows up in the RFT, the truth is you don't have a clue. The part that requires a swanky front end and persisting the information to the database is what you see, and that is easy to estimate. The seventeen step user approval process, and the half a dozen external payments systems the daily revenue report has to interface with aren't mentioned anywhere, and if you think a RFT is going to include this information, you don't work in Australia.

The real killer in these situations is business rules. Clients rarely know all of the rules they follow, sometimes because their old system does it transparently, sometimes because they do it so often they don't even think about it, and sometimes for no discernible reason. If you ignore the number of business rules that govern an area of functionality then you run the risk of seriously underestimating any changes to scope that might occur. Each new business rule, no matter how small, will take time to implement and it can really add up.

Consider the situation geometrically. Think of a functional area as a triangle, bounded by its business rules (no really, do). The developers and the business analysts get together and come up with an initial estimate for a supersoldier breeding program based on the requirements provided by the tax department. Several months later, the client comes in and mentions that even though only people over 6'4" are allowed to be users of the system, if they also have brown hair, then they only have to be 6'3". Now your triangle's sides have another little triangle jutting out of the side, because there's a new business rule, but it's only a little one, and it doesn't increase the functionality much. Oh, and also if the user has blue eyes, all the height requirements are reduced by 1". Now each of the little triangles has a littler triangle jutting out of it. Half a dozen such meetings later, and it's time to re-estimate the functionality.

If you know your maths, the area now in scope should be a familiar shape, if not I guess it's just a pretty snowflake. On its face, the scope of the functionality has increased, but to less than double its original value. A price for the change can be generated based off the original estimate and nobody interrupts the development team. After all, they haven't started working on it yet and they're all flat out working on other features.

So, what's the problem? Well, the functionality may not have increased much, but the business rules defining the functionality could blow all the way out to infinity and functional requirements still wouldn't change much.

I know it sounds simple, but make sure your initial estimation method has enough flexibility to account for a variety of types of changes. If you don't, you'll end up getting snowed under.

Programmers' Programmer

2008-10-09T05:10:00.000-07:00

There exist men who are described as "a real mans' man." These men are tanned but only because they hike and fish, know how to rebuild engine blocks, love to watch the game on Sunday with their mates and have used every attachment on their Swiss army knife. They read Hemingway, can fix a burst pipe, and have even made a bit of money on the stock market.

Is there a programmers' programmer? If so, what habits does he (or possibly she) have? Are there specific tools that he uses, or is flexibility the key? I think I should try and figure this out.

Quality, no adjective

2008-10-06T05:14:00.000-07:00

The discussion du jour at work for the last couple of weeks has been quality (so probably discussion du semaine, or maybe de la semaine. I haven't studied French in a while). The argument goes something like this: in contracted software the four variable values are scope, price, time and quality. In a fixed price government contract the price and time are invariant, and the scope's only going to increase. This leaves one axis along which adjustments can be made to make sure the company makes a profit. Problems abound.

This is not something you can tell the client, at any level. It is one thing to have a clause in the contract that allows for some preset number of allowable minor defects in the finished product to allow sign-off to occur, and another altogether to announce that quality will be the dumping ground for shortages that occur in the other three factors.
Quality is not a linear scale, or at least most scales of quality do not degrade gracefully. It only takes one defect with the login process for an application to become unsuable, for example. Or the average transaction time increases an extra ten seconds to be longer than the default timeout on most browsers.
Programmers care about the quality of their work. That's hardly unique but it needs to be remembered. Even if the front works like it's meant to, every cut corner, every hard-coded hack hurts. Attitude by the end of the project is a different matter for a different time.
What is quality? Which of the thirty seven answers to that question are you working to? This should probably be number 1 on the list, but it's difficult so I'm hiding it at the bottom.

Disclaimer

2008-10-06T04:43:00.000-07:00

I spend a lot of time thinking (read: complaining) about various aspects of the nature and quality of the code that gets written in the corporate and government world of consultantware. A lot of the problems are the old classics that you'd expect from lazy or hurried programmers, and some are unique to the nature of the business (or so I believe).

I have discussed a lot of these topics with Jonathan Lange, whose work in the open source world with Canonical is more or less the polar opposite of my own. So if you tire of my griping, I recommend Mere Code for a different perspective. Also, you will learn about Bazaar.