As a result of a retrospective we were uncovering worse ways of developing software. We had a idea we though was great and tried it. We stayed with it during the development of a major update which took 3 months. After a retrospective with the maintenance engineers it turn out our idea does not work for them (we had discussions with them before we tried the idea and the also thought it was a great idea). We came to the agreement we better get back to the old situation. The team for the update is dismantled and the maintenance engineers don't have time to do so (although their project manager has agreed to invest the time).

We're now in the situation the maintenance engineers pay the interest each time a minor release has to be made. This is very much like technical debt but has nothing to do with the product itself. Is this called process debt or is this put under the term technical debt? And what would be a good way of dealing with it? (Any other or concrete ideas to make it visible to product managers?)

PS The idea was migrating a 4 product VSS database to SVN. The database heavily leans on shared files and is a mess to untangle and pour in a usable SVN structure. It's very counter intuitive but is seems some things are better kept in VSS.

  • 2
    I'm not sure I follow. Could you please be so kind as to give us a better outline of the process? Bullets would help...
    – yannis
    Jan 18, 2012 at 7:40
  • 2
    Seems to me that the problem is the migration from VSS to SVN was not actually completed before the handover. That's technical debt, not process debt. Jan 18, 2012 at 11:28
  • Process is a reaction to prior stupidity...
    – Newtopian
    Jan 19, 2012 at 7:50

5 Answers 5


I hope I have interpreted thing correctly, I would call this technical debt. Software consists of more than just source code. Source is probably less than 10% and no more than 20% of the SDLC effort (At a commercial level at least). If you cannot reliably and easily build and deploy your source code, causing problems and costing money down the track, it's no different to source code that is hard to maintain, buggy and slow.

The fact you tried something different and it was not as good as what you left behind does not change things either. The software is now in a less maintainable state than it was previously, because of chosen technologies (VSS vs SVN) - technical debt.

The Process Debt you refer to undoubtedly exists, but that's due to the process making you do things that are no longer required. For instance if you had a process that required manual running and markup of a printed test book on each release, but you had implemented automated testing, that would be process debt, as it's something that is no longer relevant due to changes in the way things are done.

  • Not sure I agree with the 20% figure. Are you counting time designing, planning and mapping out architecture in your 20% ? That takes up the majority of my time Jan 18, 2012 at 11:06
  • @TomSquires The 20% figure sounds right for the act of writing code. Architecture, design, and planning isn't writing code. I come up with about the same figure (15-20%) looking back on past projects, assuming that code includes production code, test code, and build/deploy scripts. The other 80% of the time is requirements, architecture, design, documentation, planning and coordination, domain research...
    – Thomas Owens
    Jan 18, 2012 at 12:43

Process "debt" can't exist and certainly can't accrue.

You have a "gap" in your process where team B is doing "more" work because team A is doing "less" work.

This doesn't accrue. It's just a shifting of the workload.

If something is accruing , then a year from now, team B would have a huge backlog of things to do. Wait. That's a backlog of technical work. That's what technical debt is.

A "process debt" would be a backlog of process steps that must be executed. Checkin-Checkout? Email updates that something's about to change? That's silly. And not very Agile, either.


It sounds like you are describing muda, waste from Lean software engineering. Obviously, you want to reduce waste as much as possible...


Not an answer to the direct question, but one to solve the VSS problem:

I migrated a VSS DB to SVN a few years back, we had a fair few shared files. It was horrible. So I identified these files and moved every one of them to a 'common' directory (thankfully we didn't have files that were shared all over the place between arbitrary projects, well not many).

Once they were placed in a common folder away from the projects, they could be fetched and updated using SVN's externals feature, and the project workspaces could be updated to reference the shared files in the shared file folder. From that point on, the code became a lot nicer and there was a lot less breakage when 1 file was changed that affected an unrelated project.

  • We do the same thing but with 90% of the files shared, it just doesn't seem to work out for us. In the common there also needs to be a split for different hardware configurations that we haven't made yet.
    – refro
    Jan 23, 2012 at 15:29

The problem here isn't that your software is more suited to version controlled in VSS as opposed to SVN and the resulting "process debt" as a result.

The problem is that your software has a design flaw that encourages poor practices and creates significantly more work for the team in the long run. This is essentially technical debt not as a result of poor implementation necessarily but as a result of poor design.

The design flaw is that feature work cannot be adequately split up amongst developers without running into significant merging issues with a handful of files that change frequently by a number of different people. Certain frameworks of course lend themselves to these kinds of problems, Struts (), ASP.NET (web.config) etc... however merging on a large scale has been one of SVN's weaker points. Perhaps Git or Mercurial would be better suited to your project and help mitigate this problem.

  • Awful answer, sorry
    – Murph
    Jan 18, 2012 at 12:54
  • 2
    git or mercurial wouldn't solve the 'shared files' problem. A problem unique to VSS AFAIK. (which is like your SCM allowing hardlinks of files, so if you change a file in projectA that was shared with projectB, that file in projectB also gets changed at the same time automatically). Yes, its horrible, but it's VSS.
    – gbjbaanb
    Jan 18, 2012 at 21:32
  • Actually shared files are not horrible - losing them (when I moved to something else) was something of a wrench. What they are is not the way we do things now... but I used them in the same as sub-repos/externals (sharing arbitrary files would be a nightmare).
    – Murph
    Jan 22, 2012 at 18:24

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.