LOL. 200k? 20 devs? To build store.target.com? They'd better be awesome, and that awesome doesn't walk for 200K.
That level of awesome builds the product (show don't tell) and then sells it for $180m.
That level of awesome builds the product (show don't tell) and then sells it for $180m.
Given a sufficiently inefficient process, an infinite amount of labor can be absorbed, I suppose.
I would think a core tiger team could accomplish wonders simply iteratively triaging their existing operations.
But that's not what I have. I have a pile of legacy crud that has to integrate with ten other piles of legacy crud, not to mention the external crud with which I must integrate.
And did I mention that during holiday the site gets a little more traffic than most sites? Or that the site makes a few hundred million dollars, and can't just be rewritten on a whim? To solve these sorts of problems, I don't need ten good hackers, I need more like 50. Or more. And that's the challenge the article is talking about. Because good hackers have options like Facebook - or their own startups - where they don't have to deal with that kind of noise.
It's a serious challenge for any big company which relies heavily on the web, which in 2012 is every big company.
Why not? If the site is unstable and can't stay up, you can either throw 50 programmers at it and still have it crash regularly or you can take far fewer and re-write it from scratch.
You're right about programmers not liking the cruft, but we also don't like most of the management processes that occur in large companies. I don't know if things have changed, but back when I worked for a large brake corporation, web programmers were devalued and distrusted. All of our decisions had to be signed off (in triplicate!) by a manager who didn't know how to program or the implications of the decisions being made.
To give you on example, one of the official company-wide policies was that if you wanted to transfer files between company offices over the internet, you had to use FTP for "security purposes." We were technically not allowed to use SSH or SFTP because, when I asked, my boss said nobody had heard of it. This was in 2006.
The stakes would be incredibly high, you would need extremely skilled, experienced and passionate engineers and a management environment that would give them enough breathing space to be successful. Everyone's careers would be on the line. Besides the fact that no one is going to want to stick their necks out for Target.com (whereas someone might consider it for a site that improves lives in a meaningful way), that's going to be a lot more difficult than you're making it sound.
1) Check if the item is in stock at Store A, if so, send a message to take it off the shelf to the store -- access to system wide inventory management. 2) If it's not in store A, find the nearest warehouse and route item X to store A. Give the user an estimate shipping time + Alert Store A the incoming item is reserved for the user. 3) Update global inventory lists and decrement one item X from stocks. 4) Update sales/accounting to let them know of the sale. etc.
The problem isn't in the ecommerce site so much as everything else it has to interface with and do. It has to interface with systems up and down the whole chain, and depending on how up to date and accessible those systems are, it could get real interesting trying to merge them together.
I'm a retail integration consultant (currently looking for my next gig, to any desperate Oracle Retail users out there :-).
You either 1) Emulate stock control and routing rules in your app (flaky), 2) Hook the ecommerce app deep into the DBs of the other systems (now almost impossible to change those systems due to the level of coupling and the politics it will involve) 3) Go fully realtime with all systems running on a common bus (seriously heavy infrastructure and support requirements)
Ideally you should do 3 but most of the time you end up with some combination of 1 and 2. Then the next "must have" idea comes along, and before you know it your fancy new e-commerce solution has become part of the legacy establishment.
My experience, albeit only the last 2 jobs, with the concept of "Enterprise Service Bus" is that it becomes a magnet for "Architecture Astronauts" with little functionality delivered :-(
But it sounds a hell of a lot more impressive than "we will wrap simple REST or XML-RPC services, for which clients can easily be implemented in various consumer systems, around needed queries and updates, using the technology most amenable to the data store in question, documenting the interfaces, using proper configuration management policies", though.
But maybe that's about what you meant, in a nutshell.