First Ideas, then Software
Many core concepts related to software development performance have been addressed while writing about speed of delivery. Hopefully, it is becoming clear that speed of delivery is a localized effect and can't be generalized to all teams for all products. This final entry on delivery speed addresses the responsibility that engineers and product managers have for identifying how to best choose an architecture that allows the team to optimize speed of delivery and make good decisions about when to evaluate architectural changes to prevent a prolonged degradation of delivery performance.
In a previous post (http://bit.ly/1NwAD5) I suggested the difficulty of adding features depends on whether they are part of the domain originally considered while designing the application. This concept is similar to the idea of Frame Semantics (http://bit.ly/3WV2ZG) in Linguistics. Basically, a language evolves in the context of a certain environment, or domain, and is rooted in its own contextual concepts.
A similar notion surfaces when creating Domain Specific Languages (DSL). The programming language is constructed to represent a sub-set of programming concepts ideally suited to a domain, but consequently won't be as powerful or as flexible as a general purpose programming language. It also won't be as effective outside the domain it was designed for (for example, try using SQL to express advanced mathematic calculations).
Applications, created to address specific business problems, fall under the same principle. Luke Hohmann, in Beyond Software Architecture (http://bit.ly/2V18VA), said "Architecture determines the nature of change within the system. Some changes are perceived as easy; others are perceived as hard. When 'easy' correlates strongly with the desired set of changes that improve customer satisfaction or allow us to add features that attract new customers, we usually refer to the architecture as 'good'". A good architecture is one that makes changes easy. But difficult changes don't imply a bad architecture. They just imply that the changes aren't part of the semantic frame that was used when designing the architecture.
A development team needs to be able to view the changes they're making in the context of the original domain and decide whether the change is difficult because it is outside the original domain, or because the architecture isn't sufficiently designed for the intended domain. Then they can decide whether to "hack" a change, to modify the architecture, or to reject the change.
Ideas drive our architectural decisions because the domain the development team is operating in is comprised of the ideas product management filters from customer needs.
Software development teams can confound their own efforts to move quickly by choosing architectures that aren't well suited for the domain. Quality Function Deployment (QFD), also called House of Quality, provides a mechanism for creating the domain based on customer input and also provides a neat metaphor for incorporating technical decisions in the context of a product strategy. In QFD, the customer needs are enumerated as rows in a matrix, and the columns are technical "responses" to those needs (ie., the way the product will fulfill customer needs). The name "House of Quality" comes from the fact that the rows create a "roof" and the columns are "supports" for that roof. The domain of ideas, upon which the application architecture will be based, relies on each of the tactics as a way of fulfilling customer needs through the application ( http://bit.ly/3UHEbt). Often times, the speed of delivery is confounded by an additional feature that is too far removed from the semantic frame that originally defined the architecture
Development and Product Management have to work together to ensure that the domain space is aligned with the architectural space. Then speed of delivery can be measured consistently as long as the domain doesn't begin to shift away from the architecture. Product Management is responsible for understanding the domain space well enough to identify the semantic distance and providing the development team with feedback about the perceived effort required in business terms. Development is responsible for picking the right architecture and evaluating whether their own design decisions are contributing to a slow down in delivery speed.
