Talked to a friend of mine who worked for Microsoft few years back and the "4 testers per 1 developer" was all the rage. Code now, ship tomorrow, design next month. Obviously one of the tradeoffs. It worked wonders for the business, but engineering-wise the output is an utter crap. I spent few years writing kernel-level stuff for Windows and Linux, and the difference in quality is absolutely staggering.
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").
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).
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.
Talked to a friend of mine who worked for Microsoft few years back and the "4 testers per 1 developer" was all the rage. Code now, ship tomorrow, design next month. Obviously one of the tradeoffs. It worked wonders for the business, but engineering-wise the output is an utter crap. I spent few years writing kernel-level stuff for Windows and Linux, and the difference in quality is absolutely staggering.