Wednesday, May 25, 2011

Unrealistic Expectations

So ya.. I do software engineering for a federal agency. They're trying to meet a global deadline for conversion to a coding system, and by "codes" I mean a system where a number (alphanumeric) represents a concept. The old system has been in use since I was a kid, at least, and this new system is designed to be more than just a code + description. It will include "meta data". I hate the term "meta data", when what it actually is, is an expanded bit of jargon that is associated with a code.

Anyway, I'm going to be writing an API for this project. Mine is a very small piece. What happens is that a user types in a number, and all the possible codes that would be possible based on that that number (including meta data) would be shown to the user as a "pick list", meaning the user could select an entire code after having typed in just a single digit of the number. Each additional number a user types in further narrows down the list.

It's a fairly straight forward bit of logic. The data base that contains all the codes and meta data will have multiple indexes that can be searched through and parsed out. So, if each code is sorted sequentially, it's easy enough to start at the number the user has typed in, you'd back up one level (upward in the db) so you know that the next record in the db is the first code that would be complete based on the number the user typed in. Then you'd simply loop through the db building the pick list until you hit a number that doesn't match the number the user typed in (based on position of the number). The entire array of numbers + data would be returned to whatever called the API. I'm pretty sure the quantity of numbers that would be possible based on the first digit selection would not exceed the memory constraints allowed in a single memory partition. It's like a thread that has a maximum memory allocation, and if you exceed it, it'll err out and you'd actually have to hand off the data via a file rather than a memory variable.

I kinda like coding APIs. They're typically just logic without having any user interface crap involved. The UI software calls the APIs to retrieve some data or other, and those are not fun to code.

The problem is, I'm in a meeting right now that is setting the "milestones" of the project. They ask developers how long it will take to create all the new software and databases. This particular federal agency has a new focus on creating consequences for missing deadlines.

Writing software is not easy to do. Something always goes wrong, and things always take longer than expected. In the game development world, they push developers to get stuff done by some deadline that somebody else established, and if it's not ready, they just send it out anyway, with loads of bugs, expecting they can fix it in a patch afterwards. In the world I work in, you can't ship anything with bugs. It does happen that something slips through, but you simply can't knowingly ship some software that has a problem.

Basically, what they do is create "consequences" for not having good predictive skills. The "consequences" directly contradict the edict that buggy software not be released because people's lives may be put in danger.

Which is why this particular federal agency has lots and lots of problems actually delivering quality software products. It's a bad philosophy, which of course, is all related to bad management. However, the "consequences" never seem to apply to upper management.

No comments: