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.

  • 1
    The text field on StackExchange sites is not remotely large enough to hold a good answer to your question. There are shelves at your local library filled with attempted answers. Can you narrow it down?
    – thiton
    Commented Feb 15, 2013 at 10:51
  • Apologies for the vagueness of my question. I guess in hindsight, I already knew the answer to the question (similar to Neil and Ozz's answers) but what I'm really looking for are facts that I can use to convince management that we need to address quality concerns much earlier in artefact life-cycles.
    – Chris Snow
    Commented Feb 15, 2013 at 12:50
  • 1
    Tell them it will cost them money if they don't. That'll be enough.
    – Neil
    Commented Feb 15, 2013 at 15:22

2 Answers 2


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.


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.

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.