Should Have Paid Me More

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, Part III, and Part IV of this series to gain context.

As demonstrated in Part I, Part II, Part III, and Part IV of this series, the Plus application was a mess. It never really worked and when the desired functionality was simulated, it caused other issues. To be fair, the department that requested Plus in the first place was also a mess – its manager not only couldn’t manage the department’s 150 employees, but further had no understanding of what they did or what they were supposed to be doing (and those two things were definitely not the same). As a result, change requests for the Plus application had no order, logic, or sanity, and often contradicted other change requests made by the same department slightly earlier. It was a constant cycle of “Make this change” “Why did you change that? Change it back!” “Make this change”. 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…

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

I enjoy using tables. They clearly demarcate the boundaries between datum, creating an easily-understood convention for interpreting information while retaining amazing flexibilities. They’re dead straight simple to program – an HTML layout table be created using as little as six tags with very logical names, a JSPWiki table simplistically requires only a few pipes, and Microsoft created an entire program designed around tables. They call it Excel. continue reading…