I’m in the middle of the implementation phase of my project. The last week or so was mostly planning out the scope of the application, which ended up being a lot of waiting. Do they want to be able to X in the application? Hmm, not sure, lets ask them. An hour or two later, I’d have my answer and I could move on to the next design question. A few religious debates later (including one where I was arguing against CodingHorror) we were settled on the design and implementation strategy. The application is nothing fancy; a simple insurance underwriter system, Web based, written in ASP.NET 2.0. The biggest cool factor to the whole thing is that we’re using the ASP.NET AJAX extensions. UpdatePanels are pretty rock.
The specification process wasn’t anything special. Whoever wrote Software Requirements from Microsoft Press (which Google later reveled to be Karl E. Weigers), would be appalled. I’ve never met the customer, and my only method of contact is through my manager. Not exactly joint application development. The spec is penned out in pseudo-use-case-UML and stickypadded to the cabinets in my office. We have an ER diagram, but that’s by my own hand alone. I’m essentially developing a program off what’s in my head, a single ERD, and two Self-Stick Easel Pads. Ah, this is my welcome to enterprise development.
Either way, the program is getting written. Today I started slogging through my Data Access Objects now, which ain’t `zactly fun. I like to imagine LINQ. just sitting on my shoulder, taunting it’s super-cool in-lining abilities I can’t use. Over the course of forty plus table attributes, my wrists started hurting. The wonderful advice I’ve received about taking breaks while working is finally making sense. At 2:02PM, I decided it was break time.
After waiting for the Coke machine to timeout on my credit card authorization, I took a walk around the building. You know, just to wring out my fingers and to hope the Coke would work next time I tried. Then it hit me. There was a problem in our software design that would cause the customer to do horrendous amounts of data entry, along the line of 6,600 records. I stopped in the hallway and thought about it for a second. One of the reasons we were developing this software in the first place was to automate this kind of thing. Surely we (read: I, in this case) couldn’t have overlooked this fact? I jogged back to my office, checked the ERD, and went into an instantaneous depression.
Yep, it was flawed. The customer would have to enter 6,600 records (granted, with one column each) upon delivery of our product. My development efforts ceased and all my energy refocused on eliminating this problem. Two hours later, I had nothing to show for it but a lot of failed ideas. Somewhere during that time the someone-just-broke-up-with-me feeling hit. The product wouldn’t work as promised. It wasn't time for the We're Doomed speech yet, but I was planning it. I started discussing it with a co-worker, who had just come back after house-shopping.
Bottom line: it’s the customer’s problem to do data entry, not ours. After an hour long discussion, we decided that the problem was domain specific and, sadly, irresolvable using our techniques. I would continue to develop as plan, and just try not to think about the poor administrative assistant that was going to have to do data entry. The problem was solved, but I was still fairly shook from the ‘oh ***’ moment earlier that day. I typed up a few more methods then headed home. Apparently software can’t solve all of our business problems. Maybe I was just being naïve about it, but I was hoping that this product would really reduce all the tediousness of the customer’s current tasks. It will, but there will be a high initial time investment. Today I learned that design is about compromise.
Print | posted on Wednesday, May 23, 2007 12:58 AM