Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

How requirements help make vacations successful

Jason Bock | May 10, 2016
Working at a relentless pace can lead to unfortunate circumstances. You have to balance speed with clarity

how requirements help make vacations successful

This vendor-written piece has been edited by Executive Networks Media to eliminate product promotion, but readers should note it will likely favour the submitter's approach.

Back in February of 1997, I changed jobs and started working with a consulting company. My first client was an industrial manufacturing company where thousands of technicians would work in the field installing and servicing their equipment. To enter their time sheets, the techs would use an Excel spreadsheet to fill out their information for the week and submit it to the accounting department. The people in accounting would re-enter the technicians' information into the financial application.

Needless to say, this was inefficient for many reasons, and they had decided to create their own internal Web application to allow technicians direct access to the back-end systems.

Remember, this is 1997, when Netscape was the browser of choice and using Perl CGI was an accepted Web development approach.

I was responsible for creating a VB application that allowed accounting employees to enter time for technicians who couldn't access the Web application, along with creating payroll and labor files every week for other various back-end systems. The other developer on the project handled the website (and yes, he used Perl).

Needless to say, the payroll file that was created on Monday was pretty important to get right and done on time. Unfortunately, we were working in an environment with a SME who, while he was a good person at his core, was hard to work with at times and often spoke before he thought through the ramifications of his statements. Requirements were virtually non-existent, and testing ... well, if we thought it was correct, we shipped a new version. You can imagine that this didn't work very well, and in September things came to a screeching halt.

Mistakes were made

I was married near the end of that month. The Thursday before I went on vacation, the team was going to ship a ton of new features in the application. We were concerned that there would be issues, and while the Web developer handling the Perl side of things could work his way around in VB, he wasn't the one handling that area on a day-to-day basis.

We tried to do more testing before I left, and that gave us more confidence that the system would still work as expected. However, as you can imagine, there were problems, the biggest one being that creating the payroll file didn't work.

Again, I'll stress that this happened in 1997, a time when I didn't have a cell phone or a laptop with me such that someone could easily get a hold of me and yell at me to fix this ASAP. (Quite frankly, I would've ignored that anyway -- I was on vacation, and you're supposed to disconnect on a vacation!) Thankfully, the other developer on the project was able to figure out what the problem was and push a new version, but the fact remained: We still failed.


1  2  Next Page 

Sign up for CIO Asia eNewsletters.