4 ms·

Contracts (APIs, interfaces) imply both parties understand what is being exchanged. The process of developing a contract helps each party figure that out and ex

Contracts (APIs, interfaces) imply both parties understand what is being exchanged. The process of developing a contract helps each party figure that out and express it concretely. Downstream, on one side of contract, as you develop and test, you may find that you understand the problem differently. Then the contract becomes a constraint. This organizational model then requires that parties revisit contracts if needs on one side or the other change. That still looks like coordination. Perhaps the win is just less frequent, more focused coordination. We still need a common picture of "what", just now as expressed through contracts. I like the peer bob1029 post on consistent labels, in that way. The other decoupling to consider would be "when" - how can we work in parallel with minimal synchronization and blocking?

kqr 5y ago
> how can we work in parallel with minimal synchronization and blocking? This is something I'm very interested in at the moment. Trying to read up on how good development organisations do it, but I'm partly coming up short. I know a Ward-style lean approach of web-based concurrent engineering involves these things: - Brainstorming up multiple potential ways to break the system into subsystems, and exploring those in parallel. - Negotiating over interfaces. "If I give you that endpoint, how will you use it to improve the product?" - Specifying ahead of time which subsystems are inflexible and which are flexible. If an inflexible subsystem has an interface demand, the flexible subsystems have to comply. They, of course, are prepared for this and have explored several variants of their interface. - Exploring several implementations exposing the same interface. The main thing I don't get is that this is presented by Ward as a cheaper way to do development, because the subsystems are -- when all is said and done -- virtually guaranteed to integrate cleanly, and by exploring many options in parallel at all levels the risk of failure to deliver on schedule is virtually zero. But... that parallel development of alternatives sounds really, really expensive. Like more expensive than blowing the schedule by a fair amount. I understand not all the work is wasted -- there's useful learning that happens in exploring an alternative even if it doesn't end up being used. But still! Reinertsen argues for a more fiduciary view where the number of parallel alternatives to be developed must be balanced against the economically defensible level of risk reduction, but it gets somewhat abstract for me at that point. Can you really apply that logic at all levels in the organisation? Does it get easier with experience?

kqr 5y ago

> how can we work in parallel with minimal synchronization and blocking? This is something I'm very interested in at the moment. Trying to read up on how good development organisations do it, but I'm partly coming up short. I know a Ward-style lean approach of web-based concurrent engineering involves these things: - Brainstorming up multiple potential ways to break the system into subsystems, and exploring those in parallel. - Negotiating over interfaces. "If I give you that endpoint, how will you use it to improve the product?" - Specifying ahead of time which subsystems are inflexible and which are flexible. If an inflexible subsystem has an interface demand, the flexible subsystems have to comply. They, of course, are prepared for this and have explored several variants of their interface. - Exploring several implementations exposing the same interface. The main thing I don't get is that this is presented by Ward as a cheaper way to do development, because the subsystems are -- when all is said and done -- virtually guaranteed to integrate cleanly, and by exploring many options in parallel at all levels the risk of failure to deliver on schedule is virtually zero. But... that parallel development of alternatives sounds really, really expensive. Like more expensive than blowing the schedule by a fair amount. I understand not all the work is wasted -- there's useful learning that happens in exploring an alternative even if it doesn't end up being used. But still! Reinertsen argues for a more fiduciary view where the number of parallel alternatives to be developed must be balanced against the economically defensible level of risk reduction, but it gets somewhat abstract for me at that point. Can you really apply that logic at all levels in the organisation? Does it get easier with experience?