[iMark]

I was on a project that produced a carcinogenic prototype. The irony was we knew it at the time. Before it was shown to the higher-ups, us developers joked that they'd like the prototype so much they'd come back with a completely unrealistic deadline for the finished product.

They did. They wanted it ready in 3 months. I estimated 10.

We delivered something - I'd hesitate to call it a finished product - 15 months later, and it was deservedly panned by users.

I've spent a lot of time since pondering exactly where it all started to go wrong, and I'm entirely convinced the day we demonstrated the prototype was it.

[kabdib]

I saw a startup do a tablet once (a very early one). They'd written a lot of demo code in Smalltalk V.

I interviewed there, and turned down an offer. When I was talking with them, I joked that they needed to be careful or they'd wind up shipping their demo code. "Oh, don't worry," they said, "We're going to re-write all of that."

A year later they shipped their demo code. A year after that they'd sunk without a trace.

(I sometimes wonder if they would have had a chance if I'd joined them. I'm guessing it would have turned out pretty much the same).

[mikestew]

"I sometimes wonder if they would have had a chance if I'd joined them."

Maybe if you joined as VP of Engineering or CTO. As an IC, all you're going to do is get dragged down with them, and go home pissed off every night.

I've been there. A company has no existing test infrastructure, it's all done by hand, and the build "system" are the binaries that come off a dev's machine? No problem! I'm you're man, I'll have you up and automated in a jiffy. Except that the reason there's no existing infrastructure now is because of general cluelessness, not for lack of expertise.

You need someone to hook the hoozit that I lightly touched last time I was there to your new whatzit? Yeah, I'll come in on a contract basis to get it sorted. My first clue should be that none of the other devs who know it better than I came to your rescue. No specs for the thing I'm supposed to integrate with, no documentation as to what it is you actually want, and a PM that sits and watches YouTube videos all day? Yeah, I should have guessed.

It's top-down, and if you're not at the top, you're not going to save them from themselves.

[bermanoid]

Not at all - the day you went wrong was the day you wrote code that worked and assumed that the people paying you would let you rewrite it later.

That never happens, unless you force the issue by making the first version fundamentally unsalvageable through choice of language or something like that.

If you don't know for sure that you can't (for a very real reason, like the fact that AS3 won't run on iOS) ship a line of code, it's on you to assume that everything you write is going to get to production. That's the reality, even if it's uncomfortable.

...I say as the lead on a game that just got sent in for review today, 8 months early, with 95% of the "prototype" code that we started a few months ago intact. Luckily we never believed that it was actually prototype code, because wasting a month and a half to recreate something that already works is a hard sell to anyone that hasn't struggled with the codebase already.

Pad estimates, and plan for the worst, is all I can suggest. But also realize that sometimes short timelines are a blessing: the people that would be filling up the feature request list stop doing so once you tell them that you're already overcommitted by 80%. That helps the product, usually.

[iMark]

We were asked to produce a prototype in a two month time frame and we did. It was the subsequent unrealistic time frame after we demonstrated the prototype that did the damage.