Chareth was a junior developer, and he wasn't happy about it. Every task that was assigned him from a senior developer was like another dagger made of salt and lemon juice being jabbed into his heart and exploding. The tasks were insulting, too — increase a font size here, add a "sign out" link there — child's play for a guru developer in junior developer's clothing like Chareth.

When Yuriy assigned Chareth a relatively simple task, he didn't expect much trouble. Chareth was to build a simple stored procedure that could calulate sales tax based on state, order total, and zip code. He turned in his first attempt for code review, and promptly failed — too much extraneous code where a much simpler and easier to maintain solution would work. He turned in his second attempt, and along with it a paragraph defending the code from his first try. His code didn't pass muster this time, either.

On Chareth's third attempt, it was clear that he was getting agitated. Yuriy didn't want to make Chareth feel any worse, so he did his best to gently tell him that he failed again, this time writing his own solution and pointing out what he had done differently to make it simpler.

It didn't take him long to hear back. Chareth was convinced that Yuriy's solution sucked, and having tried to work with Yuriy on it knew of only one better way to get his point across — he was going to tell!

The email that Chareth sent to Yuriy and CC'd to Yuriy's boss said:

Hi Yuriy,

I checked the datatypes of the fields like state, zipcode, SubTotal, 
Tax in AX and compared them with the dataypes in the GetTax SP. There 
is a slight loss of precision in some cases.

I am listing them down:

1) State - for example is of datatype nvarchar(10) in AX. In the Sp 
   however it is of char(2). Please note that existing data has many 
   states like ACT, NSW, QLD etc which are all 3 characters. 

2) Zipcode - exact match. No issue. 

3) Subtotal - It is numeric(28,12). The data type used in the SP Money 
   is having a slightly lesser precision.(-922,337,203,685,477.5808 to 
   +922,337,203,685,477.5807 which means something like numeric(15,4)) 

4) Tax - is numeric(28,12)

It is better to change the datatypes to match the ones in AX as this would 
save us from any maintenance efforts in the future arising due to addition 
of more characters in any of the fields.

Please let me know if there are any issues/clarifications.

Thanks & Regards,
Chareth

Chareth had avoided one of the common traps when trying to get someone else in trouble — he didn't sound like an angry jerk. But now it was on Yuriy to respond and explain why he'd designed GetTax that way, including a CC to his boss. Before he finished typing his response, though, a new message appeared from Yuriy's boss:


1) The US doesn’t have any three character states and we’re not planning 
   on annexing any states anytime soon. 

2) Good to hear. 

3) This can be left the way it is, if we get an order with a subtotal of 
   octillion dollars then we’ll just make sure to discount it by sextillion 
   dollars thereby getting us down to our precision number of 922 trillion dollars

4) This will be useful for the prior order if we ever receive it. 

We won’t be changing any data types.

It seems as though Chareth is the only one on the team that knows the cardinal rule of determining column sizes: try to imagine the highest reasonable value that will ever appear in it, and then add that many orders of magnitude.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!