Improve company productivity with a Business Account.Sign Up

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 346
  • Last Modified:

Need article on moving development of acquired software from single developer to team.

My company recently acquired a rather complex software product created by a single developer for a limited market. (It happens to be an MRP system, but not sure if that is relevant.) We are trying to get a handle on the functionality, code and database (none of which are well-documented) so that bug fixes and further development can be taken over by a larger team -- and get it ready for larger-scale distribution. The original developer is still available, but only on a limited basis.

Do you know of an article or book that addresses best practices or suggestions for a task such as this?  Thanks.
1 Solution
I do not know of any books or articles on the subject, but I can offer some good advice.

1) The IT management should have it as a goal to always make sure that more than one developer has a working knowledge of the code.

  Programmers can be lost to the company for any number of reasons from leaving for better pay, to a plane crash, to a natural disaster.  To be prepared for this, you must spread the knowledge.  I know you currently have a goal to get a team working on this but that is not necessarily the same thing.  I have seen managers try to give one person a piece and another person another piece, etc.  This leaves gaping holes in the overall understanding.

2) When it comes right down to it, you will just have to roll up your sleeves and dig into the code.

  One of the best ways I have seen to handle this involves trying to rewrite a section, as an exercise.  This gives you an in depth understanding of the process, but you have to start from the idea of understanding all of the logic branches that the code can go through as this helps to map out your testing scenarios.  By the time you are able to replace a piece of the code, and verify that it has the same functionality, you have a pretty good understanding of the code.

3) When it comes to trying to understand someone else's work (especially when they are not available) it helps to have several people looking at it.

  Some people like to refer to this as a "sounding board"... whatever you label it, there will be times when the code seems odd... programmers rarely follow the same practices.  Encourage your team to ask when they don't understand.  Explain that this does not reflect poorly on their abilities, but instead reflects well on their ability to work as a team.

4) Understand that what you find may not be good code.

  This makes it EXTRA IMPORTANT to fully understand it.  Use of global variables, poor design, use of spaghetti code, etc.  These things need to be identified so that the code can be fixed.  To many developers the old adage, "If it ain't broke, don't fix it" applies.  I disagree.  I ran into a bit of code recently that looped through from 0 to 2,147,483,647 to see how many of the values were in a list... Using run time type information (called reflection in some languages) I was able to determine that the list he was testing only had a range of 0-3.  While the other code worked as it was, in my opinion, it was completely wrong.  Remember, you and your team will need to be able to maintain this.  Anything that is identified through this process as needing to be fixed can be added to the team's "to do" list.  There is no need to fix it immediately, as the code is supposed to be in a working state now.

5) Use an automated testing tool

  If the project came with automated tests, great!  If it did not, this will be more work up front.  It will pay off in the long run.  If the code came with automated tests then you can use those tests to verify your attempt to rewrite sections (step 2).  If it did not come with test cases in an automated testing environment then the rewrite process would be a perfect place to put in your testing scenarios.  You can make the same test of the original code as you do for your new code.  As the rewrite project progresses you will build the automated testing that will help to keep the code stable in the future.  This helps with the maintainability of the code since, if you make a change that breaks something, it will tell you.

6) Make sure to keep the original source code in pristine condition

  For a year or more after your team has taken over the project and feels comfortable with it, it is a good idea to keep the original source, in it's original condition.  You never know when a customer will come back and say, "It never used to to that!".  This will give you the ability to run that version and show that it did, or did not.  If it did not behave that way then you will have it for comparison.

I hope some of this advice helps, let me know if you have any questions on any of it.
AutomateMyOfficeAuthor Commented:
Thanks very much, developmentguru.  I really appreciate the time and thought.  Why not submit it, as-is, to one of the industry magazines?  I am certain this situation is relatively common and would think such an article would prove valuable to many readers.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

What Kind of Coding Program is Right for You?

There are many ways to learn to code these days. From coding bootcamps like Flatiron School to online courses to totally free beginner resources. The best way to learn to code depends on many factors, but the most important one is you. See what course is best for you.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now