7

My company has several products on the market, developed in multiple offices in Europe and the US, which use the same common library. This common library wraps up a lot of industry-specific details, as well as adds some enhanced user controls, extension methods, math bits, etc.

Problems arise when QA comes back with a bug or the product owner for one of the products wants a change, and that bug or change requires changes to the code in the shared library. Because it is a change to a library used by all of our products, the change can have far reaching effects. The defect / bug report / change request is typically placed in the product backlog for the "original" product - that is, the product being tested by QA or owned by the PO requesting the change. This means that there is very little visibility in the other products for these changes, and things may break (very obviously with compile-time errors or more subtly with different run-time behavior) when the library is updated in those other products. QA for the other products may see the changes as regression failures.

The library is fairly mature at this point, so most of the changes being made are the result of bugfixes. Changes are submitted via a pull request, where a representative from each of the regional offices can review it (though only 1 needs to approve it); known high-impact changes are typically communicated over email, but may be forgotten by the time development resumes on a given project.

How can I manage a library like this, to ensure a good visibility among QA product owner, and the Developers?

| improve this question | |
  • What is the problem with "Pros and Cons"? – gnat Dec 16 '16 at 21:08
  • 1
    @gnat edited to be more concrete – mmathis Dec 16 '16 at 21:16
  • You don't have a bad process for managing the library, but if you have a lot of regressions and breaking behavior, the library may be poor quality and need some rewriting. Normally such a library does not encounter many regressions. Think about more effective automated testing, and where exactly the bugs tend to concentrate. – Frank Hileman Dec 16 '16 at 21:17
  • I think I read that at google when a change on project A causes breakage on project B the developers of B are allowed to revert the change to A. – bdsl Dec 16 '16 at 22:40
  • What about versioning? An specific product depends on a specific version of the lib. Of course it demands independent maintenance (lifecycles) for each version. If you end up with many and different versions, that could mean that the shared lib might not be as "common" as you assume, so doesn't make sense to make it shared lib. At least part of it. – Laiv Dec 17 '16 at 13:28
4

Based on your description, the common library appears to be a collection of business functionality and utilities common to many of your projects. Regressions caused by one product's modifications may not be immediately visible in the other products.

Some core recommendations are:

Versioning

As you mention, the library is pretty stable. Versioning this library, if you haven't already, is the first step to preventing side-effects. Once released, versioned artifacts are assumed to be immutable.

Each consuming project should lock to a known-good version of the library. QA only has to worry about breaking changes when they choose to update to a newer library version. At this point, they should be running full regression testing anyway.

Semantic versioning (major-minor-patch) is a compatibility-based versioning scheme that might apply in your case. Library versions can be easily managed through artifact-management tools such as NuGet. Source code can be maintained using branches, tags or similar mechanisms.

Release Notes: With versioning, you have the additional advantage of release notes. Each version can describe the bug fixes and enhancements that went into that release. This makes it more visible to product owners, developers and QA, so they can make informed decisions.

Decomposition

Based on historical data, you might have a good idea about which areas of the library have the most changes or churn. You might also have fairly independent areas of functionality within the same library.

It might be a good idea to separate these areas into independent libraries and modules, each with their own versions and locked dependency versions. This helps to reduce the impact of a version upgrade and isolate ripple effects to a more defined area.

Product owners can now track which sub-modules need the most attention, and would be able to create a dedicated team to manage or QA those specific areas, if necessary.

Unit tests and e2e tests

Define your "units" of functionality. In most utilities, the unit is a single class or a single function. In some cases, it might be a module.

Design unit tests to cover individual functionality. Use the 80-20 rule to decide which units need the most tests. In addition, design end-to-end tests as necessary, mocking out sample library consumers and testing the expected behavior.

This will be the first line of defense, and should alert developers that they are making incompatible changes and need to update the version.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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