20 devs * $200 K (loaded) / year = $4 M / year.
... Assuming they had a way to bootstrap an idiot-rejection-filter.
It's likely that retail will undergo another change such as when sears took over in the late 19th / early 20th century. Retailers arent going to lose the war they will simply be replaced by more nimble competitors who can properly leverage technology. Contrary to popular belief there are good developers outside of sv and some developers are motivated towards well paying 9 to 5 jobs instead of options and sodas.
The article also conveniently ignores the huge logistics infrastructure retailers have and focuses purely on websites, while the web is certainly important the reality of the situation is that currently retailers such as Walmart have huge competitive advantages due to its investment in logistics tech and infrastructure.
It will change if organizations like Amazon and Zappos prove out that it is a competitive advantage. It is just mainstream retail is not the proving grounds for such revelations.
History is filled with these kind of rock star failures.
Buying the company gets you a team that can verifiably build the product you want, because they already did. That kind of conservative risk management is worth a ton of cash in the real world.
Though why would it not be possible to hire a person with a track record of building the sorts of things you want, and let that person hire the team?
Buying a company may or may not get you a team, depending on whether or not they stick around.
You are correct that paying market salaries for competent engineers does not ensure competent engineers.
However it must be noted that not paying market salaries for competent engineers definitely ensures that one employes substandard talent. The market is working well right now and competent engineers have no problem receiving market rate. There is absolutely no reason whatsoever why competent engineers will not find a job paying the market rate for their talent, and that is exactly what happens. As for the companies that can not pay market rate, well they are simply not competitive and will fail. That's how the free market works and it is a very good thing.
Any company that requires being competitive in the tech domain needs to be willing to pay for key talent. Companies like Target definitely need to do everything they can. Arguments that incompetent developers are good enough are absurd. Obviously what they have now is not working.
Building a site that can handle a nationwide retailer the size of Target, second only to WalMart in brick and mortar stores, is completely non-trivial. The top 2 engineers there need to be paid at least $1.5 million annual salary. Sorry. I know many companies don't like this but there it is. Now obviously there are many levels below this, but this requires a pretty large development team and several below this level are going to be getting $200k-$400k. At the bottom, the losers that are just out of college and don't know anything, those guys are going to be making $75k to start. Because that's the starting salary. Companies don't want to hear this. Only the fatuous useless ignorant executives that have run the company into the ground should be paid these salaries, in their opinion. Well, they can keep thinking that and see where it gets them. Many will lobby Congress, that is a popular tactic. Pay a lobbying firm $25 million and maybe you'll be able to flood the market with cheap engineers from overseas who are willing to work for $21 an hour, and are able to do the same things that any other $21 an hour retail employee can do. Because the overseas guys that really know their stuff are not looking for $21 jobs, they are making the same salary as everyone else with their skill level. Because that's how the market works.
The number was just a straw man to get the discussion going. Find some value that attracts talent, perhaps between my wild guess and your numbers.
(Also as a reference a Sr. Architect at Walmart.com according to Glassdoor makes 120-130k)
I guess that's one way to solve the idiot-rejection-filter problem.
I've interviewed with several "luxury" retailers within the past year, and my idiot-rejection-filter was usually triggered soon after the beginning of the interview.
It was usually due to the perception of inmates running asylum, or a legacy technology I didn't want anywhere near my resume (VB). Either way, lack of technological leadership, planning, and execution was easy to spot with a phone call or visit to a store.
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.