Kangaroos with missiles, or Reusing code for fun and profit...but mostly fun.

Ah, the killer kangaroo story. Maybe you've heard of it, maybe you haven't. As the story goes, work was being done by the Australian Defense Science and Technology Organization's Land Operations/Simulations on a simulator for helicopter pilot training. It included, among other things, herds of kangaroos, since startled animals could give away a helicopter's position. “Being efficient programmers, they just re-appropriated some code originally used to model infantry detachments reactions under the same stimuli, changed the mapped icon from a soldier to a kangaroo, and increased the figures' speed of movement.

“Eager to demonstrate their flying skills for some visiting American pilots, the hotshot Aussies "buzzed" the virtual kangaroos in low flight during a simulation. The kangaroos scattered, as predicted, and the Americans nodded appreciatively . . . and then did a double-take as the kangaroos reappeared from behind a hill and launched a barrage of stinger missiles at the hapless helicopter.”

It makes a good story, and shows quite nicely that even when reusing code you have to be careful, but as it turns out, there's a bit more to the story, and it wasn't a mistake so much as a bit of fun. The kangaroos weren't there out of necessity, the interesting bug was discovered rather early, and the “kangaroos” were firing beach balls, the default weapon of the simulation code.

Initial story found somewhere on the net, the rest from the snopes article here

The Null Object Design Pattern

I came across an interesting design pattern recently. Say you have a service that fetches a foo object and calls foo.bar() if some condition is met. Under normal circumstances, you'd have to check if the foo object is null. What if, instead, you could have an object that represents a null foo, and just has no-effect methods. That way, the “null” object could be treated the same way as a normal object. To do this, just write a private inner class that extends foo, have its methods do nothing and return false on condition methods. The outer class will have a static final instance of this, and any outside methods that are supposed to fetch a foo then return this “null” object if they fail.

I found it here

Evidence Based Scheduling

Developers don't like writing schedules. They're a pain to write and often don't seem realistic. I found a system for writing them called evidence based scheduling. The complete description can be found here but here are the highlights:

1:break things down into small timeframes, no more than 16 hours. Large timeframes like days and weeks leaves what actually needs to be done extremely nebelous. With smaller timeframes you need to find out what's actually coded.

2: track elapsed time. Chart estimated time for tasks vs how long they actually took. This gives a nice velocity metric. Keep this 6 months back.

3: when estimating the time it will take to complete future tasks, run a Monte Carlo simulation assigning random values from the person's velocity history to each task. The estimates and their conversion to calender dates can be automated, and the averaging against the person's velocities will help give a better estimate.

Interesting enough, because of the way the estimates are calculated, interuptions to the coding time don't need to interupt the “clock” with elapsed time. The number of times that velocities where time taken involves one of those interruptions are used is very similar to the chance that those interuptions will happen.

4: manage the projects actively. You can see how cutting lower priority effects ship dates, estimate ship dates for each person, and use these to make changes

The method kind of reminds me of some of the artifacts used in SCRUM and other agile programming methods. I'm guessing something like this would be easy to integrate.

The Waterfall Development Method

One of the older development methods out there, the waterfall method specifies a single major iteration, starting with requirements analysis, then going through design, implementation, testing, release, and maintenance. Its has a few advantages, such as clear start and end points to each part, and improved quality because the specifications must be finished up front, helping prevent feature creep. There are, however, several major criticisms to this method. First, the requirements may not all be known at the start, but rather will emerge as the project progresses. Also, because there's no return to previous steps, what you have when you finish one is what you have. In some cases, you'll hit the implementation process and find out that there are roadblocks.

More reading here

UML class diagrams

UML, or Unified Modeling Language, encompasses several documenting diagrams, including ones representing use cases and sequences of interactions between the code, but one of the most basic, and the one that often first presented, is the Class Diagram. A class diagram gives a clear, visual representation of the class hierarchy and the interactions. It helps with planning a system, as well as being able to tell at a glance how things interact.

Test Driven Development

Test driven development, or the practice of writing the unit tests before writing the code. This means you have to know the requirements before you start coding, and in such a way that you can write a set of tests that encompass that specification. This gives a few interesting benefits. First, once you have the tests written, you have a metric to measure completeness of the code. The more tests passed out of the set, the closer you are. Second, during refactoring, you have a way to make sure you haven't broken the functionality tested.

How to write unmaintainable code

I found another "what to avoid" article cleverly disguised as "how to make things bad" related to programming. I like articles like this because they're memorable and funny, making it all the more likely for the concepts to stick. Sure, some of them are a bit out there (using a baby names book for variable names, camouflaging commented-out code), but others point to rookie mistakes (obvious commenting, ignoring coding conventions, not validating input), and suggestions to use features of languages like assert.

Article here