What's the best strategy for maintaining this piece of software

Question

I work at a non-computer startup. Over the past few years I wrote our website and well as an internal website that we depend on everyday. Because I was involved with all operations of the startup and I was working alone, I was able to determine requirements and program new features without a formal spec or requirement documentation. The system is also written in an outdated framework that no one else uses. The system is fairly large. Over 100 tables, over 100k lines of HTML, C++, Perl code.

Because most of the documentation and requirements are in my head, it's difficult for others to come in and work on the system. Now, I want to detach from the startup. What's the best strategy to transition to someone else managing the project? Should I

1) Hire a technical writer to document everything with me?

2) Hire a consultant company to manage the IT, server, and code-base? Do such companies exist?

3) Try to hire a very skilled senior developer? This I think is difficult because we are not a computer company and no one good is probably going to want to work at a company like this and being the only programmer.

Your thoughts are appreciated.

Thanks.

Answer 1

As a start, I would suggest that you ensure that the code is very well commented and you create an overview document that will let your eventual replacement know which source files are responsible for what.

You definitely want to hire a programmer to replace you, the more skilled the better. Do so now.

Answer 2

Evidence of a problem.

• "The system is also written in an outdated framework that no one else uses. "

• "most of the documentation and requirements are in my head,"

• "it's difficult for others to come in and work on the system."

Hire one senior and one junior developer to rewrite it from scratch.

1. They have the working site as a "living" spec.

2. They can clarify the bad parts by asking you.

No new features.

Just rewrite it on a new platform that the two developers can agree on.

It's cheaper -- in the long run -- than anything else.

I hate to be the one to call your baby ugly, but preserving code simply because it happens to do a useful thing isn't really cost effective. The time required to learn an outdated framework is time wasted.

Answer 3

commenting the source code and laying out a good schematic plan gonna make things a lot more easier. I don't think you should migrate to any other platforms, frameworks... unless you did a big mess with the code itself.

I had a similar story few years ago. The big peace that manages Data base transactions.. was written in plane C/C++ given our old RDBMS company didn't think of writing any ODBC driver for UNIX based platforms, neither a perl DBI interface. Hence I was forced to some extent to code very low level, and imagine.... Apart this everything else was written in Perl.

So during the hiring process we didn't face too much difficulties, the new mate was a PHP Guru and very enthousiastic about Perl, so hopefully few days later he was already doing great.

Answer 4

I'd suggest to start by your self..

First keep the code clean. Well commented and well structured. If you are following good coding convensions/practices perhaps the patterns the reader can easily understand what you have done...

I don't see any advantage of using a Technical Writer. In such a scenario you will need to transfer a huge amount of knowledge but still he/she is not a developer. So I guess the documentation process will not be much effective one.

One thing I'd suggest to do is, document the really necessary information (Core or root information) by your self. You may not need to write a long story.. In most cases a diagram / flowchart or even just a sketch can tell thousands of words. hundreds of Code lines :)

Be careful to filter out the really really essential part first. Honestly there is no need of keeping 100% documented, covering the core part would be enough for most cases. As an example you don't need to document what an each and every method does in a Class. A short description on functionality of a given class would be enough for another programmer.

Answer 5

I agree that documentation alone would not suffice and would not be effective. Best to have few flowcharts and diagrams, including the following:

1. How to = troubleshooting the downtimes.
2. Managing dependencies for system changes
3. All configurations explained in detail.