[hga]

He's not "rubbing it in", he's pointing out some harsh truths. Perhaps mostly about how most people define "big picture", but in general they need to be said.

I'll go one step further; in a followup, the author said "[T]he leadership of the company is excellent" when that is demonstrably not so. Just sticking to the technical management part of things, the leadership of this company has known, and should have realized what it meant, that for that last year they had a key coder who was producing unmaintainable code. For the last half year this guy has been melting down and is now non-functional. Yet he is still a "co-founder".

They don't seem to have then necessary sense of urgency about this emergency ("We're in trouble (in my estimation only) because no startup can afford to have a key person take a dive, and every developer is key.").

This is an existential crisis for the venture and there's probably nothing more important for them to do at the moment than resolving it with a good plan, which I just don't get the impression is happening.

[pw0ncakes]

Fair point.

We believed that the unmaintainable code problem would be less of an issue after launch, and that this person knew his codebase well enough to keep it on life support until that point, at which we could hire people to fix the problem, possibly with aid of post-launch funding. We assumed it was benign "technical debt" -- a bad technical situation that can be paid off later when resources are less scarce.

What we didn't count on was the meltdown of the person responsible for the problematic code. In hindsight, we should have seen it coming, but it seems like there are always things going wrong in a startup, and everything seems urgent.

I've wanted for a while to fire this guy, throw out his code, and rebuild everything from scratch, but have been under the impression that we don't have the time/turning room to do this. I'm not experienced enough to know the externals (e.g. how hard it is to get funding, etc.) and whether or not this is the case.

[hga]

Well, I guess you've learned an important but hard lesson of the "trust but verify" variety WRT to code: unmaintainable (vs. hard to maintain) code is very likely to be a technical black hole rather than technical debt.

If your company had been reviewing his code it would have soon caught him violating his APIs and it's leaders could have taken corrective measures 10 months ago or so.

And you really do have to review the code of people you don't know very well. E.g. at one startup I worked at I finished the ... outsides of a custom tree database (designed deal with misspellings quickly). At a certain point long after it should have came to that, I reviewed the guts of the tree database and found to my horror that the author's undo list for transaction aborts (or power failures, etc.) was entirely in memory....

Otherwise the problems his work represented were of the technical debt variety and due to very good modularization I was able to fix many of them as appropriate. But if the venture had taken off, the above problem could have been a very nasty time bomb (only mitigated by the external parts that recorded all incoming transactions and that allowed for reply).

That company was also a great example of how not to do Customer Development and Lean Startups and a failure to do the lean part of that killed the company just when it took off (new angel investors turned out to be devils).

[pclark]

why do you want to be an EIR?

[pw0ncakes]

I like programming and solving problems, but I also like working at the big picture and being aware of the financial aspect. I'd be a great VC, although I'm also a pretty strong programmer. It'd be nice to straddle both worlds and learn from the best on each side.