The Master is Simplicity

by in Editor's Soapbox on

When I was in college, as part of the general course requirements we had to take Probability and Statistics. The first time around I found it to be an impenetrable concept beyond my grasp, and I flunked. Since it was a requirement, I took it again and barely skated by. Joy; I had cleared the hurdle!

By that time, it had become clear to me that I was going into a field that required a whole lot more understanding of P&S than I had acquired. Since I wanted to be properly prepared, I signed up for a free summer school course to try it once more.

Beyond Brillant

by in Feature Articles on

We've all had cow-orker's who couldn't do their jobs. Some people have even had the privilege of working with Paula.

Jarad should be so lucky.

Temporal Obfuscation

by in Feature Articles on

We've all been inflicted with completely overdesigned overly generalized systems created by architects managers who didn't know how to scope things, or when to stop.

We've all encountered premature optimization, and the subtle horrors that can spawn therefrom.

2018: The Wizard Algorithm

by in Best of… on
NIH syndrome causes untold suffering in the world, but for just a few pennies a day, you can help. Or maybe not, but not-invented-here meets password requirements in this story from June. --Remy

Password requirements can be complicated. Some minimum and maximum number of characters, alpha and numeric characters, special characters, upper and lower case, change frequency, uniqueness over the last n passwords and different rules for different systems. It's enough to make you revert to a PostIt in your desk drawer to keep track of it all. Some companies have brillant employees who feel that they can do better, and so they create a way to figure out the password for any given computer - so you need to neither remember nor even know it.

Kendall Mfg. Co. (estab. 1827) (3092720143)

History does not show who created the wizard algorithm, or when, or what they were smoking at the time.

Assumptions are the Mother of all Bugs

by in Feature Articles on

A long time ago in my "C" programming days, I learned that when you code up anything that depends on any sort of external data, be it a file, database or socket, you should be paranoid and do it defensively. After all, you can't control those things and there's no guarantee that they will always work the way you hope. Sometimes you care about every possible error code; sometimes just success or failure. The point is to check the result of what you tried to do.

Fast forward through several years of C++ and ten years into Java, and our boss calls us into the office.

The Command Controller application is failing and nobody knows why. It runs fine for a while and then it starts throwing what appear to be random exceptions. The problem is happening on almost every single command that it's receiving, but only in production. We can not reproduce the issue in any of the other environments (DR, pre-prod, QA or Dev). The team that wrote it is dumbfounded and has asked for help. We have a pretty good reputation at solving tough issues, so you guys need to drop everything and figure this out.

Politics Rules! Common Sense Drools!

by in Feature Articles on

As programmers, we all need to fix bugs. As experienced programmers, we recognize that sometimes, the ability to fix one bug depends upon first fixing another bug. Managers, on the other hand, don't always get that simple concept.

At the beginning of my career, I worked for Initrode where I wrote software to run a test-station that diagnosed assorted electronic components of jet fighters. Initrode acted as a government-supplier of the test station to another government contractor (LUserCorp) that used the station to write the test sequences to diagnose electrical faults. If the test station hardware malfunctioned, or there were bugs in the software that made the electronics tests fail to work properly, then LUserCorp could use that as an excuse for time and cost overruns. If that happened, then the government would penalize Initrode to recoup those costs.

Success Despite Management

by in Feature Articles on

In our industry, we all know that managers cause problems when they try to, well, manage. This invariably causes us to get frustrated. Sometimes when we rebel and try to force them to do the right thing, we are the ones that pay for it with our jobs. Sometimes, they get impatient at our mortal lack of $Deity-level skills to make the magic happen fast enough for them, and we pay for that with our jobs as well.

Occasionally, even though it seems as though managers never pay for their mistakes, Codethulu smiles upon us and gives us a glimpse of a Utopian world...

Blind Leading the Blind

by in Feature Articles on

Corporate Standards. You know, all those rules created over time by bureaucrats who think that they're making things better by mandating consistency. The ones that force you to take time to change an otherwise properly-functioning system to comply with rules that don't really apply in the context of the application, but need to be blindly followed anyway. Here are a couple of good examples.

Honda vfr750r

Kevin L. worked on an application that provides driving directions via device-hosted map application. The device was designed to be bolted to the handlebars of a motorcycle. Based upon your destination and current coordinates, it would display your location and the marked route, noting things like distance to destination, turns, traffic circles and exit ramps. A great deal of effort was put into the visual design, because even though the device *could* provide audio feedback, on a motorcycle, it was impossible to hear.