Jason M. Hanley :: Custom Software Developer

Did you know that nearly 100% of drivers involved in accidents don’t think it was their fault?

This is perhaps not shocking, but what might surprise you more is that nearly 100% of them are wrong!

Most accidents are completely preventable, if you just follow advice from a good driver training program.

The “T-bone”

Primary Fault: “T-bone-ee” mis-judges distance of (or doesn’t even notice) oncoming car and turns left in front of them

Common Excuses:
“They came out of nowhere!” Cars do not randomly appear from spatial vortexes.  It was barreling towards you the entire time.
“They were speeding!” If you could tell they were speeding, you sure as hell should not have turned in front of them.

Primary Prevention: Don’t turn in front of cars unless you damn well know you’re going to make it! (duh)

Secondary Fault: “T-bone-er” ran head on into a car that turned right in front of them!  Never a good idea.

Secondary Prevention: Keep your foot over the brake and plan an avoidance when approaching an intersection with cars waiting to turn left.

The “Rear-end”

Primary Fault: “Rear-end-er” hits the car in front of them because they didn’t stop in time

Common Excuses:
“It was snowing/raining/slippery!” Yeah, so drive according to the road and weather conditions and leave some extra space.
“They stopped too quickly!” Umm, NO — YOU stopped too SLOWLY.

Primary Prevention: Always leave enough room ahead of you for an emergency stop, given current road and weather conditions.

Secondary Fault: The “Rear-end-ee” probably DID stop fast — likely because they weren’t paying enough attention.

Secondary Prevention: Avoid distractions (phone/texting/emailing) while driving and always look far ahead so you can anticipate problems before they “come out of nowhere.”

Those are just two examples.  There are many more.

So everyone — please, pay attention and take responsibility when you’re driving, because if you are involved in an accident — it’s probably, at least partially, YOUR FAULT!

As software moves into maturity, it becomes a delicate art to add features and fix bugs without screwing up stuff that already works.

I’ve worked on three 10+ year-old, massively-sized projects (CorelDRAW, Microsoft Access, and ERDAS Imagine) and let me tell you — the older the code base, the tougher it gets.

In very mature projects, maintainability starts to become more important than optimization, and the prevention of introducing new bugs can trump fixing old ones.  You’ll even see libraries where they decide to keep old bugs in place, since consumers up the chain rely on the buggy behavior.

If you’re a programmer, it’s important that before you change any function that is used elsewhere in the system (a “core” function), you check each and every place it is called and understand the implications of your change.  If there’s any doubt, you need to either step through, or ask someone else who is more familiar with that code.

A safer alternative is to write a new function that caters to your specific needs.  This may seem wasteful at first, but it actually pays off in the long run.  This is because it usually makes for less complicated logic in the function, and simpler dependency chains.

Adding additional parameters and conditional branches in an existing function can introduce subtle changes that cascade to other parts, causing subtle bugs that are difficult to track down, and even harder to fix.

That said, there is a time and place for refactoring, but it needs to be done carefully.  It should be done independent of other changes, and be extremely well tested.

Automated testing and regression tests help fight this war, but coverage is never 100%.

I’ve found it’s often better to err on the cautious side and try not to break things in the first place