Which, by itself, is already a crazy idea in a supposedly "civilized" world.

When I mail a letter, I expect only the staff of the post office can read the outside of the envelope for the purpose of delivering the letter, until it reach the mailbox of the recipient. After which only authorized persons (with the mailbox key) will be able to retrieve.

There are LOTS of privacy expectation on the outside of the envelope already, namely:

1. I expect no one but post office staff can read it, and only for the purpose of delivering the mail (i.e. no data mining, no retention of this data, no sending it to FBI/NSA)

2. To spell it out, I don't expect the general public, non-delivery post office staff, the post office manager, nor people touring the post office, etc, to be able to read the outside of the envelope during transit

3. I don't expect people to stand behind the postman while he puts the mail into the target mailbox. Nor do I expect the postman to read the "from" address intentionally unless the "to" address is wrong

4. I don't expect anyone can open and go through the mailbox, even without opening any envelopes.

Look, to a game seller, how much money you spent of his game is way more important than how much time you spent on it.

Classifying you as a "mobile gamer" based on your purchase is the only relevant way from the POV of the industry. No game company cared how much time you spent of a game after you have paid for it.

For a mandatory car analogy - a rich guy bought 20 Ferraris but only drove them once in a while, spent most of his road time in a Benz instead. Another rich guy bought 20 Benz and only 1 Ferrari and drove the Ferrari all the time. Guess which one is more of a "Ferrari driver" and which one is a "Benz driver" for Ferrari and Benz?

And today, if you stopped buying iPhone, others will follow, and then Apple won't have any iPhone sales anymore.

See how ridiculous you sound?

That is neither "early" nor "late". You estimate the effort required, break down the stories into manageable small chunks, then let the dunderheads priorities the stories, and then off you go to the next sprint.

It may take 10, or 20, or 50 more sprints to have all the multi-currency requirements completed, but does it matter if it was the 3rd sprint, the 38th sprint or the 380th sprint? If it does, you are doing waterfall. For agile projects, it shouldn't matter. If the dunderheads aren't willing to pay for the additional stories, that's another problem entirely.

Yes, if they had included multi-currency at the 1st sprint, then you won't have a stories worth 10/20/50 sprints to do at the 38th sprint, but you just had those same amount of effort spread throughout you other stories, which would result in similar total effort anyway.

Or are you going to say your codebase was already a mess by the 38th sprint, when everyone was hope the project would finish so they don't have to deal with the accumulated technical debt? If you are going to say that, you already spotted the problem, and that is not with doing agile.

Same here, and my first PC was an XT. So it is like in some 25+ years of owning and building my own PC, I can count the times I have upgraded one (after initially building it) in one hand.

And the most recent one was like 5 years ago, and that's only because it was a big hassle to re-install everything if I bought a new PC (which is a non-issue with a Mac), so I bought a new video card instead even though I could well afford a new PC with better everything.

Then don't buy iPhones. It is that simple. Really.

The *point* of Agile is that there should be no time that is "late in the project".

With fixed, short, repeated cycle of iteration/sprint/whatever-you-call-it, such as 2-weeks sprint cycle, *every* cycle should be start with work estimated to fit in the cycle, and ends with deliveries of completed work that delivers value to the customer. It should work the same for the first cycle, just the same as the last cycle.

If there is a point in time that is considered as "late in the project", you are doing Waterfall, not Agile.

The "design" part is no difference, but the execution makes all the difference. Running software is like running a car in an alternate universe, which you only get a specification document for the basic laws of physics and the spec for the materials, which may contain errors, and which may change without notice. The strength of the steel, for example, may suddenly weaken, or a steel bar may suddenly shatter if a small but specific pressure is applied to a special point on the bar.

Not only that, the requirements for the car changes at the whim of some group of people, and different requirements sometimes contradict each other. Plus the quantitative requirements (like mileage, capacity, etc) double every 18 months, but your design today have to also handle for the increase in the coming 5-10 years, which means you must use technologies still in experimental stage, and hope it fits your design when it matures.

You can bet a car designed for such alternate reality will have lots of problems. So, yeah, designing a car and designing a software product is not different.

Gee... this sounds just like the Waterfall model, guess where the CS departments learned it? :)

And this sounds just like managers who don't understand how things works, and think doing design is a waste of time and push for "just start writing code" before the requirements even finished.

And I would say those hordes don't even want "basic job training", they just want a piece of paper.

Exactly. This is just the same "if you have hammer, everything looks like a nail" problem that is already so well-known in among programming already, but in a wider setting.

Programmers who don't know much math never knew how many stupid solutions/programs they have written over they career, and thought the math has no use cuz they never need to use it.

Programmers who knew a lot more math take advantage of it everyday and can tell their story how math is useful to their work.

Only those few who knew enough math to know they can benefit more from knowing more can say "more math can help me", but those would went and learn more to be the second group soon enough, so the gap between the two groups will always remain.

This part is right.

And this part is totally wrong. The clean solution is to take a page from Europe, make your train network actually useful, and let trains haul you AND your car from one city to another. You drive the station, park your car ONTO the train (as well as charge it if you like), then go sit comfortably in the passenger cart of the same train, let it take you to the destination city, and then get on your car and drive away.

The train ticket may sound expensive, but if you account for the fact you saved fuel/electricity cost for the car, and you can comfortably rest or sleep overnight for the entire trip, it is a bargain.

You have such a big problem with long road trips in the US because your train network sucks.

The ugly truth is, IMO, the mentality is really not as much as "leave me alone" as it is "let me cover up my failure in hope of a miracle". And miracles DO happen quite frequently in large companies, where 80% of their projects fail anyway, so as long as you can cover up your failure until some *other* guy's failure can no longer be covered up and the whole thing failed, you are good.

In some cases, it manifest as the "Schedule Chicken" pattern. But this works on every level. Architects can stall any project by unending questions and arguments on the design, ensuring his design will never face the test of reality, or at least enough CYA when the system fails. Developers can keep pretending they are on-track, while nothing works, until other teams call for a delay, or every components fail spectacularly during integration.

Doing Agile takes away all their excuses and provides great transparency, it usually makes a lot of people who used to work in large shops extremely uncomfortable, to say the least.

Exactly. You cannot use Agile to build a 100-mile canal, as the whole thing would be useless even if you completed 99 miles.

If the system cannot be useful until a large set of functions are in place and working, then it is not suitable for Agile, period.

Game companies aren't the only ones to rehash the same stuff again and again. Journalists had already learned that trick before there were game companies.

An excellent example of this is a search function which assumed wildcard for blank search fields, and initially defaulted to all blank. Double bonus for not setting any limit on the number of results returned. The dev tested it thinks it is great it returned all 3 testing records (sorted) when just hit "Search" without entering anything.

Any user using it for the first time, and experimented with hitting the "Search" button (or even experienced users accidentally hitting "return") will trigger a full table scan, and in the first week after the system was just launched, get a few thousand rows of results. Then a couple weeks later, had their IE crashed when IE can't handle to huge table returned. A few more weeks later, had the whole server hung up for hours as the database tried to sort 20 million records and the sort overflowed to disk.

Unfortunately, I have seen this happen too many times in real life systems.

A minute of thought from the system analyst or architect would have changed the spec to have the current date set as the initial default in the date range search field (or some such similar defaults that would normally give a much smaller and useful results), and forbid search with all blank (probably with an error saying "Please enter your search criteria."). More technically minded analyst would include in the technical spec to limit the result set from the database BEFORE the sort.