[MCRed]

I haven't worked in the Kindle division, but there is a huge cultural gulf between Apple and Amazon. Apple is very much a software company (well they're a design company that encompasses both hardware and software). They care a great deal about getting software right. At WWDC each year they have a session on how to do great software that illuminates a process that involves a lot of design and upfront work before you begin coding. A process that virtually nobody does these days. (I say these days because back in the 80s this is how CS students were taught "write your program out in paper before writing it in code". Nowadays nobody barely thinks about their work before they start writing code, for the most part.)

This is the polar opposite of Amazon, which I worked for in the past.

Amazon is perceived as a high tech company but it is a retailer and its management is the management of a retailer. Amazons engineering is overseen by non-engineers and the company culture is highly political and focused on making a show more than making a product. Quality is the last thing they actually care about (when it comes to software.) You get ahead at Amazon with press releases-- it never matters if your product makes no sense. (EG: Movie listings on amazon.com, mail-order catalogs, literally scanned, and posted to amazon.com, innumerable initiatives and features that were put up there getting someone a promotion, only to have the team disappear in the next quarterly company wide reorg and the result to just rot.)

This is why I would never buy a tech product from Amazon. They really don't give a damn as a culture, and any engineer who gives a damn will not survive long there (and will be punished).

Giving a damn about design and quality doesn't play well with stack ranking.

What plays into stack ranking is kissing your bosses peers butts, playing political games and making splashy new features.

[derefr]

Huh. Does any/all of that apply to AWS specifically as well, or is it an exception?

[BugBrother]

>> Nowadays nobody barely thinks about their work before they start writing code, for the most part.

I am old enough to remember where this came from...

I used to do C for quite a while, then I made my hobby (Perl and scripting) my day job.

If given a certain size of a problem while working alone, I used to sit down and think for 1/2 a day or so, then develop (coding and also thinking more) for a week or two.

After I went scripting, this didn't work.

Since I could over an afternoon throw together a solution to the same size of problem which took a week in C, it was just not realistic to think first!

The best solution was to throw something together, look at it and then rewrite it if I didn't like it. The sheer development speed felt like I had gotten a sports car.

[tracker1]

Absolutely agreed... prototype-morph-prod is a faster cycle.. but on the same lines, it means automated unit tests are more important the more complex projects get. Which is why modular code and testing work really well with scripting environments, and computing is fast enough.

With a modular approach, it also becomes easier to scale horizontally either in the same server/system or a separate server/system. Either via HTTP, TCP, 0mq or another abstraction, if the interfaces are the same, the modular layers can be replaced. This gets easier with async by default environments (node.js, golang, etc), and I find it to be much harder with classic N-Tier (.Net, Java). I'd rather use 0mq with node than wcf with .Net any day of the week.

[BugBrother]

Interesting point about scaling, thanks.