“Changes to one team’s service may be implemented by another team who needs the enhanced capability by what is called an Away Team. This team works on the Home Team’s code to add what it needs according to established engineering standards and then leaves that code in good order to be maintained by the Home Team who owns the service, with help when needed.”
Fully embedding your team in another team’s context to get something done, seems to me a very interesting compromise between autonomy and collaboration. Every team is an island, but it is ok to travel to another island and if that’s not possible, you can still build your own.
Also more than disorienting to see an in-depth piece about engineering organizations like this appear on The Register.
Putting an entire team in another team’s context is something I have considered for all the collaboration, delivery, culture etc. benefits that it will most likely yield in exchange for a minor hit in delivery.
Many years ago I suggested building in async facilities into Django. I got ridiculed for that both for technical feasibility (rightly) and necessity (short-sightedly). Now finally we have a proposal to build those features into the framework that demonstrates the same need and that can be implemented.
The newsworthy thing about the Accenture/Hertz story is not that they failed to deliver but how badly they failed and that they are getting sued for it. Getting something that’s not very good for far too much money is an accepted part of doing business with consultancies of that size.
A clear write-up of how GOV.UK kept things running smoothly while their petitions website suffered an immense rush of signatures.
Zoom is an excellent video-conferencing app which turns out to be built on some technical excellence of its own (running WASM encoders and decoders in the browser).
Some amazing work by Morten Just turning a phone into a 3D mouse using all the sensors that it has embedded in it. This is mindblowing and hints at all the things that are already possible using the technology we have.
Most of my programming career has been focused on keeping things simple and eschewing premature abstractions summarized aptly by: “duplication is far cheaper than the wrong abstraction”
Existing code exerts a powerful influence. Its very presence argues that it is both correct and necessary. We know that code represents effort expended, and we are very motivated to preserve the value of this effort. And, unfortunately, the sad truth is that the more complicated and incomprehensible the code, i.e. the deeper the investment in creating it, the more we feel pressure to retain it (the “sunk cost fallacy“). It’s as if our unconscious tell us “Goodness, that’s so confusing, it must have taken ages to get right. Surely it’s really, really important. It would be a sin to let all that effort go to waste.”