[eluser]BrianDHall[/eluser]
[quote author="n0xie" date="1262109120"]
Now if your client changes the business rules/business logic 80% in the project you do have a problem. This is were you should have your contracts and agreements in place to shield you from this. If you hire a painter to paint your house, you don't expect him to redo everything if he is 80% done, just because you decide that 'pink' would look rather dashing instead of the white you chose before.[/quote]
This is actually where I get hit, because my big projects are not on contract, they are as a member of staff. Perhaps my advice is terrible in any other situation, but I find that the reason is precisely the logic and the relationship of data.
As an example on my last project, the system was planned and drawn up and written out to be Create Listing -> Enter Info -> Add Pictures -> Confirm/Purchase. Easy.
It ended up being Create Listing -> Create Account -> Enter Info -> Add Pictures -> Preview/Select options -> Add to Cart -> Purchase, and then a Purchase could be Active, or Paused or Stopped for various reasons, and then it became Active or Stopped, and then it just became Balance > 0 or Balance <= 0. Listings could be stopped early with partial refund...but not in actual money, just account credit.
Then came in the issue that if someone adjusted a listing's options, it might cost more and cause an account issue with other projects, so Listings needed to have their own cash balance and then there would be account credits, and it all had to be itemizable in credit card receipts we didn't control the generation of for various accounting requirements of large companies.
So I guess the problem is my job isn't to build a site, but rather to build something and then develop it through initial launch.
All these changes weren't the result of bad planning, but rather to discoveries once things could be showed to potential customers, clients, business partners, and once the owner could sit down and work through the application "pretending" to be a potential customer, plus various people's family members.
Much of that could have been done without writing nearly any business logic or even drawing up a database schema diagram.
So maybe it's just my early contact with the initial raw idea, as my job usually begins with an idea a few people have done enough fleshing out of to start paying me, but that's it.
So I guess my perspective is that while my job really is to code logic and design information flow and all these really cool engineering things that not just anyone can even understand much less do...the problem is trying to build It when what It is changes every time a new perspective is received.
The thing is, I don't really mind this, it's really just a part of the "Planning" stage I suppose before a project is really even officially started, but the problem is that I dislike building a perfectly good program only to have to rip it all up because the specifications changed. Then I'm stuck with systems I spent weeks on that were not designed for the purpose I now have for them, and I neither want to start over nor does it feel like it would take less time - but then the pains of retrofitting. Rework just isn't much fun.
It's one thing if a feature was just added, but when it breaks prior assumptions as to how data should be structured...ugh.
So my working theory is to do any work FIRST that would be the most likely to cause people to change their minds. So create a fake checkout system, and see what they say - not enough options, they feel? They want to accept offline payments now? Too many options, too many steps?
With this work done I find that a much clearer picture of the final desired app is created, and then with the What It Is clearly in mind I can do the real work - making It happen.
