COVID-19 drove many workers home, and now many companies are trying to reel those same workers back to the office. Is this smart?
Answer: (as always) It depends. I’m going to talk a bit about this today from the point of view of software evolutionary pressure, rather than the more common (but perhaps more important) human factor.
I’ve been wrangling remote software dev teams for the majority of my career. Distributed development only works when your software is structured the right way. For most developers, that means splitting up the code itself along team lines. This is actually a good thing for software structure, as the distribution of teams acts as a social, structural force encouraging the software design along microservice, or at least less-monolithic lines.
In most modern situations, you want to be able to iterate your code – that’s a philosophical underpinning of Agile. The closer in time (zone) and space your teams are, the easier it is to do the collaboration needed to continuously iterate and publish iterations, and the contra positive is true as well. It’s not impossible to have a spatially-distributed team – in the last several years I’ve worked with a couple of teams smeared across a dozen time zones. It just gets significantly harder the further the team members are from one another. People end up having to reorient their circadian rhythms to match that of other team members half the world away, and this takes a toll on immediacy of the back-and-forth discussions you need to evolve your code.
Creating relatively stable interfaces in your software allows you to break up the work in a more natural way – teams stick to iterating work on either side of their API – at the cost of creating what Dr. Who might call fixed points in time and space, as the interface points are by their nature resistant to change (without adding yet more infrastructure like Azure API Management and its ilk).
In some ways, co-located teams which are physically capable of acting as single mega-teams can lead to more monolithic systems overall. Without a lot more work at the architecture level, it’s tempting to have little shortcuts pop up between subsystems which really ought to be more separated (especially true for SaaS). Managing primarily with remote teams and teams of teams, the only way I found to be truly effective was to break the software itself up into chunks with stable interfaces in between.
If you look at pre- and circa-COVID statistics (https://www.bls.gov/opub/btn/volume-13/remote-work-productivity.htm), there is a measurable increase in productivity for data and computer systems design (i.e. software) coinciding with an increase in remote work. I would assert that at least part of this is contributed to by changes in software structure.
What do you think?