Please Note: this is an older post I found in my archives. Originally dated August 13.
Another blog reply, this time to a devlicious blog post by Derek Whitaker.
re-creating massive amounts of code is expensive and time consuming
Umm... no. If codegen is expensive or time-consuming, you're doing it wrong. If members of the team have a difficult time using code, you're doing something wrong.
You're simply attributing the problems to the wrong source. Godegen is clearly not the issue here. The issue is implementation and training.
So you come up with this as a substitute:
Code you create now, but do not have a direct, immediate need for NOW is waste.
But the NOW timeline is really short-sighted.
Here's a classic. We've rigged our generated entity code to have special handling on any columns named "CreatedDate" and "ModifiedDate". Of course, lots of the primary entity tables we created simply didn't have these columns.
Now, to start with, we don't have a reporting interface or any business logic associated with these columns, so according to your logic adding these columns (i.e.: adding code) is a waste. And of course, that continues to be true until a problem arises that is solved by having these columns (except that they don't exist). I can't now go back and add these columns and suddenly get the data, but hey at least I didn't waste any time, right?
The problem with only handling immediate needs is that it opens the door to ignoring common failures.
Take my example. I know from experience that having these columns on specific tables will be useful. Maybe not now, but definitely soon. And we're not talking about full table-auditing, just a couple columns. We can get that information for a time usage so small that it's basically free and you're telling me that it's a waste because we're not going to use those columns now?
As always, good judgment and experience must be applied when making decisions about what code and features to build. I've spent a lot of time "paying for" mistakes that were wrought from the "we don't need it now" mentality.
In the case of our two dates (Created and Modified), we had to fight through support issues that relied on the non-existent data. A year ago, our product didn't have a support team, so nobody put them in, we didn't need them NOW. That cost us time and money for what should've been a "free" feature.
Turns out we'll likely need a full change history on a couple of the tables.. That's fine, we can't get that "for free", so it's OK that we didn't "waste time".
And what about features that don't get used? If I build 5 features and only 1 gets used, is that waste? Technically it is, but realistically, not every feature is going to be a hit. In fact, it's generally acknowledged that failures are a very important component of success. Maybe it just takes the implementation of 5 features to find one that "sticks", all of that "unused code" may be a "success" in some people's book.
I think you can get my point here, waste is not as simple as defining code that does or does not get used. You also have to factor opportunity costs for the code that is written and the "timing of the time". Hours are not equal, the hour when your datacenter is down has a very different value than the hour I spent writing this post.
Calling unused code the "Worst of the wastes" is difficult to swallow without a little deeper comparative analysis. But given the difficulty of even analyzing the value of unused code, I think you'd be in for a challenge there.
No comments:
Post a Comment