4 ms·

I have to take umbrage at this style of engineering. Yes having the extra copy of notepad is easy and practical, but it ignores the fundamental principle that

I have to take umbrage at this style of engineering. Yes having the extra copy of notepad is easy and practical, but it ignores the fundamental principle that doing it the right way is going to have a return down the road. An opportunity cost in having the capacity for hard links in all of those software components is taken, the utility of hard links to users in other domains not related to the single scenario can never be realized, and you've established momentum for taking the easy way out the next time the problem comes up ("Ehhh, well, we just added another copy of notepad, let's just add another copy of this dll, and this config file, and this, and that, and the other thing").

ryanwaggoner 18y ago
I guess it depends on your objective. If you want to create a lean, well-engineered architecture where things are always done the correct way, you take your approach. If you want to build a multi-national company worth $170 billion, you go their route. Yes, that's a fallacy, because it's not an either/or decision, but my point is that engineering supports the business objectives, not the other way around (assuming we're talking about a business).
- jsdalton 18y ago
  There was a discussion here last week about technical debt, and I think this is a great example of it. You incur debt when you make a decision like this one. When you make thousands of decisions like it, they add up to a whole lot of debt. The problem is that this debt is nearly impossible to quantify, so it's often invisible to the business team. A decision like keeping two copies of Notebook around thus seems like the correct decision to the business team at the time, but later proves to cost a lot more down the road. So while it's true that engineering supports business objectives at the macro level, a pure "business" mindset at the micro level can lead to short-sighted and ultimately costly decisions like this one.

ryanwaggoner 18y ago

I guess it depends on your objective. If you want to create a lean, well-engineered architecture where things are always done the correct way, you take your approach. If you want to build a multi-national company worth $170 billion, you go their route. Yes, that's a fallacy, because it's not an either/or decision, but my point is that engineering supports the business objectives, not the other way around (assuming we're talking about a business).

jsdalton 18y ago
There was a discussion here last week about technical debt, and I think this is a great example of it. You incur debt when you make a decision like this one. When you make thousands of decisions like it, they add up to a whole lot of debt. The problem is that this debt is nearly impossible to quantify, so it's often invisible to the business team. A decision like keeping two copies of Notebook around thus seems like the correct decision to the business team at the time, but later proves to cost a lot more down the road. So while it's true that engineering supports business objectives at the macro level, a pure "business" mindset at the micro level can lead to short-sighted and ultimately costly decisions like this one.