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).
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).