4

We have completed the feature implementation for new release of a product. The product is strategic for the company with a large customer base and making good revenue. The product has had lifetime of more than 10 years. Needless to say millions of lines of code and multiple technologies used. The original designers and architects have long left. The team is young and not so matured in required skills.There is not much discipline in development standard also not enough unit test cases.

This was a major release and lot of changes have happened. This has led to lot of defects being continuously reported.

The team has got into fix -test -fix cycle where for every fix some new defect is reported or something else is broken. The confidence of management is really low on product quality.

What are the short term(immediate release) and long term measures(future release) that can be taken from project management perspective to improve the situation.

2 Answers 2

5

First on my list would be to take some time reviewing your recent bugs and doing a root-cause analysis on how the bug made it in. That can help you decide on which solution(s) make the most sense for you to implement. As far as things I would likely implement in a similar situation:

  1. Design reviews - As a short term solution, I would suggest simply having a developer writing down their thoughts about how they will implement a change, and having someone else on the team take a look at it for any concerns that they have prior to the code being written. As a long term solution, I would set up some expectations of what should be in the design document (use cases, tests to use to validate, etc)

  2. Code reviews and/or pair programming - both of these can be short or long term, the basic idea is that getting multiple eyes on the code can definitely help catch bugs. But, these only really work if your people know what kinds of things to look for. My biggest suggestion on doing code reviews is to keep the amount of code being reviewed at a single time relatively small. The larger the amount of code there is, the more likely something will be overlooked.

  3. Unit tests - (properly done) these can be a good way to ensure that working pieces do not get broken again. These can start out as manual tests that get performed by hand, and eventually get automated as time allows. But whether automated or manual, the tests will only be useful if the people doing the testing or writing the tests know what is important to test. As a starting point, any time there is a new bug, write up a test for that bug. And if time allows, flesh out the testing to the behavior surrounding the specific failure case.

  4. Ad-hoc testing - have someone not on the development team use the product and see what they turn up. Sometimes when you are too close to the code, you start thinking down paths that prevent you from seeing obvious exceptions to the expected behavior.

  5. You say that the original designers and architects have long left. Are the designs they left behind well documented and up to date? Are they understood by the current team? If not, they likely do not have a good understanding of how changes in one area of the code can cause problems in other areas. It is probably worthwhile to allow some time and budget to have someone on the team dive into things and gain that understanding. If the entire team is young, I would suggest seeing if a more experienced person that you trust can be added to the team to do this. Their experience should help them pick up on any design/architecture patterns that are in place, and hopefully convey that information to the rest of the team. The person/people that gain this knowledge also become your experts for doing the design and code reviews.

0
1

In addition to Kyles list:

  1. Automated builds with http://jenkins-ci.org/. We used auto-build triggered after each commit to main repository. Jenkins checks codding standards, triggers unit tests, functional tests and emails errors to team leader.

  2. Automated deployment. We use scripts to update production files. If something goes wrong we can use rollback, revert changes and fix bugs.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.