Comment by kabdib | Hacker News Reader

Comment by kabdib | Hacker News Reader

You're not debugging hard problems all the way through the whole project. The cool, hard bugs happen maybe two thirds of the way to the ship date.

Now, imagine puffing up your development staff by a conservative factor of two. Assuming perfect skill transfer you're going to shave maybe six weeks off the schedule? In practice, no way. Your 'expert' devs are going to be swamped for a week or two while the new guys are coming up to speed.

This begs the question: What's magic about nine months? I've worked on projects that have practically killed their teams and hit their ship dates, and the result was ALWAYS that the product sucked pretty bad, and the team wound up doing another 3-4 month "fix" cycle that (a) dramatically improved the product, and (b) didn't matter, because the damage had been done and the product was toast. Then there was team burnout and churn. All very bad damage.

If you are trying to compress ship time by adding engineers you're already making mistakes that will probably kill your product. The right thing to do is to slip, and slip significantly.

I know: "We have to hit Christmas!" -- or whatever classic date your industry needs. But shipping a crap product in November is usually FAR worse than shipping a good product three months later.

Everywhere I have worked as a developer, hitting the date was far, far more important to the "folks upstairs" than quality. As mabbo mentioned, it could be inter-project dependencies. What if your software project is a driver for your company's electronic device, and they're ramping up for production in a month? You can't just say "Hey, the software team shouldn't be date-driven. Just keep 5 million finished units in a warehouse until the driver is really ready!"

It could be needing to ship in time for Christmas. You mock it, but the difference in terms of sales between hitting and missing Christmas can be the end of a small shop. Same goes for hitting trade shows. You can't just call up CES and tell them you need another week and could they please move their conference date.

It could be that your contract states that something will be delivered on DATE_A, and then something else on DATE_B. Dates are easy to describe and put in contracts. Quality goals are a lot harder to articulate and translate into terms of a contract. You'll see rough quality goals in some contracts, but you'll see dates in them all.

Saying, "We'll ship when it's good enough" often means you're never shipping. Go find products whose ship date was "when it's done" and look how late they were. When you aim for a date, and everyone is taking it seriously, you might just be able to ship something on that date, and "something" is usually good enough.

> Go find products whose ship date was "when it's done" and look how late they were.

Many of the best Nintendo games were delivered under this rule (as in yes, they actually shipped), and went on to be incredibly successful.

You're right overall, of course, and we can't all be Nintendo. But for some markets quality really is important, and in those situations you can't shortchange. You have to decide based on what your own unique situation in the marketplace is.

> You can't just say "Hey, the software team shouldn't be date-driven. Just keep 5 million finished units in a warehouse until the driver is really ready!"

So budget a generous amount of time for the driver up front.

The problem is when you are one one cog in a much larger machine. My team has a specific launch date for a major release of our piece of the product. The ten other teams around us depend on our release, and are going to meet their deadlines. The loss of one piece is the loss of the whole project.

Ideally, one should never let this situation happen- but it will.

Do I force the whole company to slip? Or do I accept that my piece is going to be crap at launch, but follow up and make it better later? Both options exist, and should be on the table. Which you pick is really up to the situation.

When I was at Microsoft there was a phenomenon known as "schedule chicken" whereby each team in an interdependent group would report up "no problem totally on schedule" despite being way off in the hopes that some other (perhaps even more off-target) group would admit they needed to slip the date. Then all the other groups could breathe a sigh of relief and say, "We totally could have made it but given that those guys slipped the schedule, we'll use the time just to be extra awesome." Of course the problem is that if everyone plays this game, you end up right before the deadline with lots of groups simultaneously admitting they're nowhere near ready and you have a huge mess on your hands.

Exactly. But we're actually talking about 3 things: time, quality, and scope. Pick any two.

I had the pleasure of working with a company that preferred time and quality, and were willing to negotiate scope. It worked really well, because, from the outside, it looked like we were releasing on a regular basis (so it looked alive), at high quality, and on the inside, we knew we'd ship the more difficult parts of the project eventually, but without the stress that goes with trading off time or quality.

Regarding ship times, it seems to depend on the industry as well as commercial vs enterprise software as well. New products and old products make a difference as well. On new products, I think you are generally correct but on established products companies can get by doing this.

The first company I worked for professionally was enterprise software and the market leader in the space had a tendency for years to knowledgeably ship poor quality products at specific times either due to legal reasons or financial reasons. They would try to staff up for releases and use contractors and all sorts of techniques to actually make the releases semi-legitimately. There was an unspoken acknowledgement not to use those versions though (actually I think they actually put a sleeve in the DVD saying not to install it in production once and to wait for the next point release coming in 2 months). I left them and became their customer and currently use 7 year old versions because the latest versions break things we need but its known that you never install their shipping version and wait for at least the first service pack.

I know in one case some customer contract/government mandate specified releases must be made by end of calender year so regardless there was a release regardless of current state of the project. The other cases were usually financial and it was due to something like if the DVDs physically shipped by end of quarter then revenue could be recognized in that quarter. Since this is enterprise the customer may or may not pay at that time since they are usually just paying yearly support but its the accounting games that are played that forced the time. In my current company we use standard accounting practices and our VCs have told us that if we are not using "creative" accounting we are doing it wrong so revenue recognition times or invoice time sneak in rather than collection time into the books.

Interestingly, the Macintosh project slipped many times, despite being the source of the "Real Artists Ship" mantra, which is often taken to mean, "it's always better to ship than to slip."

Reply on news.ycombinator.com