Should Have Paid Me More

Everyone’s seen at least one enormous red button with a label like “GLOBAL THERMONUCLEAR WAR INITIATOR VALVE – DO NOT PUSH!”, oui? Of course there’s always a villain around to press the button and ostensibly end the world, but the general concept prevails.

Given the tendency of Plus users to do the most illogical things possible while refusing to read or apply any kind of instructions given and then blame the software for behaving “unexpectedly”, it seemed only fitting to provide them with the one thing they couldn’t screw up: the Do Not Click button. continue reading…

Code comment written less than a month ago:

/**
 * Added 10/7/2009 by specific request of sjohnson. Of course there's no HD
 * ticket or other documentation for the request because everyone knows
 * normal rules don't apply to the field staff.
 */

Code comment written today:

/**
 * Removed 11/5/2009 by specific request of sjohnson. Of course there's no HD ticket
 * or other documentation for the request because everyone knows normal rules don't apply
 * to the field staff. sjohnson swears this is a showstopper and must be removed because
 * now that he actually has to work in Plus on a daily basis he understands how
 * ridiculously foolish it is to clear out the time entry fields after every entry is
 * added to the table.
 */

continue reading…

Note: You may wish to read Part I, Part II, Part III, Part IV, and Part V of this series to gain context.

As relayed in previous posts in this series, the Plus application was meant to facilitate the transmission of data from field technicians to the home office. However, at some point it was decided that Plus should also be responsible for transmitting and displaying data from the home office to the field technicians. This information ended up being things like equipment-specific metadata, customer contact numbers, location of each piece of equipment, a directory of everyone employed at the company that developed Plus (no, I’m not kidding), and schedule data. All of this came from a poorly-standardized, non-normalized database used by the company’s CRM application, Nexterna Clearview, which uses a batch-and-post system. continue reading…

Note: You may wish to read Part I, Part II, and Part III of this series to gain context.

One of the prevailing requirements for the Plus application was that it allow field staff to enter data offline and “sync” it over the Interwebs at their leisure. In addition, the application had to get updated schedule information and previously-synced data and show it to the user while offline. As you know, the most logical design that meets this requirement is a disconnected client-server model. Therefore, a server had to be built to accept connections from the client, process incoming data, and send back schedule  information and previously-synced data. continue reading…

A few years ago I interviewed with a regional insurance company for a “Senior Software Developer” position.    The application I would be working on was described as an Online application that allowed the companies agents to quote and sign business.  It was a ‘robust and flexible’ system that had been developed and enhanced over 9 years.  The application was primarily developed by consultants (Boy THAT should have been a red flag), but the division was recently acquired by the regional insurance company and the new management wanted to do development in house.  I was to be the first of a dozen new hires.  I took the job.

continue reading…