A friend of mine wants to buy a nearly bankrupt software company and is interested in one of their incomplete software. What should he get from them besides the source code as the company is willing to provide any kind of documentation he wants.
And he wants to get the most essential kind of documentation to minimize the duration of the transition period. Note that the development team will not be the same. What do you recommend?
You may want to get a list of existing customers so that you can contact them about the change and give them a chance to purchase support to get the next version. Tell them that this is a limited deal and that the cost might be changing in the future.
Overall it also gives them a person to contact as well when/if they have issues. Show them that you care about keeping them happy.
User and troubleshooting documentation, if any has been completed/started. Basically anything they can get, but if it were me I would want to know why the program was designed the way it is and how it's supposed to behave.
Any requirements documents they may have, plus flowcharts for program flow, object diagrams, UML.
If they used an Agile development methodology, the user stories would be the most crucial.
It's usually fairly easy to take code and figure out what it does (unless the previous coders lacked the common sense to follow conventions for the language.) It's harder to figure out why a system is designed the way it is. Those types of documents can be invaluable when taking over software you didn't write yourself.
Try to hire at least one coder from the original team. Having someone who is famaliar with the codebase will make it much easier to get the software to a usable state.
Any documentation is helpful.
Tests will be the most helpful, as they will give an idea of how the thing is actually supposed to work.
"Incomplete" software would scare the snot out of me. If the company is going bankrupt, there's likely a reason. There's likely a reason the software is "incomplete." These two are likely related.
Incomplete software is not necessarily better than starting from scratch. It could be of great value, but it could be worse than nothing.
Clarification:
The cost of this software is:
The value of the software is:
The last two factors in the cost will be hard to determine without a detailed analysis, and worse, are likely to have a pretty wide range of possible values. The functionality that actually exists will be hard to determine without a serious analysis, as well - what looks like functionality could well be demoware.
Writing everything from scratch may be more expensive, but it is likely to have a smaller range of possible costs.
That's also why I suggested tests as the most valuable form of documentation - not only will they tell you what the software actually does (as opposed to what they planned on it doing), but it will give you an idea of how much functionality is actually present - especially if the software has never been completed enough to even ship a V1.
Unless your friend has very detailed insight in what that company is doing, or has so much money that losing some doesn't matter at all to him, I can only recommend to cancel that deal. The old team will not be happy to help the new team. The new team will not be happy to work with an existing, but incomplete codebase. Taking over something that doesn't work is much more difficult than working on a program that already works (at least in most cases), because you can't watch it work. The effort necessary to understand the fragments and get it working correctly will probably greater and harder to estimate then the effort to start from scratch. Plus you'll probably get better people when you start from scratch, because many programmers (especially experienced programmers) love to start from scratch, but hate to work with an existing codebase.