Re: Why Distributed Teams don't work for startups (Mark Suster)

11 views
Skip to first unread message

Eskil Steenberg

unread,
Jul 8, 2010, 5:22:15 AM7/8/10
to game-studi...@googlegroups.com


On Tue, Jul 6, 2010 at 8:25 AM, Adam Martin <adam.m....@googlemail.com> wrote:
Like most of Mark's blog posts, plenty of food for thought in a concise post:

http://www.bothsidesofthetable.com/2010/07/05/the-power-of-in-person-why-distributed-teams-are-less-effective/?awesm=bothsid.es_6jI&utm_medium=bothsid.es-twitter&utm_source=direct-bothsid.es&utm_content=backtype-tweetcount


Not to say that Face to face has no value, but he is very much coming form a management perspective.

Software development is traditionally seen as something very hard to scale, where close collaboration between developers is very important. Managers have designed all kinds of methods for dealing with it (Scrum, agile... Full list: http://en.wikipedia.org/wiki/List_of_software_development_philosophies)

But the fact is that most developers are daily collaborating with developers they have never meet by using OpenGL, DirectX, Coca and other large code bases without any problems. You see, what management hasn't been able to solve has already been solved in the language, its called an API... Therefor I propose a API based approach to development.

Cheers

E


Adam Martin

unread,
Jul 8, 2010, 5:58:37 AM7/8/10
to game-studi...@googlegroups.com
Hmm. I think the term "development" is overloaded here, and your
points make that clear to me in a new way:

- Writing a few lines of code to fulfil a precise, static,
mathematical description
- Designing and implementing a binary that fulfils a problem, which
may be "fully specified" but is specified in natural language, and so
is fundamentally non-static and imprecise

I believe Mark's focussing on startups (he's a VC), so the vast
majority of tech workers he deals with are working on the latter kind
of problem - almost exclusively.

> --
> You received this message because you are subscribed to the Google Groups
> "Game Studio Manifesto" group.
> To post to this group, send email to game-studi...@googlegroups.com.
> To unsubscribe from this group, send email to
> game-studio-mani...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/game-studio-manifesto?hl=en.
>

Eskil Steenberg

unread,
Jul 8, 2010, 7:59:21 AM7/8/10
to game-studi...@googlegroups.com
Hi


Hmm. I think the term "development" is overloaded here, and your
points make that clear to me in a new way:

 - Writing a few lines of code to fulfil a precise, static,
mathematical description
 - Designing and implementing a binary that fulfils a problem, which
may be "fully specified" but is specified in natural language, and so
is fundamentally non-static and imprecise

I think this is the misconception. My opinion is that the later consists of many instances of the former and therefor you can take any big project and divide it up in to smaller modules that can be connected by APIs.

Secondly, i think my body of work proves that a single programer should be expected to be able to write more then "a few lines of code" without asking for help. In fact i think the later should not be too much to ask from any programmer.

Cheers

E

Adam Martin

unread,
Jul 8, 2010, 8:08:11 AM7/8/10
to game-studi...@googlegroups.com
On 8 July 2010 12:59, Eskil Steenberg <eskil.s...@gmail.com> wrote:
> Hi
>
>> Hmm. I think the term "development" is overloaded here, and your
>> points make that clear to me in a new way:
>>
>>  - Writing a few lines of code to fulfil a precise, static,
>> mathematical description
>>  - Designing and implementing a binary that fulfils a problem, which
>> may be "fully specified" but is specified in natural language, and so
>> is fundamentally non-static and imprecise
>
> I think this is the misconception. My opinion is that the later consists of
> many instances of the former and therefor you can take any big project and
> divide it up in to smaller modules that can be connected by APIs.

You're ignoring the decision-making that MUST take place, very very
frequently, for that sub-division to be done.

It's the the assesment of differnet options of "type 1" developement,
and the overall decision-making processs, that benefits from engineers
being face to face.

Without that, you tend to get products that are inconsistent, or
"technically correct, but fail to fulfil the overall desire". You see
it often with projects that were outsourced at too conceptual a level:
the client got what they wrote down, not what they asked for (and
DEFINITELY not what they wanted).

> Secondly, i think my body of work proves that a single programer should be
> expected to be able to write more then "a few lines of code" without asking
> for help. In fact i think the later should not be too much to ask from any
> programmer.

Yep, I think that's why Mark felt OK "assuming" that anyone in
"development" would be doing a lot of type-2 work.

Again, startups specifically : you can't afford people who don't do /
don't like type-2 work; they are a liability. (I have met and worked
with plenty of people like that; they "just want to code, and not be
bothered with "external" issues")

Reply all
Reply to author
Forward
0 new messages