
Engineering is about tradeoffs: How hard will you work to save 68KB of disk space? - nreece
http://blogs.msdn.com/oldnewthing/archive/2009/03/12/9471146.aspx
======
huhtenberg
Yeah, yeah. I hear ya.

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.

------
DannoHung
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
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
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.

