Inherited nightmare scenario, looking for advice [closed]

Question

I will try to keep this as brief as possible but with enough information to make informed decisions. Please point me in the right direction if this is not it.

I've worked at a small startup for the past 5 years. We have 8 people at our office, and our main development is done offshore. Long story short, our contract is terminating with them on not the greatest terms. Nothing malicious, but we will not be in business with them in the future, and they have become unresponsive for the time being.

I am the only one at our main site that has any programming knowledge. We are in the process of signing with another team, but everyone comes to me for answers, effectively making me head of Development (formally QA/Support). As crazy as this has been so far, I remain optimistic.

There is one very big problem, and that is the fact that there is no one to ask technical questions to. I've checked around our repository (we use Assembla/SVN), and we are seriously lacking in documentation. I'm thankful that I've poked around in the past and was able to setup a dev environment, and modify files as well as deploy them. There is still a lot that I do not know.

My questions are far and wide, but here are some of the main ones to start:

Have you ever been put on a big project by yourself? What did you do first? Apart from backing up our source code, what are some important steps I should take?

I'm feeling pretty overwhelmed at the moment, so I do appreciate some understanding. Our company is in decent shape financially (always operated in the black, lots of revenue coming in), so I'm not really worried about job security. Still, is the best answer to this situation find a new job? I really like our founders, and they have treated me like family. There is also the issue that I am now developing the software, and am being paid for my old job duties (may or may not be the best time to bring this up?) Thank you and have a nice day.

Our Stack: C#, .NET, SQL, Devexpress

Answer 1

No insult intended., but you are way out of your depth, in the sense that one person - who is not a member of a team - cannot take over the work of an entire team. So, make sure that your employers, who treat you as family know it.

Also, this is not your problem, but management – of both companies - who are responsible for arranging a smooth handover.

Is there someone on the other team with whom you personally resonate? If so, could they give you a “brain dump”? Every scrap of information is priceless in such a situation, so even if you don’t get it all, whatever you could get would be valuable.

Again, this is a management problem, as they should have been tracking the project, including documentation, not just coded, all along. If they felt unable to do so, they should have employed someone who could.

It may well be that they only thing to do is to pay the offshore outsource company to produce the documentation, which they should already have produced. Given that you are not parting on good terms, that may be the only way to get it done.

How is the timing with both teams? Is there any overlap between the new team & the old? Could you make separate contract with the new company to provide one guy just to handle handover?

Ad, finally, I can’t stress enough how important it is not to repeat the same mistakes with the new team as with the old. Have a project post mortem, preferably with the new team, but company internal if they are not yet on board. Figure out where things went wrong and ask the new team for their plans to avoid a repetition. Any professional company, especially one still looking for a new contract with you should be willing to comply; they should also be willing to provide one senior guy to coordinate the handover, if they think that will land them the contract.

And, think for yourself, what role you want to play going forward, when the new team is in place – QA or developer – and discuss that with your company. They might be very glad to have you as a developer, to liaise with the new company and help avoid a repetition. Who knows, you might become project manager (if you want to). Your current situation sucks, but it presents opportunities, if you want them.

Answer 2

Your code is version controlled by Subversion, so you should not need to "backup" the code other than occasionally backing it up at another physical site in case of fire or some other catastrophe.

Now, regarding how to handle the lack of documentation, lack of understanding of the code, etc., this question on the Software Engineering Stackexchange site may be useful to you: I've inherited 200K lines of spaghetti code — what now?

There are a couple of ways you could approach it. The first is to stop adding features temporarily in order to focus on implementing unit tests. This has two advantages: getting familiar with the code as you build tests for it, and putting in checks to detect when the code is broken when you start changing it.

The second approach is to clean up things a bit at a time as required. If you need to work on module A, then do the documentation, unit tests, and whatever other changes you think would be a good idea for module A, while leaving the rest of the code alone. For the next feature when you modify module B, do the same for module B, and so on. The advantage of this approach is that feature development is not stalled for an indeterminate amount of time, and, though I may be unusual, I am more motivated to understand other peoples' code when I need to change it and actually do something with it.

Answer 3

I do not think your question fit this web site because it is more oriented toward project management instead of navigating trough a workplace. Although, here some suggestions to help you to plan:

• Managing the technical debt to avoid the next programmers tell you that you need to rewrite the entire application.

• Assign each commit to a task to be able to understand why the code has changed from an outsider.

• Implement continuous integration to keep track of dependencies to be able to compile on another machine and avoiding an obscure missing dependency.

• Implement continuous delivery to keep track of what step need to be accomplish to release a version.

• Create tests of critical logic to generate live documentation.