I've always had a clear vision of how code ownership should look alike:

  • each piece of code should be owner by 1 team
  • code should be divided domain-wise (not tier-wise, so no "component teams", please)
  • responsibility of the owner is not only for writing code, but also deploying, troubleshooting, supporting & maintaining as well
  • in terms of testing - the owner team is responsible for testing their piece & all the junction points with other "modules" (or whatever else is it interfacing with)

And I was fully convinced that this is the best approach to code ownership - because as team knows it's stuck with the piece of code for good:

  • it helps with motivation for continuous improvement (or decommissioning ;>)
  • it's always clear who to reach to when you need info about that part of system
  • as split is functional (domain-wise), all the tiers are covered so team can pretty independently perform "full-spike" changes

Banzai. Simple & clear. All you have to do is execute.

And then I've read a book (you can find my review here) with a horrific title Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum by Craig Larman & Bas Vodde (creators of LeSS). And this book has made me thinking. That's a short version, actually something like that has happened:

{ reading the chapter about Feature Teams }
{ gasp }
{ page turn - forward }
{ reading further }
What the F&#K?!
{ page turn - back }
{ re-reading a paragraph }
{ page turn - back }
{ re-reading last 2 pages }
What the ACTUAL F&#K?!

Yes, pretty much like that. So, what do the authors say? What has made me swearing aloud (& people around fleeing) in the public bus like that? ;D

Codebase of whole product should be shared by all the feature teams (who are cross-functional of course).

Before we get through to rationale (& whether I agree or not), let's try to find out what may be the weak spots of my previous approach (the one above):

  1. Let's take the functional (domain-wise) split in multi-tier application. If it's really possible, why not to treat them as separate products with separate owners & forget the whole scaling Agile thing? The key point is that in many case the reality is much more brutal than theory - either because of historical decisions, different technologies, multi-purpose character of some tiers or just because of how the domain looks alike - it's not possible to make a coherent split for all the tiers. You can fool yourself that it's all about refactoring, but is it really soothing that you have to re-write half of your tier applications?

  2. Let's assume you've somehow managed to make the initial split -> you've got functional split for your functional teams. But what about the amount of work they will get in their areas? If two areas are similar in terms of lines of code or even code complexity, but one of them gets more Business attention these days while the other one no-one cares about for now. One Product Owner will have his high priority items queued for several months, while the other one will have no choice but to find out some nice-to-have stuff to do for his bored team? That's suboptimal.

Bold points, don't you think? Ok, it's high time to get back to the approach proposed in the book, so we can see whether these problems are solved there:

[Book]: Any team can get any workitem to do. Actual business priority truly decides about the development order ...

[My Voice of Reason]: WAIT! We have a large system, developed during many years by tens (at least) of developers - they can't know every corner of the system! How will they know what to actually do?

[Book]: But why don't they? This way they don't have the incentive to make a clear, navigable code. And, in a result, smart, talented person keeps working for years on the same 30 files - isn't it what makes the work boring & limits the personal growth? And such a person gets used to that easily, so (s)he rings a bell once (s)he has to leave this comfort zone. Actually, working with other people code is a critical skill that you can't let vanish.

[MVoR]: But doesn't it mean various teams will change the same pieces of code in the same time?

[Book]: Continuous Integration is a key here. Branch as late as possible is another important practice. Embrace feature toggling (releasing disabled code) as well. And of course all of this covered with a thick layer of automated testing sauce ;D

[MVoR]: What about the code quality? Developer modifying function X doesn't know who will modify it next & whether (s)he will keep the same coding style, level of quality, etc. Won't such developer make his change at least cost, without caring about future consequences?

[Book]: Focus. This approach doesn't mean NO code ownership. It means SHARED code ownership for all teams. It's teams' responsibility to eliminate such issues, because it pretty much means shitting in the own nest. If you're desperate, you can appoint code custodians for particular components -> as a source of advice & feedback for changes.

[MVoR]: What about troubleshooting, support, maintenance? Who does that & how are the incidents split between teams?

[Book]: Rotating these duties seems like a very good idea.

Current status

I can't really say I'm fully convinced, but this whole thing has made me thinking.

  • authors emphasize the need for automated testing A LOT - lack of such automation MAY be a show stopper (& what then?)
  • high level of technical debt / coupling could be a pain as well, but maybe this approach is a better solution to fix such problems?
  • won't teams riot, because of ripping them of their comfort zones (by forcing to work with code that may be uknown to them)?
  • what about efficiency of development? won't programmers triple-check / penta-check their work, just because they feel much more insecure now?

Hmmm...

Pic: http://mapa.targeo.pl/

Share this post