Ownership: Architecture

I talked yesterday about what happens when development teams lose ownership of the software requirements. In that, I mentioned that teams need to own their architecture and technology stack. Surely this is so self-evident it barely needs mentioning? Well, not quite. In fact, it's incredibly common for developers to be unable to influence any part of this.

The reasons for that vary, but it's commonly one (or more) of the following:

• A senior management ivory tower or remote head office that does not successfully interact with developers.
• Technical details presupposed by non-technical business/retail teams.
• Overly strict adherence to "the way it's always been done".

All of those reasons have one key thing in common. The decision on how to build the software is taking place away from the information which should drive that decision. Either through distance (the ivory tower), lack of domain knowledge (the non-technical), or time (the way it's always been done).

That last one is particularly important, as a lot of organisations don't think about it enough. The decisions you made yesterday may not still be relevant today - especially in development where they're often driven by time constraints, unforeseen events or external influences. Again, it's something which took place away from the point of most information.

I think development teams can sometimes be culpable in this, too. It's about that role of responsibility as a part of ownership - by abdicating your responsibility to design your project away to an ivory tower, vocal end users or the past, you also lose ownership of that design. When you have a lot of technical debt and bad development practice it takes courage to be the first one to stand up and say, "I don't think a VB6 client application interacting with a COBOL back end is the right choice for this project".

This might sound like a joke example, but the point is sound. As developers, we don't do enough to stand our ground, to point out that we're the experts and we know how these things should be done. It's our responsibility to listen to managers and business users to understand what they need, and to look to the past to address compatibility, but it's also our responsibility to say when an idea isn't appropriate for a project. It comes back to the point that development is a collaborative process; you're having a conversation rather than following a dictat.

Otherwise, we put ourselves at risk of building software with technology and architecture that isn't suitable. This leads to more time fighting the proposed solution than the problem, and ultimately the kind of shortcuts and "that'll do" thinking that arise in a team which isn't owning and taking responsibility for the software it develops.