Why Remote Engineering Is So Difficult
blog.learningbyshipping.com
Why Remote Engineering Is So Difficult
1–10 of 43 posts
Re: Why Remote Engineering Is So Difficult
#2The more interesting thing about this story is how all of the examples
are tied together in an already well known way stated by Fred Brooks in
his 1975 book, "The Mythical Man-Month". You may have heard the adage
of how adding developers to a late project only makes the project more
late. The reason is communication overhead. One developer can produce
some number of lines of code in a given day, so you'd expect adding more
developers would result in more lines of code being written --
essentially O(N). Unfortunately, there is communication overhead and it
increases complexity at O(N^2) as well as being an even bigger drain at
the start when bring new developers up to speed with the existing group.
If you take a step back, all of the remote working patterns presented in
the article as working are essentially ways to eliminate the need for
communication.
Re: Why Remote Engineering Is So Difficult
#3I think it's almost impossible given human biology to expect excellent architectural/engineering decisions from remote teams. You need the in-the-flesh discussions, whiteboarding, leadership, etc.
Re: Why Remote Engineering Is So Difficult
#4Results oriented work environments force goals and processes to be written down and made explicit. Heavy reduction of tacit skills and information is extremely difficult and expensive, though it may result in more robust outcomes.
Re: Why Remote Engineering Is So Difficult
#5I think it's almost impossible given human biology to expect excellent architectural/engineering decisions from remote teams. You need the in-the-flesh discussions, whiteboarding, leadership, etc.
So then, how does FOSS fit into your notion of human biology?
Re: Why Remote Engineering Is So Difficult
#6I think it's almost impossible given human biology to expect excellent architectural/engineering decisions from remote teams. You need the in-the-flesh discussions, whiteboarding, leadership, etc.
So then, how does FOSS fit into your notion of human biology?
Good model for maintaining an existing codebase, but not for designing good ones from the ground up. It works best with a singular leader (or geographically centered leaders) who can make the overall architectural and engineering decisions.
Re: Why Remote Engineering Is So Difficult
#7Very interesting food for thought here, but the difficulties of remote engineering are not fundamentally any more challenging than any other collaboration obstacles. Obviously having all the stakeholders sitting in the same room is the platonic ideal of a team, but to me this is a secondary concern after getting the absolute best people we can.
I think the author is a bit out of touch with how startups operate. Personally I'll take a crack team made up of five best people sitting in San Francisco, New York, Berlin, Bangalore and Tokyo over a special team with a powerful corporate mandate ensconced in Microsoft's Redmond campus.
If everyone is good at what they do and has their eye on the ball, then communication can be managed from anywhere, but if you're dealing with the political reality of operating in a major corporation then you need all the help you can get.
Re: Why Remote Engineering Is So Difficult
#8It's easy to say that communication is key, because it is, but all else being equal, if your team can't execute projects in a distributed, remote environment as well as it can in a centralized place, then it's not as good at communicating as you think it is. Dragging a failing remote team into an office isn't going to magically make them successful, and scattering a successful team across the world isn't going to suddenly make the project fail.
I personally find the very disconnected nature of the teams I lead in my consulting work actually forces us to communicate in an open, concise, discoverable way that would be good for any type of team, but that co-located teams get to cheat out on because a weak team member can always ride his stronger teammates' organizational coat tails with nosey interruptions and annoyances.
We have to think things through and write clear specs, because we can't use body language to clarify and count on the people involved in the meeting to just remember the attitudes expressed. We have to be good about change management, because we can't just turn around and ask someone to "get out of a file" or do whatever we want to the database whenever we want to. We have to keep meetings to a minimum, because you just can't have a productive, two-hour phone call.
These are all good things for non-remote teams, too. But they cheat and don't follow good practice.
Re: Why Remote Engineering Is So Difficult
#9> If I had to sum up all of these in one challenge, it is that however you find you can divide the work across geography at a point in time, it simply isn’t sustainable. The very model you use to keep work geographically efficient are globally sub-optimal for the evolution of your code.
I think this is true of any organization, geographically divided or not. These are the challenges of organizational structure, and I've seen them affect organizations in a single location just as much as organizations with remote engineers.
In my mind, the single most important thing to do is to re-evaluate and adjust the structure early and often. The way you divide up work today will almost never be sustainable - regardless of geography. The trick is to help everyone understand and expect those changes to occur frequently.
Re: Why Remote Engineering Is So Difficult
#10I believe the key to making remote work work is that everybody has to work remotely, or as if they were remote. If you have meetings and other communications happening face to face, then the remote people, to a greater or lesser extent become Cowboys, through no real fault of their own.