kcw | journal | 1999 << Previous Page | Next Page >>

Today (September 1st, I need to catch up on my entries) I found out that we've encountered a significant setback in our software project. Apparently, we were assuming we'd get information from another group and their product doesn't actually do what we need from them.

We were expecting them to process some data and summarize it for us, but their product is just an information conduit. It doesn't know anything about the underlying data, so of course they can't look at it to summarize it. Something that I kind of expected from reading their Requirements Document but that others in my group thought different. Not that I'm trying to place any blame, we're a team and we share the good and bad and I should have clarified it myself.

Our project is already quite behind, in my opinion. We received an initial Requirements Document two or three months ago. Our team spent the better part of a month coming up with an architecture that we thought is robust enough to deliver on the capabilities and performance of the RD.

It was a rather complicated architecture, requiring different levels of tables, each summarizing the previous level. This would cut down on the massive data that we're expected to store and it would speed up data access since there is less data. It would make the accessing logic non-trivial and there would have to be processors to summarize the data and clean up the tables continually.

After meeting with our Vice President that architecture was shot down. The VP didn't want such a complicated architecture that would require extra work from Report Writers and would be hard to implement. Both good points. He also wanted the RD to be revised so that it would not be so ambitious; it should be more focused on the immediate problems.

Ok. So our development group and product management spent another month trying to revise the document. We have simplified the architecture into just 2-3 massive tables and hope that our database can handle the load. We've gotten a document that says what we need from other applications, although most other applications go through the Universal Work Queue, which is the problem in the first paragraph.

There are still some philosophies that I have that are a little jarring to the rest of my group. If product management wants something, I'm inclined to say yes -- we'll somehow fit it in to the product. It's up to the Project Lead to say that it would be too much work or unfeasable. There are some things that I think would be trivial to implement that the Project Lead has nixed.

One problem is that Product Management (PM) wants to deliver a competitive product. Not just that, but a superior product than the competition. I can see that and agree. So if PM wants a feature we should provide it. On the other hand, our product doesn't need to be best-of-class. We're counting on a good integration with other products in the company to be the major selling point.

There is still a lot of work to do. I sometimes feel like we are not making any headway. I also feel that my style is not compatible with my Project Lead's style. Frustrations that I can put down in writing, but that I'll otherwise keep to myself. I do believe in putting the team ahead of myself, and so I will deal with this personal problem and try to do my best.

Copyright (c) 1999 Kevin C. Wong
Page Created: August 9, 2004
Page Last Updated: August 9, 2004