Wednesday, November 26, 2008

Good, Bad or Ugly?

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.

Saturday, November 8, 2008

On Time vs In Time

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

Saturday, October 25, 2008

Quick Question

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

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?
  1. "Who designed this crap?"
  2. "Who signed off on this crap?"
  3. "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.

Friday, October 17, 2008

Content? Happy? Passionate?

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:
  1. 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.
  2. 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.
  3. 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.

Friday, October 10, 2008

Snowflake Specifications

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.

Thursday, October 9, 2008

Programmers' Programmer

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.

Monday, October 6, 2008

Quality, no adjective

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.
  1. 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.
  2. 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.
  3. 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.
  4. 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.


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.