Elegant vs Quick

[ckrusen (Calvin Krusen)]

This is a continuation/ resurrection of

STOP IT! (Rant warning here!) "Hard Coding vs Data Driven"

Warning… I am going on a little rant here… wanting to correct bad practices that are continually put into place by various programmers, system “designers” and users. Situation: Customer “Walmart” has special rule for order entry that says “Lead Time = 3 days for all standard products”. So… the user asks for BPM that looks for Walmart Customer ID (problem 1) to enforce the 3 day rule (problem 2) for all “standard products” (problem 3). Programmer’s “solution”: they write a BPM that looks fo…

Yes, hardcoding has its downfalls, and data driven solutions are more elegant and often(but not always) more extensible.

But a sufficiently documented “quick and dirty” hardcoded solution could be acceptable, and less prone to feature creep.

Take the request to limit a part to a specific customer.

The elegant solution would require adding a UD field to part table to hold the CustNum, Regen of the DB, a BAQ to find the CustNum for a given CustID, a customization of Part Maint to allow selecting the Customer, a BPM to halt saving a line with an invalid part / customer combo, training whomever is going to maintain that field in Part Maint, trainingng order entry what the exception message they’ll see means, etc…

The quick and dirty is to make the BPM that stops saving a line based on the hard coded combo of partnum and custnum, training order entry about the exception message they may see.

The obvious argument for the elegant solution is that someone else can now set the specific customer for any given part. As opposed to development having to tweak the BPM when a new partnum/customer combo is needed.

But that elegant solution has some obvious limits. Ones that require an entirely new solution. More than just a revision of the original one.

The example that comes to mind is when the powers that be decide there needs to be more than one customer that can buy that part. Might be the same customer, just one that is implemented as multiple customer entries. Or maybe that customer wants you to sell direct to certain distributors of theirs. Now your solution needs to be torn down an implemented in a manor with a one-to-many relationship (I.e. a UD table with partnum and custnum as pairs of keys)

The hardcoded solution merely requires a tweak of of the condition widget - adding another row, setting AND/OR and parentheses.

I’d say it is acceptable to do the quick(and dirty) method if the request is, “Make it so that P/N ABC-123 can only be sold to ACME Corp”

Now if the request included, “… And we’ll want to be able to do this for other parts too.”. Then the elegant solution would be more appropriate. But don’t forget to ask if they might ever want to restrict the part to more than one customer.

Now let your hate flow through me.

[zwilli526 (Zack Williams)]

I’d argue you’re solving for 2 different problems. Making a part customer specific is different than limiting a part to multiple customers.

Option A is still a fully formed solution. How to make a part specific yo 1 customer.

If option B become a necessary design a new solution. Limit part to group of customers.

In this particular example l, an elegant solution would would allow allow for infinite combinations of part/customer and the BPM would never need to be touched again.

Often time the difference between elegant and dirty is minimal. 2 hours of front end dev time is worth 20 hours of troubleshooting and break/fix down the line.

[klincecum (Kevin Lincecum)]

On a more serious note. I believe either is fine, as long as it is well documented,
easy to find, and easy to understand.

[timshuwy (Tim Shoemaker)]

as the original poster of the the post, i guess I should comment…
Note that I personally HAVE done the shortcut approach “option 2”… but typically if it is a one-off special situation.
So, I guess I agree with you there.
In the original post, the person who created the original BPM did the hard coding technique… but as they did it, the hard coded option had so many “if thens” burried into the code, it made their solution very difficult to maintain… they started adding more and more customers, and lead times, and exceptions. When I got the request to add one more customer, I determined that it was a fairly easy fix to simply add a ud field and create a very simple BPM to do the calculation rather than all the complex code.

[ckrusen (Calvin Krusen)]

This is kind of my point. Solve the current problem with only moderate considerations for future needs. There may eventually be a time when the Q&D solution is no longer satisfactory. Most often because the original need changed (from: part ‘XYZ’ can only be sold to cust ‘ABC’, to: a user specified part can only be sold to a user specified customer).

Probably one thin I kind of gloosed over was the visibility of imementation. In the customer restricted part example, the end action of stopping the line save would be presented to the user.

In contrast to a solution like hiding a specific ShipVia by tweaking the WhereClause in the GetList method. Someone could see the ShipVia in ShipVia Maintenance, but not know why it doesn’t show in order entry. Unless the person that implemented the BPM was still with the company, or clearly documented it (not likely), someone could spend a lot of time hunting that down.