Is this what the users want?
"Remy," they say, "we've got an application for you to design. Here's the specs."
The application they want is a pretty straightforward data pump application. Like 90% of what my company needs, it involves picking up records from one place and putting them down someplace else. In this case, the data in question represents item information and it comes from the health and safety database and goes to our production processing database.
At first glance, things like this seem like they should be simple, but in practice, they never are. I started asking questions- "Hey, these different types of data you need moved, are there any dependencies between them?"
"Oh, no. Nope. Definitely not."
Well, actually, yes, yes there are. The base record, the item, is supposed to be created inactive, according to the spec, but all of the other data we're moving- technical parameters, formulas, etc. require the underlying item to be active.
Which means, when somebody makes changes in the health and safety database, there's no guarantee the majority of those changes will ever make it over to the production process database, since we can't process half that data until somebody flips a switch in the production process database.
At this point, I make the natural suggestion: "Maybe we should go back to the user's requirements and work from there."
"There are no user requirements," I'm told. Instead, the analyst working on this project reverse engineered the process by looking at some existing code. Code that does a similar role (pulling from a different health and safety database to populate the production processing one), in a process that's being replaced by the one we're building.
Today, days after I had a milestone to finish my technical design, the analysts send an email to a user, "Hey, how do you guys want this to work?"
When I gave my estimate for this project, I was pretty generous. And this is why. Because "just make it work like the old thing" is not a valid set of requirements. The "old thing" has a bunch of assumptions buried in its code built around how the old systems behave. Assumptions that may no longer be valid. Every IT project should be built around what the users actually need.
The application they want is a pretty straightforward data pump application. Like 90% of what my company needs, it involves picking up records from one place and putting them down someplace else. In this case, the data in question represents item information and it comes from the health and safety database and goes to our production processing database.
At first glance, things like this seem like they should be simple, but in practice, they never are. I started asking questions- "Hey, these different types of data you need moved, are there any dependencies between them?"
"Oh, no. Nope. Definitely not."
Well, actually, yes, yes there are. The base record, the item, is supposed to be created inactive, according to the spec, but all of the other data we're moving- technical parameters, formulas, etc. require the underlying item to be active.
Which means, when somebody makes changes in the health and safety database, there's no guarantee the majority of those changes will ever make it over to the production process database, since we can't process half that data until somebody flips a switch in the production process database.
At this point, I make the natural suggestion: "Maybe we should go back to the user's requirements and work from there."
"There are no user requirements," I'm told. Instead, the analyst working on this project reverse engineered the process by looking at some existing code. Code that does a similar role (pulling from a different health and safety database to populate the production processing one), in a process that's being replaced by the one we're building.
Today, days after I had a milestone to finish my technical design, the analysts send an email to a user, "Hey, how do you guys want this to work?"
When I gave my estimate for this project, I was pretty generous. And this is why. Because "just make it work like the old thing" is not a valid set of requirements. The "old thing" has a bunch of assumptions buried in its code built around how the old systems behave. Assumptions that may no longer be valid. Every IT project should be built around what the users actually need.