From an overall social welfare pesrpective, there is something to be said for going above and beyond the customer's minimum standard. Indeed, most of the work that goes on at big companies is of this type (it's no coincidence that the original author works on the compiler team at Microsoft). Just understand the context in which you work - if the company is going to go under with its current customer base, it's irresponsible to focus on things that are not going to get more customers - and that it can be hard to measure the effectiveness of work that doesn't directly lead to new sales.
So do you want to say that MSFT should invest less energy in speeding up the code they produce, because it won't get them more customers or more money?
As a user, of course I want Microsoft to invest more in speeding up their products. I also want them to be easier to use, and have all the features that I want, and cost less, and release more frequently.
As an engineer, yes, I do want them to invest more in speeding up products. Performance tuning is fun, it's an extra skill that can go on my resume, and it helps me take pride in my work.
As a shareholder, hell no are you going to indulge those prima donna engineers and their perfectionist tendencies. I invested in this company to get a return on my investment, and that means more revenue. It's clear that shaving CPU cycles isn't going to get more customers; Windows has been dog-slow compared to competitors ever since the Amiga came out, and it hasn't hurt us so far. That effort would be better invested in getting into new lines of business and building more solutions to capture the enterprise market.
As an executive - it's a complicated question. I want our products to be faster, but it's also clear that our customers want them to be easier to use, and have a lot more features, and cost less, and release more frequently. All of those are in conflict with writing performant code with a fixed number of highly-trained engineers. And if I hire more engineers, the code often gets slower, as global optimization opportunities get lost in the communication gaps between workers. OTOH, performance often has intangible benefits in brand loyalty, in increased usage, in word-of-mouth, and in PR. I'd love to be able to quantify these benefits and trade them off against each other, but the point of intangibles is that they are intangible. I'm responsible to shareholders, however, and my gut feeling is that increased performance will not be the deciding factor for most customers.
(As just plain old me, the question is completely academic: I am neither a user, employee, executive, or shareholder of Microsoft, so I don't really care what they do.)
And tangentially, I still wonder why MSFT thinks that forcing Windows 10 down the throat of the existing users can be considered something that will "get them more customers" if that should be the ultimate goal of the company.
It's not that all issues are preventable. It's that you can prevent a lot of them with just a little extra work up front.
It's a misuse of Knuth's original point, which has much more to do with how brittle and incomprehensible "optimized" code can become.
The programming language affects a lot the criterion. Some are known to be "correct" (like Haskell), others "fast" (like C) ...
Given an infinite amount of time, I suppose the three can be reached in any language.
Unfortunately looking further than the end of the next sprint is disallowed in a lot of people's minds. It's pretty sad that a lot of software "engineers" actively avoid any kind of engineering.
Premature architecture is a code smell. Putting in scaffolding for later is a code smell.
However, I admire your ability to write code without any forethought now that can be used perfectly in whatever form it will be needed later.
I dispute that that is true. They may have a vague idea of a goal, but that's not applicable at the code level in general.
> Based on that knowledge you can make reasonable decisions and trade-offs now.
We aren't talking about making decisions, we're talking about stubbing out code for future needs, an entirely different thing. Nothing wrong with making reasonable decisions, but there is something wrong with stubbing out code you don't need because you think you'll need it later; if you need it later, add it later. It'll cost the same as adding it now. If you think it's going to cost more later, then revisit your architecture because it shouldn't. The implicit argument for adding it now is that's it's cheaper to add now than later, I'm saying that's nearly always a bunk argument.
> However, I admire your ability to write code without any forethought now that can be used perfectly in whatever form it will be needed later.
That's not what I said; the cost of change should be the same later as now. That doesn't mean you won't have to make a change, it just means it shouldn't be harder to add later than to add now.
I was talking about decisions and not writing code and was pretty clear about that.
> That could mean a simple API wrapper that can later on be optimized
That's code. That's what I'm responding to, you insulted those who believe in not writing code before it's necessary, called them sad, and now you want to deny the very thing being replied to? Really? Forget it, you don't know how to discuss something.
That's patently false in any code I've seen; and saying "well make it so, can't be so hard" is just proof by handwaving.
It's new code, so you can absolutely write it without extra scaffolding for "shit you might need later". If you don't need it now, you don't need it yet.
If you want performance, you have to design for performance, not just build the first thing that comes to mind and try to optimize it later.
Most of the time, the answer is "Too much, not worth it". Some of the time the answer is "Let's do it". Knowing which situation you are in is key.
Ideally, I should write code for readability and maintainability and let the compiler and runtime worry about optimizations.
The only good reason I can think of is that you're somehow stuck with 300ms+ delay anyway, so you provide an animation so that the users don't think "WTF? I just clicked on it and why is nothing happening?" But if you can shave off 0.2 seconds then you can probably get rid of the animation altogether!
I think they're terrible.
You'd also be surprised by how many people will completely misunderstand your UI and get confused by things popping around magically, if the transitions are too fast or inexistent. You have to build a UI/UX that your typical user will enjoy and be able to use, not a UI/UX that your nerdy friends are going to love. (unless they're your target users)
IMHO, this is exactly the kind of thing Donald Knuth was approving of.
Given how cheap CPU cycles are, how expensive developers are and that faster code often means more 'unsafe' code, 97% of the time it's more economic to just have the resource-greedy software.
Plus, I've seen more than my fair share of premature optimizations that ended up actually causing performance problems and stupid bugs.
I agree. I run sloccount in my build system. It gives a cost for manpower. For example:
Total Physical (SLOC) = 6,944
Development (Person-Months) = 18.36
Schedule Estimate (Months) = 7.55
Estimated Average Number of Developers = 2.43
Estimated Cost to Develop = $ 206,696
http://www.dwheeler.com/sloccount/http://vmorgulys.github.io/stackcity/sloccount.html
We should count the energy spent by inefficient programs (multiply the number of devices). It could balance that equation as the Moore's Law is ending.
I guess Debian (or another distro) if more energy-efficient than Windows (or Android).
Edit: beautified sloccount output
That's the problem.