Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This pretty much changed my view of her--it displays a lot of naiveté about how long it takes to develop software. I guess it depends on the market, but I'd be extremely skeptical about shipping any world-shaking software 6 months from beginning to write it. Assuming you allow at least a month for testing and debugging--which is EXTREMELY aggressive--that leaves just five months for planning and execution. For any kind of complex software you're looking at at least two or three weeks for planning, at a large company like Yahoo even a month seems very aggressive. So that leaves 4 months for development. You're going to lose at least a week to two weeks to meetings related to issues, work distribution, and so on. Assuming they're using Agile (if not, you have to allow for project planning meetings etc), and give them 1 month sprints to be generous, you're looking at about 3-4 iterations of the software before you ship.

I just don't think this is realistic. It's a nice goal and a nice thought but unless they're building HTML 5 games or something and counting those as products it's just not realistic. But we shall see.



I'm guessing you are very much her target audience, above are a bunch of traditional ideas about development that result in huge, drawn out processes for out of date designs that more often than not have some big omission missed during planning. In the meantime you've got a team so ingrained in how their project should work (after years of effort, probably forgotten what they're even building, lost in a world of type masturbation and implementing whatever cool tech they read about today, and demotivated because they've delivered F.A. in the meantime), regardless of its function, that pivoting the mess post-delivery is now impossible.

Yahoo isn't exactly sending men to Mars, they're cobbling together fairly simplistic web apps to serve ads and perhaps even subscriptions that at best need a bit of fancy realtime communication or maybe a very large database in the background. For these kinds of apps and open source where it is now, you can get 'prototype one' built in about 90 minutes by one guy defining a bunch of models and a 0 byte index.html.

Given a team of 3, one week is more than enough time to have a couple of buttons, some rough page layout, and most importantly an increasingly sterling idea of the problems you're going to start running into and how you need to adjust. It's called iterative software development, it's great.

Now just add one PM to whip the software kids in the right direction, and you have a viable chance at delivering an internal demo in 2-3 months.


Ok, yes. If you're developing a single-page Web app--or even a handful of pages--then you are correct, 6 months is an eternity. For an entire project though, which I understood was the thrust of this article, it is an extremely short period of time.

If Yahoo's goal is to develop simplistic Web software then I retract my statement, but we're talking about something absolutely worlds away from the type of stuff that Google has been producing, or even Yahoo over the past several years.


I'm not sure, but I don't think the implication was that the project must be 100% perfect in 6 months, just shipped. Slap a BETA tag on it, and it's still shipped, just not polished.


I don't think you understand what the word "project" means. It does not mean complex software.


I have a hard time believing she's naive about how long it takes to develop software after being on the product side of Google for so long.


Which product at Google took six months or less to develop from scratch?

This is not to say that a six month development cycle is impossible. There just has to be an understanding that there will be a trade-off in quality. Maybe Mayer is in the "get something out there fast, and reiterate based on feedback" boat (which would make me respect her more) but going from 0 to 100 in six months is impossible with the scale of projects Yahoo! works on.


Statements you make and policies that you implement for your company say a lot more about your naïveté than positions you previously held.


Assuming naivety is neglecting multiple data points, among them her extensive experience at Google working on or with some of their most successful projects.

Why start there? Why not look at the whole picture and loan her the benefit of the doubt, saying, "I believe with your experience it's likely that you're familiar with software development. Therefore I won't assume this is a massive brainfart, even if part of my mental model of the world thinks it could be. Without that assumption, what are you trying to communicate with this, and why? What can I learn from this, and do I need to update my mental model?"

Assuming naivety is unreasonably dismissive, and says more about the critic than the policy or policymaker.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: