Dec 3, 2012

Hardcode the descriptions

So... today I got an interesting email. Basically I was asking to the stakeholder if a business logic check could be done adding a specific parameter to a domain model instead of hardcoding items ID in the code. I got this redacted answer:

The user is from the marketing division and has no idea on how to determine this parameter. I don't think hardcoding IDs is a good idea: they are generated and that could cause problems moving from test to production. I think it's better to hardcode the descriptions.
Yes. Hardcode the description. The application has also the feature to edit the items. So what happens if the marketing guy edit an item description? you get it? The best has yet to come. I objected that the "link" between the code would be easly broken by another feature of the application that allow to edit the description. The architect than suggested to add another column with a copy of the actual description and use that value to hardcode. I overcame my horror and pointed out that that way every time a new record is inserted we have to modify and redeploy the application. So, after a few days of silence, the specs for the business logic checks changed. Developing the new checks I discovered that they were already in place! So I digg in the customer email and had a look to the original issue and guess what... the new specs do not solve the issue.

This is not a rant against enterprise lack of organization, or good application design. It's a rant against lack of care. Care for good code , of professionalism. Since I want to keep this stuff public. I should stop here.

No comments: