Any insufficiently advanced magic is just technology.

All quantum computers are real, unless declared integer.

This is sadly true, and I've seen it a lot. When a developer is motivated by a deadline, other people's screw ups are just things that interfere with meeting that date. Any fixes will come out of the padding in the estimates, and once that padding is gone, so is the programmer's motivation to fix them. Those kinds of bugs then get quietly swept under the rug, or if they do get brought up in advance, people start arguing about who made them, who should fix them, who will test them, and in which future release will they go out to the customer.

In this particular example, the bug is egregious, and I'd expect the programmer to make the 5 minute effort to clarify the spec. The difference is that most programmers understand math well enough to catch a math error, but not every spec error is in their field of expertise. What if the mistake was in the calculation of tax, and the programmer doesn't understand the tax laws well enough to spot the error? That bug is going to sail right through every test, and the developers will deliver their perfect-to-spec-yet-still-buggy code.

The fact is that no set of specs are ever perfect, and the dangerous fallacy is in believing that they can be made perfect. And even if you can hone and polish them to a glistening perfection today, the problem domain the design is addressing will often change between the time the specs are written and the time the software is delivered.

Specs have several kinds of errors: errors of omission, conflicting requirements, and incorrect requirements. Design activities can identify conflicts, but often can't find the others.

The figures of "90% design, 5% code" is very much tied to physical world engineering, and is valid advice when you're creating an unchangeable physical thing like a car or a bottle-forming machine. But think about how much computers have evolved in the last 30 years - it shouldn't surprise you to learn that software development methodologies have evolved as well. Unlike hardware, software is infinitely flexible, and changes can be made cheaply and continuously throughout the life of a product. So instead of spending 90% of project time on Big Design Up Front, iterative or Agile project management methodologies and flexible design methodologies such as Test Driven Development leverage the facts that the world is constantly changing, software is infinitely flexible, its design is malleable, and having fully automated tests enables rapid changes and continuous deployment. By writing a test first, you ensure that requirement (as received) is being met. Understanding that coding is a design activity (and not a construction activity - construction happens when you click "build") is key. By applying good design principles, code can be refactored from a functioning solution to an elegant design, and this activity takes place iteratively during coding.

They've been using 3D printed objects as patterns for investment casting of metal for over 20 years, since the advent of 3D printing. The problem is cast metals are often not the best solution for the end use of the part. For example, no cast metal is yet suitable for making molds or dies for high volume plastic injection molding, where it has to be extremely hard and shock resistant - P-type tool steel is the right material for molds, but I don't believe it can yet be precisely formed by casting.

However, an investment cast metal mold makes a great temporary mold or die if your production mold breaks. A company can print up and cast a mold and get their factory back on line within just a few days. The temporary mold may only last for a thousand parts, but that will often be enough to keep them on-line for the two months it takes to have a production mold made. If not, they print another and keep going.

the potential for some conspiratards to see themselves as they talk about "the government"

because it's all the same paranoid bullshit

Office365 was created for exactly one reason. It was created to convert customers from a pay-once model to a pay-as-you-go subscription model.

Who do you think Office2013's biggest competitor is? Open Office? Hardly. They're competing against the installed base of Office2010 users. They are competing against themselves. Long ago they ran out of truly useful features to add - how many users were clamoring for the ribbon bar, or Clippy? Once they improved their software engineering skills and drove out most of the bugs and security flaws, they removed all compelling reasons to upgrade. And that is cutting into their revenue stream. Subscription based software rental will keep the money taps open, but only if they can connive people into "upgrading" to it.

This change improves one thing only: Microsoft's cash flow. It was not changed out of a desire to improve upon a working product.

And you're helping sell it.

They'll have less resources to assign to the 90% of the time they have given to domestic disputes and even less to the chuckleheads who are cutting you off, talking on their phones, while drunk and snorting coke, while driving.

Every new law should be bound to carry funding to enforce it.

Here is tip, comrade, everyone is a terrorist, but me!

It means "ã]6". At least that's what I got after pasting it into a base 64 converter. But I'm not sure I understand it any better now.

You were doing really great until the end there. "But nobody knows how to use a terminal, and you can't do it on a tablet!" is actually a real business concern that needs a plan to address it, even if that plan is "we will never outsource data entry or use anything other than desktop/laptop for it".

Point-of-sale systems are moving to tablets/phones right now - that's how the food trucks here in Boston are running their businesses. I'm sure there will be businesses moving data entry to it also. Perhaps the better response would be "The plan is to keep data entry on the existing systems, but move the data entry portions into the process itself so that we don't need humans here at all. When the data entry becomes trivial then we will look to either combine it with another role or push it to an outside firm."

I was afraid someone like you would reply.

It. Was. A. Joke.

Maybe he's the guy who gets all the emails that Exchange is down, and needs a reliable email client?

And what, in your expert opinion, is the right tool for the job? Back in the day I never bothered moving to pine, because I figured elm was good enough for me. (And it was.) Now I seem to spend half my workday in Outlook, and it makes me exactly every bit as productive as elm did. It's worse, actually, because these days everyone has email and it's now far too easy for the unwashed masses to cc: a status report to a hundred people who simply don't care.

If a newer tool doesn't provide a demonstrable or measurable improvement, what makes that new tool "right"? What makes the old tool "wrong"?

Soylent Green is 99% people!!