requirements for software quality for internally developed / shared software?

Question

In environments where software is built internally by one team and then that software is used by other internal teams, how does one decide what the required quality should be for the produced artefacts? For example:

1. documentation completeness and accuracy
2. extensibility/re-usability of artefact (without hacking at source code)
3. defects
4. etc

I guess one aspect to consider is the length of time into a project before quality is considered. It should be more cost effective to ensure quality is built into a product from the start rather than leaving it until later in the project life-cycle.

Answer 1

I worked for a programming team which developed on top of a framework built by yet another internal programming team, so maybe I can share some insights I've learned.

While it's true that both teams are internal, in my experience, that grants you little extra freedom that you'd otherwise have if the objective is to produce code in an efficient manner. General guidelines within a programming team still apply: never commit broken code, branch significant modifications in order to disturb work being performed by other programmers, etc.

When it comes to committing code that another team will use, like a final product, it must be up to par in terms of testing and functionality. The difference is that if something is broken, rather than upset a client, you're wasting company time and money (and you're probably upsetting programmers rather than clients). After a bit of trial and error, we figured out that the best way to handle such things was for the framework to be committed like you'd produce a release.

There would be a trunk source repository, which, rather than being the place where all programmers commit their daily unbroken code to, would be the definitive tested and stable version that other programming teams can draw from. The "what would have been" trunk turns into a common branch (which we called the release branch) where new features get added and bugs are fixed. Where you'd normally branch from the trunk, you simply branch from the release branch and merge back into the release branch when you're finished. Once you've reached a point in which important features/bugs are added to the release branch, make a point that a programmer spends a good couple days to thoroughly test all (not just newly added) functionality. Once this is done, the stable branch can become the new trunk and a new release branch is created for the next version.

Even with this system in place, there were still many problems, but I can't imagine how many more problems we would have had if the framework worked every other day.

And to end with a little bit of advice, the biggest advantage that you have working with an internal programming team is that you have communication. Use it.

Answer 2

how does one decide what the required quality should be for the produced artefacts?

I always strive for the best*, but be aware that there is a multitude of non-coding "things" that are potentially going to get in your way.

These can include scope creep, dependencies on other teams/departments, budgets being slashed, personnel being re-assigned, political changes within company, incompetent managers/developers/BAs/PMs.

*where the word "best" is arbitrary in itself.