Slashdot Mirror
NYT Paywall Cost $40 Million: How?
An anonymous reader submits this musing from Philip Greenspun's blog: "Aside from wondering who will pay more than the cost of a Wall Street Journal subscription in order to subscribe to the New York Times, my biggest question right now is how the NY Times spent a reported $40-50 million writing the code (Bloomberg; other sources are consistent). Google was financed with $25 million. The New York Times already had a credit card processing system for selling home delivery. It already had a database management system for keeping track of Web site registrants. What did they spend the $40-50 million on?" Maybe the folks behind CityTime were free on weekends.
A lot of it will have gone into executive information components of the system. Ways of showing the guys in charge exactly how much money they are making from the paywall this minute. Then you have the configuration interfaces and the teams to design datasets to control how the paywall works. Then you have the engineering which actually implements the paywall. They probably wrote a proxy from scratch to do that. Then they put it through validation. This created 10000 bug reports. Thats a lot of bugs so they outsourced the bug fixing to four companies in India who approached the solutions in 223 different ways. Then the resulting code changes were merged back into the mainline with bugs closed. Nobody wanted to do the tests again which was probably a good idea for the sanity of the people involved. Then they went live.
Well, thats my guess, anyway.
http://michaelsmith.id.au
I'm a consultant in telecom. I see this every day. I'm convinced that any project, no matter how big can be done by 6 people.
Apples: Creating a search engine from scratch. The main hook is that it is simpler than existing products. User workflow involves typing in a term and clicking a link, and users are interested in it because it's different than competing products. No money (remember, this is before Google Ads) is changing hands.
Oranges: Changing the user experience for a major existing site. Users are already familiar with the existing site and already inclined to react negatively because you're now charging for what was free. Money is changing hands, so a complete system for handling disputes and showing purchase history is required. The whole system has to hook into existing customer service systems. Customer service systems behind the scenes have to be extended. Support personnel have to be trained. Legal considerations for multiple states or possibly nations may be involved. Management needs reporting features.
I watched the Navy burn $27 million on a glorified CRM that used Siebel and never got any working components. While that clusterfuck was going on a small team of four people built a prototype type system that was eventually rolled out to production because it was the only one that worked.
The person responsible for the $27 million dollar disaster got promoted and took over management of the working system, which they promptly turned over to EDS to manage.
When it comes to software development, spending more doesn't necessarily get you more.
That's our life, the big wheel of shit. - The Fat Man, Blue Tango Salvage
Well it's quite possible to "book" the value of a project much higher than you may actually outlay at any present time. Remember, these costs get deducted, deprecated and ultimately reduce tax burdens.
Or maybe it was just hookers and blow...
I said no... but I missed and it came out yes.
Prerequisite: the team must be equipped with powertools to cut through the red tape.
Say, open line to the CEO who just says "yes" to anything they say and authority to fire whoever stops them from performing their task.
Depending on company structure, 10-60% of the time of any "revolutionary" change is spent actually developing the change, the remainder is asking, waiting, begging, urging, pressing, explaining, escalating and generally overcoming people who while aware of the necessity of the change and futility of their resistance, will resist the change as much as they can (or see it as the opportunity to exercise their decision-making power, which is totally unneeded and unwelcome there but by no means anyone could ever notice that.)
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
The depressing thing about the "big budget" development efforts is that the bigger the budget, the bigger the likelihood that it will fail.
Some of the most successful software I've ever seen was fairly ugly stuff that was knocked out in short order by less than 5 people. Years later, as it finally begins to seriously creak at the seams, the corporation puts together a massive team to bring it up to date. They spend massive amounts of time and money on consultants, fad "silver bullet" development tools and fad "silver bullet" project management techniques. 18 months into the 2-year schedule, they realize they've spent a year and a half generation UML Actor diagrams, panic, and immediately set everyone to work coding, without any coherent blueprint at all. The whole thing falls apart, lots of people get laid off, and maybe 2-3 people go in and hack the original warty system to keep it going. With luck, one can repeat this cycle several times.