Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I write software that involves the use of measured quantities, many input by the user, most displayed, that are fed into calculation models to simulate various physical thing-a-majigs.

We have created a data type that allows us to associate a numeric value with a unit, we call these "quantities" (big duh). Quantities and units are unique to dimension. You can't attach kilogram to a length for example. Math on quantities does automatic unit conversion to SI and the type is dimension safe (you can't assign a weight to a pressure for example).

Custom UI components have been developed that display the value and its unit and/or allow the user to edit them. Dimensionless quantities, having no units, are a single, custom case implemented within the system.

There's a set of related quantities such that our target audience apparently uses them interchangeably. The quantities are used in special units that embed the conversion factors for the related quantity dimensions...in other words, when using these units converting from one to another simply involves multiplying the value by 1 to the dimensional difference. However, conversion to/from the calculation system (SI) still involves these factors. One of these related quantities is a dimensionless one that represents a ratio.

I simply can't get the "customer" to recognize the necessity of distinguishing these values and their use. They've picked one and want to use it everywhere, customizing the way we deal with it in special places. In this case they've picked one of the dimensions that has a unit...BUT, they don't want there to be a unit (GRR!!!). This of course is causing us to implement these special overrides for our UI elements and such. That of course is often times forgotten and worse...after a couple months everyone forgets why it was necessary and why we're using this dimensional value, calling it the wrong thing, and disabling the unit.

I could just ignore the "customer" and implement the type as the dimensionless quantity, which makes most sense. However, that leaves the team responsible for figuring it out when they've given us a formula using one of the other quantities. We have to not only figure out that it's happening, we have to decide what to do. This isn't a trivial deal.

The other option is just to say to hell with it, do it the customer's way, and let it waste continued time and effort because it's just downright confusing as hell. However, I can't count the amount of times someone has said, "Why is this being done this way, it makes no sense at all," and the team goes off the deep end trying to figure it out.

What would you do?

Currently I'm still attempting to convince them that even if they use terms interchangeably, we at the least can't do that within the product discussion. Don't have high hopes though.

share|improve this question
4  
I'd say stop coding and really, really try to settle this. Capture the requirements well and agree on something with your customer on paper. Then continue working on it. –  Sergio Mar 2 '11 at 19:03
    
Oh man, I've been there. The best part is 4 years from now they'll come back to you pissed off that their data is a mess! Keep your email trail. –  GrandmasterB Mar 2 '11 at 19:17
1  
In your customer's defense, there are some very well-known ratios that have no dimension. See en.wikipedia.org/wiki/Reynolds_number and en.wikipedia.org/wiki/Power_number for two of them. As en.wikipedia.org/wiki/Dimensionless_number points out, frequently people give them a unit so that you remember what the number actually means. But it remains dimensionless. –  btilly Mar 2 '11 at 19:17
    
@Sergio - make your comment an answer and I will upvote it. –  mouviciel Mar 2 '11 at 19:17
    
@mouviciel: Ok then, submtited it as an answer. –  Sergio Mar 2 '11 at 19:18

6 Answers 6

up vote 12 down vote accepted

I'd say stop coding and really, really try to settle this. Capture the requirements well and agree on something with your customer on paper. Then continue working on it.

share|improve this answer
1  
I can't stress this enough, on paper. –  Sergio Mar 2 '11 at 19:25
    
Then once it is on paper take the time to document it in the application. Maybe with help on screen that they can understand. –  Amy Patterson Mar 2 '11 at 19:42
    
+1 for design document. –  zzzzBov Mar 2 '11 at 20:07
1  
It's what I did and it all worked out. –  Crazy Eddie Mar 3 '11 at 0:10

There's a set of related quantities such that our target audience apparently uses them interchangeably.

What would I suggest? Stop and talk.

This is a perfect example of your target users using your application in a way you didn't anticipate.

You need to understand why they use these terms interchangeably. Have you used a sludge hammer on a thumbtack, or is your target audience oversimplifying something.

Before you can come up with a solution though, you need to understand why it's a problem. More code might not be the best way to go.

share|improve this answer

I think you do need to educate the customer, some things just can't be done without it causing complains and plain wrong results in the long end. Those things are difficult, but usually explaining works best when you try to mainly ask questions that help someone find the problems. For example, try to come up with an actual (if fictional) example where things would lead to ambiguous, conflicting or wrong results, and ask the customer how to deal when that happens. Usually, talking through examples and listening (really, the key to get people to understand something is to listen to them and try to know what they are coming from.)

If you really can't avoid coding it in, then I would try to hide the unit as late as possible, and also write up that you cannot be held accountable for problems caused by that decision in the long end. Then wait for a business case where the decision of the customer led to wrong results, and still try to educate them, but now with real world examples.

And keep your patience. Don't get too frustrated - even when you really, really know you're right.

share|improve this answer

I'm not expert on the actual content of the problem, but you could try including the customer or major stakeholder in a meeting and let them ask/answer questions of your team.

Getting the customer involved firsthand might spur some serious thought and perhaps lean them in favor of your own proposal.

share|improve this answer

Ya im going to have to agree with the rest here and just stop and talk to them. and even when they decide "oh this is what I want" i'd wait a few days to see if they change their mind.

Customers are a strange breed indeed... hey that rhymes!

share|improve this answer

Don't even start working, until everyone is 100% on same page, as to the exact requirements, then once you are clear, as to what they want and why (really important). Then you can take the time to explain some of the pro's and con's to implementing or the choices they made.

Or if you feel they just not good at making wise choices, decline them as a customer, and move on..

But you'll find that it is rare that a customer/client has a clue.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.