Reservoir Dogs: DueDates 2.0 Edition
| Posted on Monday, December 08, 2008 |
0
commentsAdd comments |
Reservoir Dogs is a film by Quentin Tarantino from 1992 in which a would-be heist by a gang of ice thieves is set spiraling out of control when a rat (actually, a mole…er, undercover cop) sets the thieves up. After the opening scene just moments before the heist, the movie picks up right as everything has gone haywire with the gang scattered, either lying dead in the jewelry shop or running for their lives while dozens of police are searching for them.
There is a scene about an hour in where two of the gang members, Mr. Orange and Mr. Blonde (the members all went by color-name aliases) are holed-up in the after-heist staging area. Mr. Orange with a gut-wound is lying on the floor bleeding out, passed out and near death, while Mr. Blonde begins to torture a cop he happened to take hostage while fleeing the scene of the failed heist.
In Reservoir Dogs: DueDates 2.0 Edition, Mr. Blonde would be Wicket, Mr. Orange would be the DueDates application, and the cop would be my team of developers: Vincent Leung, Creighton Okada, and John Zhou. In this rendition, Mr. Blonde (read Wicket) definitely tortured our project and the team—“Look [programmers], I’m not gonna bull!@#* you. I don’t really give a good !@#* what you know or don’t know. But, I’m gonna torture you anyway. Regardless. Not to get any information. It’s amusing to me…to torture…[programmers].” And what’s a movie without the most appropriate soundtrack, as the torturing begins the radio is playing Stealers Wheel’s Stuck in the Middle With You. Here are the first two verses to set the mood as the rest of the story unravels:
Well I don't know why I came here tonight, I got the feeling that something ain't right,
I'm so scared in case I fall off my chair, And I'm wondering how I'll get down the stairs,
Clowns to the left of me, Jokers to the right, here I am, Stuck in the middle with you.
Yes I'm stuck in the middle with you, And I'm wondering what it is I should do,
It's so hard to keep this smile [on] my face, Losing control, yeah, I'm all over the place,
Clowns to the left of me, Jokers to the right, Here I am, stuck in the middle with you.
Clowns, Jokers, and Stuck in the Middle
Well, let’s clear up just who the “clowns,” “jokers,” and those “stuck in the middle” are…these would all be me and the other members of the team of which Wicket and DueDates pulled strings making us dance like little Marinette dolls. Our team consisted of me, Vincent Leung, Creighton Okada, and John Zhou.
I went into this project with an open-mind of my teammates. Although, I had heard what to expect from each from others, as well as, having read their blogs and looked over their prior DueDates projects, I had hoped that we would be successful at our endeavor to migrate DueDates 1.x to 2.0…or from a console application to that of a web application.
Honestly, I’m not sure what I would have done differently within the group. Each team member performed the tasks that were asked of them. We divided the tasks up, such that we could all work on something working towards the goal of merging our efforts. Creighton and Vince focused on getting the JAXB, XML, and configuration manager operating, while John worked on setting up the sorting method, making the libraries extensible, and cleaning up code. Vince also took on the task of setting up the email function and timer.
Being the sole team member with extensive web development experience (albeit in ASP.NET), I took on the task of the web UI, with the hopes of just “wiring” the rest of the team members’ efforts. In the end, this resulted in being the Achilles’ heel of our project. More on this later…
All team members were responsible for testing and writing documentation (including wikis).
As in the DueDates-Silver implementations, the team met several times (almost daily) throughout the project cycle, however, most of this occurred during the second week. The main issue with first week was the occurrence of Thanksgiving. While my team members celebrated their holiday on the traditional Thursday, my family waited until Saturday to celebrate.
This coupled with getting to know each other and mitigate our schedules really impacted our success during the first week. I don’t really blame anyone for this, as it’s just a matter of Life. We met initially the first day the assignment was given and divvied up tasks with the expectation that our initial tasks would be completed when we met again following the Holiday. This all went as expected with everyone completing their assigned tasks leaving the second week for wiring up the web UI and back-end components.
As mentioned earlier, following this we met at least a couple hours every day the remainder of our allotted project time. During this time, every one worked on their tasks. About the only thing I think we did not do sufficiently was communicate, including me, who had kind of taken on the role of project manager. More on this later…
I don’t know if the Hackystat SICU accurately reflects the entirety of the group’s performance. While I believe it accurately records the time, effort, and productivity of the individual programmers, it has no way of capturing what its sensors aren't designed to record. In this case, I am alluding to the fact that my teammates were doing their parts, but it was really hard for them to do more because they needed to wait for me to complete the wiring of the web UI interface to their back-end components. More on this later…
The Failed-Heist
It’s really difficult to judge, in my opinion, how much of the project we completed. We resolved the back-end implementations for support of an XML configuration file (R1), provided sorting (R4), filtering (R6), and email alerts (R7). The web application had some of the basic functionality (R2) with all the necessary CSS formatting (R3). (Note: There was no R5 in the requirements.) Unfortunately, R2 was the hinge-pin of the system, and I was never able to complete the wiring up of the back-end components. Which frankly, drove me to the point of such frustration…for many reasons…but, most of which had to do with the fact that I develop web applications for a living (not via Wicket). The major issue was I never quite wrapped my mind around property models, at least for listview and dataview “controls”. This in effect, killed our project. Mostly due to the fact that I spent way too much time on trying to get it to work by myself before asking for help…from my teammates and classmates. In many respects, I felt like I was wasting my teammates' time, with little for them to do, while I was tortured by Wicket, and they were held hostage.
So while DueDates 2.0 isn’t a viable production application, all the parts are there…just disconnected…like the body parts of some poor dead soul after an autopsy.
By the time I decided I needed help, there was sufficient time, but even after speaking with Arthur Shum and reviewing DueDates-Akala’s code, and my DueDates-Silver partner Robin Raqueno and reviewing DueDates-Ahinahina’s code, the pieces of the puzzle still remained allusive to me. Much appreciation to both Arthur and Robin for their time, support, and guidance.
Also, there was the issue of working with 3 additional programmers with six requirements in a short time span interrupted by a holiday. The biggest issue here was that I think there were too many moving parts, which proved difficult for me to manage especially under the pressure of a failing web UI implementation and having the capacity to be there to help my teammates with what they were doing when they ran in to issues. But, more importantly to me is being a good, helpful, and responsible team member, so I gladly stepped up each time, even returning the favor of assisting Robin by spending an hour showing him the ins-and-outs of CSS.
Another prominent issue with DueDates-‘Oma’oma’o was it began with an initial loading of DueDates-Silver’s code which eventually got hodgepodged with code from other projects. I think this caused a lot of overhead, which caused the team members to not really understand how the project worked or would work. A top this, most of the group had not worked with XML and JAXB, so this was additional overhead the project suffered from initially as well.
Track Two
If Reservoir Dogs: DueDates 2.0 Edition had another song on its soundtrack it would be Queen’s Under Pressure, which begins:
Pressure! Pushing down on me
Pressing down on you no man ask for
Under pressure
The second aspect of what I learned by working on this project was the amount of pressure (and responsibility) I can currently handle. As you may already know, I work a full-time salaried position as an Information Management Officer at First Hawaiian Bank. At this job I manage about nine applications, as well as several databases and workflow processes (both automated and not), as well as being a valued contributor to several other projects falling within my department’s primary responsibility.
The amount of unbridled pressure I have been under the last month has basically zapped, fried, and overloaded my brain. My most prominent application at work is undergoing a conversion to a new platform which has been undergoing a belaboring degree of setbacks. In addition, my department’s holiday party of which I got the luck of being on the planning committee this year was about to take place. This along with the DueDates 2.0 all had deadlines of just days to a week apart.
This resulted in an extreme amount of performance pressure and anxiety to complete all three to the best of my capacity which I was ill-prepared to cope with.
This had a detrimental effect on me and in the end, my ability to keep a certain level of “numbness” out of my ability to think and get the Wicket concepts. The entire experience felt like a log-jam, overload of information and my brain just seized up. And if you take on the role of project manager, either through assertion or organically, then a situation like this can bring a team down. In many respects, I believe this is what happened to DueDates-‘Oma’oma’o being successful.
The Aftermath
I learned over the past few weeks that continuous integration is difficult, especially, when working with a group of developers who have probably been silo-ed for the majority of their projects. Secondly, I learned that continuous integration only works if it’s used. I think our group had a few too many cases of code conflicts, because on occasion code was committed prior to the committer performing an update on their system.
In Reservoir Dogs, Mr. Orange shoots Mr. Blonde moments before he’s about to set the cop, who at this point has been drenched in gasoline, afire. It would appear Mr. Orange has saved the cop’s life, but eventually, the rest of the heist gang arrive and promptly kill the cop…and then, Mr. Orange. The movie ends with everyone lying dead on the floor, either having shot each other or by the cops that have arrived to the scene.
Reservoir Dogs: DueDates 2.0 Edition ends similarly so for DueDates-'Oma'oma'o.
Download your (dysfunctional) copy here.
Reflections
I’m not sure what’s more important…completing a task and learning from that experience, or trying (desperately so) to succeed and still failing and learning from that experience. “It wasn’t for a lack of trying” the saying goes. Software engineering is a process, an inexact one a t that. Not every project comes in on time, budget, or fully meets specs. It’s part of the business…or science…or art…that is software engineering. There’s another saying that can be applied with equal resolve to software engineering…”Hate the [program], not the [programmer].”
There is a scene about an hour in where two of the gang members, Mr. Orange and Mr. Blonde (the members all went by color-name aliases) are holed-up in the after-heist staging area. Mr. Orange with a gut-wound is lying on the floor bleeding out, passed out and near death, while Mr. Blonde begins to torture a cop he happened to take hostage while fleeing the scene of the failed heist.
In Reservoir Dogs: DueDates 2.0 Edition, Mr. Blonde would be Wicket, Mr. Orange would be the DueDates application, and the cop would be my team of developers: Vincent Leung, Creighton Okada, and John Zhou. In this rendition, Mr. Blonde (read Wicket) definitely tortured our project and the team—“Look [programmers], I’m not gonna bull!@#* you. I don’t really give a good !@#* what you know or don’t know. But, I’m gonna torture you anyway. Regardless. Not to get any information. It’s amusing to me…to torture…[programmers].” And what’s a movie without the most appropriate soundtrack, as the torturing begins the radio is playing Stealers Wheel’s Stuck in the Middle With You. Here are the first two verses to set the mood as the rest of the story unravels:
Well I don't know why I came here tonight, I got the feeling that something ain't right,
I'm so scared in case I fall off my chair, And I'm wondering how I'll get down the stairs,
Clowns to the left of me, Jokers to the right, here I am, Stuck in the middle with you.
Yes I'm stuck in the middle with you, And I'm wondering what it is I should do,
It's so hard to keep this smile [on] my face, Losing control, yeah, I'm all over the place,
Clowns to the left of me, Jokers to the right, Here I am, stuck in the middle with you.
Clowns, Jokers, and Stuck in the Middle
Well, let’s clear up just who the “clowns,” “jokers,” and those “stuck in the middle” are…these would all be me and the other members of the team of which Wicket and DueDates pulled strings making us dance like little Marinette dolls. Our team consisted of me, Vincent Leung, Creighton Okada, and John Zhou.
I went into this project with an open-mind of my teammates. Although, I had heard what to expect from each from others, as well as, having read their blogs and looked over their prior DueDates projects, I had hoped that we would be successful at our endeavor to migrate DueDates 1.x to 2.0…or from a console application to that of a web application.
Honestly, I’m not sure what I would have done differently within the group. Each team member performed the tasks that were asked of them. We divided the tasks up, such that we could all work on something working towards the goal of merging our efforts. Creighton and Vince focused on getting the JAXB, XML, and configuration manager operating, while John worked on setting up the sorting method, making the libraries extensible, and cleaning up code. Vince also took on the task of setting up the email function and timer.
Being the sole team member with extensive web development experience (albeit in ASP.NET), I took on the task of the web UI, with the hopes of just “wiring” the rest of the team members’ efforts. In the end, this resulted in being the Achilles’ heel of our project. More on this later…
All team members were responsible for testing and writing documentation (including wikis).
As in the DueDates-Silver implementations, the team met several times (almost daily) throughout the project cycle, however, most of this occurred during the second week. The main issue with first week was the occurrence of Thanksgiving. While my team members celebrated their holiday on the traditional Thursday, my family waited until Saturday to celebrate.
This coupled with getting to know each other and mitigate our schedules really impacted our success during the first week. I don’t really blame anyone for this, as it’s just a matter of Life. We met initially the first day the assignment was given and divvied up tasks with the expectation that our initial tasks would be completed when we met again following the Holiday. This all went as expected with everyone completing their assigned tasks leaving the second week for wiring up the web UI and back-end components.
As mentioned earlier, following this we met at least a couple hours every day the remainder of our allotted project time. During this time, every one worked on their tasks. About the only thing I think we did not do sufficiently was communicate, including me, who had kind of taken on the role of project manager. More on this later…
I don’t know if the Hackystat SICU accurately reflects the entirety of the group’s performance. While I believe it accurately records the time, effort, and productivity of the individual programmers, it has no way of capturing what its sensors aren't designed to record. In this case, I am alluding to the fact that my teammates were doing their parts, but it was really hard for them to do more because they needed to wait for me to complete the wiring of the web UI interface to their back-end components. More on this later…
The Failed-Heist
It’s really difficult to judge, in my opinion, how much of the project we completed. We resolved the back-end implementations for support of an XML configuration file (R1), provided sorting (R4), filtering (R6), and email alerts (R7). The web application had some of the basic functionality (R2) with all the necessary CSS formatting (R3). (Note: There was no R5 in the requirements.) Unfortunately, R2 was the hinge-pin of the system, and I was never able to complete the wiring up of the back-end components. Which frankly, drove me to the point of such frustration…for many reasons…but, most of which had to do with the fact that I develop web applications for a living (not via Wicket). The major issue was I never quite wrapped my mind around property models, at least for listview and dataview “controls”. This in effect, killed our project. Mostly due to the fact that I spent way too much time on trying to get it to work by myself before asking for help…from my teammates and classmates. In many respects, I felt like I was wasting my teammates' time, with little for them to do, while I was tortured by Wicket, and they were held hostage.
So while DueDates 2.0 isn’t a viable production application, all the parts are there…just disconnected…like the body parts of some poor dead soul after an autopsy.
By the time I decided I needed help, there was sufficient time, but even after speaking with Arthur Shum and reviewing DueDates-Akala’s code, and my DueDates-Silver partner Robin Raqueno and reviewing DueDates-Ahinahina’s code, the pieces of the puzzle still remained allusive to me. Much appreciation to both Arthur and Robin for their time, support, and guidance.
Also, there was the issue of working with 3 additional programmers with six requirements in a short time span interrupted by a holiday. The biggest issue here was that I think there were too many moving parts, which proved difficult for me to manage especially under the pressure of a failing web UI implementation and having the capacity to be there to help my teammates with what they were doing when they ran in to issues. But, more importantly to me is being a good, helpful, and responsible team member, so I gladly stepped up each time, even returning the favor of assisting Robin by spending an hour showing him the ins-and-outs of CSS.
Another prominent issue with DueDates-‘Oma’oma’o was it began with an initial loading of DueDates-Silver’s code which eventually got hodgepodged with code from other projects. I think this caused a lot of overhead, which caused the team members to not really understand how the project worked or would work. A top this, most of the group had not worked with XML and JAXB, so this was additional overhead the project suffered from initially as well.
Track Two
If Reservoir Dogs: DueDates 2.0 Edition had another song on its soundtrack it would be Queen’s Under Pressure, which begins:
Pressure! Pushing down on me
Pressing down on you no man ask for
Under pressure
The second aspect of what I learned by working on this project was the amount of pressure (and responsibility) I can currently handle. As you may already know, I work a full-time salaried position as an Information Management Officer at First Hawaiian Bank. At this job I manage about nine applications, as well as several databases and workflow processes (both automated and not), as well as being a valued contributor to several other projects falling within my department’s primary responsibility.
The amount of unbridled pressure I have been under the last month has basically zapped, fried, and overloaded my brain. My most prominent application at work is undergoing a conversion to a new platform which has been undergoing a belaboring degree of setbacks. In addition, my department’s holiday party of which I got the luck of being on the planning committee this year was about to take place. This along with the DueDates 2.0 all had deadlines of just days to a week apart.
This resulted in an extreme amount of performance pressure and anxiety to complete all three to the best of my capacity which I was ill-prepared to cope with.
This had a detrimental effect on me and in the end, my ability to keep a certain level of “numbness” out of my ability to think and get the Wicket concepts. The entire experience felt like a log-jam, overload of information and my brain just seized up. And if you take on the role of project manager, either through assertion or organically, then a situation like this can bring a team down. In many respects, I believe this is what happened to DueDates-‘Oma’oma’o being successful.
The Aftermath
I learned over the past few weeks that continuous integration is difficult, especially, when working with a group of developers who have probably been silo-ed for the majority of their projects. Secondly, I learned that continuous integration only works if it’s used. I think our group had a few too many cases of code conflicts, because on occasion code was committed prior to the committer performing an update on their system.
In Reservoir Dogs, Mr. Orange shoots Mr. Blonde moments before he’s about to set the cop, who at this point has been drenched in gasoline, afire. It would appear Mr. Orange has saved the cop’s life, but eventually, the rest of the heist gang arrive and promptly kill the cop…and then, Mr. Orange. The movie ends with everyone lying dead on the floor, either having shot each other or by the cops that have arrived to the scene.
Reservoir Dogs: DueDates 2.0 Edition ends similarly so for DueDates-'Oma'oma'o.
Download your (dysfunctional) copy here.
Reflections
I’m not sure what’s more important…completing a task and learning from that experience, or trying (desperately so) to succeed and still failing and learning from that experience. “It wasn’t for a lack of trying” the saying goes. Software engineering is a process, an inexact one a t that. Not every project comes in on time, budget, or fully meets specs. It’s part of the business…or science…or art…that is software engineering. There’s another saying that can be applied with equal resolve to software engineering…”Hate the [program], not the [programmer].”
