Removing hard-coded values and defensive design vs YAGNI

Question

First a bit of background. I'm coding a lookup from Age -> Rate. There are 7 age brackets so the lookup table is 3 columns (From|To|Rate) with 7 rows. The values rarely change - they are legislated rates (first and third columns) that have stayed the same for 3 years. I figured that the easiest way to store this table without hard-coding it is in the database in a global configuration table, as a single text value containing a CSV (so "65,69,0.05,70,74,0.06" is how the 65-69 and 70-74 tiers would be stored). Relatively easy to parse then use.

Then I realised that to implement this I would have to create a new table, a repository to wrap around it, data layer tests for the repo, unit tests around the code that unflattens the CSV into the table, and tests around the lookup itself. The only benefit of all this work is avoiding hard-coding the lookup table.

When talking to the users (who currently use the lookup table directly - by looking at a hard copy) the opinion is pretty much that "the rates never change." Obviously that isn't actually correct - the rates were only created three years ago and in the past things that "never change" have had a habit of changing - so for me to defensively program this I definitely shouldn't store the lookup table in the application.

Except when I think YAGNI. The feature I am implementing doesn't specify that the rates will change. If the rates do change, they will still change so rarely that maintenance isn't even a consideration, and the feature isn't actually critical enough that anything would be affected if there was a delay between the rate change and the updated application.

I've pretty much decided that nothing of value will be lost if I hard-code the lookup, and I'm not too concerned about my approach to this particular feature. My question is, as a professional have I properly justified that decision? Hard-coding values is bad design, but going to the trouble of removing the values from the application seems to violate the YAGNI principle.

EDIT To clarify the question, I'm not concerned about the actual implementation. I'm concerned that I can either do a quick, bad thing, and justify it by saying YAGNI, or I can take a more defensive, high-effort approach, that even in the best case ultimately has low benefits. As a professional programmer does my decision to implement a design that I know is flawed simply come down to a cost/benefit analysis?

EDIT While all the answers were very interesting as I think this comes down to an individual's design choices, I think the best answers were @Corbin's and @E.Z. Hart's as they bring up things that I hadn't considered in the question:

• the false dichotomy of 'correctly removing hard-coded values' by moving it to the database vs 'efficiently applying YAGNI' by using hard-coding. There was a third option of putting the lookup table into the app configuration, which doesn't incur the overhead of the correct way, and without the efficiency of YAGNI. We generally aren't limited to either/or decisions, and it then comes down to a cost/benefit decision.
• code generation can reduce the overhead of moving the hard-coded values to the database, and in a way that also removes my over-engineered decision to process a CSV into the table. Potentially this also adds a long-term maintenance issue with the generated code if the basic requirements change for the lookup method. This all just affects the cost/benefit analysis, and it is likely that if I had had that automation available I wouldn't have even considered hard-coding something like this.

I'm marking @Corbin's answer as correct because it changes my assumptions of development cost, and I'll probably add some code generation tools to my arsenal in the near future.

Answer 1

You found a flaw in your development process. When it's a pain to do the right thing (create the table, repo, repo tests, flatten tests...), developers will find a way around it. This usually involves doing the wrong thing. In this case, it's tempting you to treat application data as application logic. Don't do it. Instead, add useful automations to your development process. We use CodeSmith to generate the boring, boilerplate code no one wants to write. After we create a table, we run CodeSmith and it generates the DAOs, DTOs, and stubs out unit tests for each.

Depending on the technologies you're using, you should have similar options. Many ORM tools will generate models from an existing schema. Rails migrations work in the opposite direction - tables from models. Meta-programming in dynamic languages is particularly strong at eliminating boilerplate code. You'll have to work a little harder to generate everything you need if you have a complex multi-tier application, but it's worth it. Don't let the feeling, "wow, this is a pain in the neck" stop you from doing the right thing.

Oh, and don't store your data in a format that requires additional processing (CSV). That just adds extra steps that require your attention and testing.

Answer 2

To key-off of and extend @Thorbjørn Ravn Andersen's answer: Keeping the calculation/lookup in one place is a good start.

Your thought process of defensive vs. YAGNI is a common problem. In this case, I would suggest it be informed by two more things.

Firstly - how was the user requirement presented? Did they specify editability of rates? If not, is the added complexity part of something you can bill for or not? (or if you are on staff, that you can spend your time doing other work instead ?) If so, then definitely go ahead and deliver what was reasonably asked for.

Secondly, and perhaps more importantly, mere editability is unlikely to fulfill an actual requirement in the face of a legislated change. If and when the rates do change, there is likely to be a cut-over date and some before-and-after processing that has to happen. Furthermore if that same interface has to then do any kind of back-dated claims processing, then the correct rate might have to be looked up based on the effective date of the entry, rather than the actual date.

In short, I'm noting that an actual editable requirement may well be quite complex, so unless or until it is fleshed out, the simple is likely better.

Good Luck

Answer 3

Make the actual lookup a library function. You can then see all the code using that lookup in your source repository, so you know which programs need to be upgraded when the rates change.

Answer 4

Let me see if I got your question right. You have 2 options to implement a feature: either you hardcode a value and your feature is easy to implement (btu you don't like the hardcode part) or you have a very big effort to "redo" a lot of things that are done so you are able to develop you feature in a clean way. Is that correct?

The first thing that comes to my mind is "The most important thing about knowing the good practices is knowing when you are better off without them".

In this case, the effort is very high so you can do it in a clean way, the chances of collateral effect of this change is big and the return you would get is small (as you explained, it seems likely that it won't change).

I would use the hardcode approach (but prepare it to be flexible in the future), and, in case of change of this rate in the future, use the opportunity to refactor all this bad design section of the code. So the time and cost could be estimated correctly and the cost of changing your hardcoded value would be minimal.

This would be my approach :)

Answer 5

This is an item that "won't change" until it does. It's inevitable that it will change, but that time may be a bit far off.

Your justification is correct. At this time, the customer didn't ask for the ability to easily change those rates. As such, YAGNI.

However, what you don't want is the code that accesses your rates and interprets the results scattered throughout the codebase. Good OO design would have you encapsulate the internal representation of your rates in a class, and only expose the one or two methods necessary to use the data.

You are going to need that encapsulation to prevent copy and paste errors, or having to perform a refactoring across all the code that uses the the rates when you need to make a change to the internal representation. When you take that initial precaution, the more complicated approach can be a simple swap and replace for the more featured version.

Additionally, call out the limitation of the current design to the client. Tell them that in the interest of maintaining the schedule you hard coded the values--which requires a coding change to update them. That way, when they become aware of pending rate changes due to new legislation, they can choose to simply update the lookup table or perform the more complicated change at that time. But put that decision in their lap.

Answer 6

Split the difference and put the rate data in a configuration setting. You can use the CSV format you've already got, you avoid the unnecessary database overhead, and if the change ever is necessary, it'll be a change that the customer should be able to make without having to recompile/reinstall and without messing around in the database - they can just edit the configuration file.

Usually when you're looking at a choice between two extremes (violate YAGNI vs. hard-coding dynamic data), the best answer is somewhere in the middle. Beware of false dichotomies.

This assumes all your configuration is in files; if it's somewhere difficult like the registry, you should probably disregard this advice :)

Answer 7

I figured that the easiest way to store this table without hard-coding it is in the database in a global configuration table, as a single text value containing a CSV (so "65,69,0.05,70,74,0.06" is how the 65-69 and 70-74 tiers would be stored.

Just created a DB Table. (You where thinking of storing a whole table in one filed, have you gone mad?)

The table needs 2 fields NOT 3. Age and Rate. This next row contains the upper value! You are de-normalizing without even knowing it!

Here is the Sql to get the rate for someone of age who is 67.

Select * from RateTable where Age in (Select max(age) from RateTable where age <=67) 

Don't bother to make a maintenance screen as it's out of scope. If they ask for it later, issue a change request and do it.

EDIT: As others have said keep the code the gets the rate centralized, in case the whole Rate structure chages.

Answer 8

Hard code in a function.

• When values change, you can bill the customer again
• When the values change, chances are the table format will have to change, doing CSV will waste time
• Easier to implement, higher chances of being on budget with current contract
• Can find easily when it will need to be updated

Answer 9

I agree with most of the answers given. I'd also add that consistency with the rest of the application is important. If this is the only place in the code that has hard-coded values it will probably surprise maintainers. This is especially true if it's a large, stable code base. If it's a small program maintained by you the decision is less important.

I have a distant memory of reading a well known agile/OOP guy (like Dave Thomas or Kent Beck or someone) saying that their rule of thumb for code duplication was twice and only twice: don't refactor the first time you duplicate something since you might only ever write it twice in your life. But the third time...

That doesn't exactly address the question, since you're questioning YAGNI but I think it speaks to the general flexibility of the agile rules. The point of agile is to adapt to the situation and move forward.