The setup:
Winform/ASP.NET MVC projects.
Learning NHibernate
SQL-Server driven apps
I work with clients that have no idea how to model an application. That’s what I’m for. However, we have lots of conflicts with validation, mis-understandings, etc.
For example, the client will ask for an order entry screen. The screen should require a “product”. That’s fine and dandy. However, the client didn’t know to tell me that the user can’t order a product of “Class A” unless it’s Tuesday.
Or, they need a time entry screen. 2 days before it’s rolled into production, they casually forgot to mention that certain activities are only valid for certain situations. These situations being a week of coding.
That’s of course, some crude examples (not by much!). But the problem is getting these non-technical clients to layout their business logic. They somehow didn’t realize that the “Class A” problem would come up two weeks later, etc.
I’m all for agile programming but is there an easy way to somehow make business logic like this extremely easy to implement and change on almost a daily basis?
I of course am splitting the project into hopefully intelligent pieces, using NHibernate, etc. But making this BI logic so dynamic is really making it hard to project timelines, etc.
Any suggestions? I know there will never be a perfect client (or a perfect provider) but how do you guys deal with the constant mis-understandings?
Thanks.
The problem is that the customer can always come up with some completely left-field ideas. “Oh, If the customer orders a Class A product on Tuesday, and it happens to be their birthday, give them a 50% discount and a free Class B product. And notify the Chairman to give them a phone call.”
You CAN’T program for all eventualities. If you do plan to build a super-duper rules engine for business logic, it should be because your system is going to be widely deployed and needs to be customized by the customers. Not because your customers don’t know what they want – in that case you’d be building a system to anticipate customer requirements, not a system to order products (or whatever it’s main purpose is).
Maybe I’m old-fashioned, or maybe it because I’ve had just too many bad experiences, but I’m not at all interested in agile development. How do you know what direction to travel unless you know where you want to go? For anything more than a small, single function trivial application, I (roughly) follow an iterative Waterfall method, keeping the cycles small. Make sure that you have a complete document of everything that the system will do. Once the client has signed-off on it, that’s what they’re getting. If they have any changes, they all go into “Version 2” which will be started after Version 1 is deployed into production. A little irritating for them, but in the end everyone is a lot happier.
Yes, there are always exceptions, like when the management need a data-entry system in 2 days. But then make it clear that if they add any requirements as you go, they’re automatically granting you as much extra time as you need to implement them.