Programming environments: what I've learned

[I D Shukhov]

The fewer programmers the better.

Big projects:  > 20 programmers are the worst.  The best project I worked on was with 2 other people.  Big projects are more structured with many more levels of management.  The many programmers will always feel under a magnifying glass and competition and one-upmanship will be rampant.

Working alone can have its problems too

This can feel a little like solitary confinement:  just you and the code.  Day after day with nobody to talk to.

You want the least amount of oversight possible.

The closer managers are to your work, the worse the job will be.  That includes distant and "hands on" task managers.  The best managers are completely absent, ask for weekly status reports, and only show up at demos.

Beware of "strong" task managers.

Beware of "lead programmer" types.  If there is a designated leader, you want somebody who doesn't have strong ideas about the "right way to do something".  You may be able to ascertain this by asking to speak to the person and talk to them about programming.  Such people can make your life miserable and stunt your development. 

Sometimes maintenance work trumps new development

Yes, maintenance is tedious, but new development often brings out the a$$hole nature in  programmers given the pressure to get a working product and the opportunities for one-upmanship.  Maintenance, on the other hand, is humbling and slower paced.   This can be rationalized as "I'm only doing this to pay the bills...", but months can turn into years and decades.

Death marches and suicide missions

Mostly this has to do with unreasonable deadlines either because of something fictitious as a management technique or an actual serious mistake in planning or misunderstanding of the work that needs to be done.   There doesn't seem to be too much of this in government contracting (the government is probably used to things taking forever and fund projects with this in mind), so I don't have too much experience.  Has anyone read "Death March" by Edward Yourdan?  Any way to detect these ahead of time?

[Peter Gibbons]

Good points.

I also think that 2 or 3 people teams are the best.

Incidentally most of the time I worked with one or two people.

I never worked as part of large team. 7 or 8 I think was the max.

Working alone as you said has challenges too. Maybe the solution is to engage the users early to get feedback and some positive reinforcement.

[Walter Mitty]

I think 7 person teams are the best.  The best team I ever worked on was 5.  We specialized in areas of the project.  The nearest thing we had to a leader was more of a mediator than a determiner.  We all wanted the project to succeed,  and we each wanted out onw piece to be as simple as possible, but not simpler than that. 

[David Randolph]

A death march is almost impossible to detect prior to actually starting on it. The most important criteria that I found was when the deadline stays the same, but the requirements are constantly changing. That is something that you can only find out as you start the project. I chose to abandon ship at that point.

[Walter Mitty]

A death march is almost impossible to detect prior to actually starting on it.

I disagree.  While there are unforeseeable events that can turn a valid project into a death march,  there are certain flags that some projects show before they start that just about certainly guarantee that it's going to become a death march.

One flag is this:  "We expect 110% from our people, all the time".  That's a flag for a death march. 

Another one:  Excessive reliance on untested technologies or methodologies, to meet a schedule that classical methods would have required three times as much time.  Death march ahead.

A third one:  there are no married people on the team.  Death march, most likely.

This last one is a yellow flag, not a red flag.  If I think about it maybe I can come up with a few more red flags,  and lots of yellow flags.


 

[ilconsiglliere]

My 2nd job at the big phone farm started out very collegial. There was about 6 of us in the group including the project leader. The project leader didnt care how you did it as long as you delivered. It was very B*ll Labs-ish. We just worked at our own speed when we wanted and they didnt care how we did it as long as we met the date.

Than we got a psychotic manager that ratcheted up our release schedule from 4 times a year to 6 times a year to once a month. He decided we were an assembly line. This coincided with the psycho manager increase the staff to about 30 developers.

That is when the death march started.

He invented this new term called "concurrent engineering" in my organization. It meant that the analysts were writing the requirements at the same time as we were coding and that multiple releases happened simultaneously.

For example say you had release A, B, C in that sequence. This meant that all releases were being worked at the same time and that B had to incorporate A's code in their work and that C had to incorporate A & B's code in their work. Keep in mind that the code may not have been tested and may not work. It led to huge amounts of defects, fragmented code and version control nightmare. After about a year I requested a transfer out.

This was my last job coding. My next job was as a DBA which was almost as bad. Since than I never code, ever.

[Walter Mitty]

Beware of "strong" task managers.

Strong leaders are well matched with weak followers. 

But I don't quite agree that the best managers only show up for demos.  But I think the best technical leads are those who know how to use influence rather than either intimidation or control.   In order to use influence, you have to give up on the idea that you're always going to prevail.  You aren't always going to prevail, even when you are right.

But when you do prevail, you really improve things in a fundamental way. 

This isn't a touchy-feely "let's all sit down and sing kumbaya while we code" kind of sentiment.  There are people who know how it should be done better than other people.  They tend to be older, just because it takes time to learn this stuff.  But they can't be too set in their ways either.  (That's my weakness).

[Carrie Cobol]

I don't know, I've been in a few outfits where the tech lead produced stuff that gets posted in Daily WTF and insisted their way was best and there was no talking them out of it.  In those cases a strong lead is a bad thing.  Combine that with a hands-off manager and it's a recipe for disaster.

[I D Shukhov]

I don't know why companies aren't more adventurous in trying small team structures besides the boss-subordinate model.   Teams should be able to figure out how to govern themselves.  Of course there's going to be different levels of capability and experience within a team.  I believe in different kinds of abilities, so while technical achievement should be rewarded primarily, social traits like friendliness and humility also need to be recognized.  The soft skills are important for team synergy and are therefore valuable.

If a team can't figure out a reasonable way to manage themselves, then there must be templates around they could use.

[The Gorn]

I don't know why companies aren't more adventurous in trying small team structures besides the boss-subordinate model. 

For the same reason that companies use preferred vendor lists rather than dealing with individual vendors. In exchange for optimizing special cases, the business takes on a new risk of small teams that are not aligned with the whole.

Most businesses favor consolidation, and most businesses are autocratic and don't trust the underlings. All of this " Teams should be able to figure out how to govern themselves" gets away from consolidation of power.

[I D Shukhov]

I don't know why companies aren't more adventurous in trying small team structures besides the boss-subordinate model. 

For the same reason that companies use preferred vendor lists rather than dealing with individual vendors. In exchange for optimizing special cases, the business takes on a new risk of small teams that are not aligned with the whole.

Most businesses favor consolidation, and most businesses are autocratic and don't trust the underlings. All of this " Teams should be able to figure out how to govern themselves" gets away from consolidation of power.

A business would need to ask itself:  "Are self-managed teams more effective than traditional task-leader teams?"   To answer this question some manager in the organization would need to review the existing information on the subject and maybe try an experiment.  There must be record of these types of teams in our industry.   Google is always being held up as being progressive.  How are projects organized at Google I wonder?

I don't think that measuring team effectiveness would need to be that complicated.  As long as the experimental team got its work done I'd judge it as being effective.  After the project is over the members would be asked to rate the experience according to how much they learned, how well the team performed and how happy they were.

[Origisaurus]

Somewhat eerily, I was just now touching base with my "9/11 team".  It was our fifth day on the project, and we didn't know each other that well.  The titular leader was hopeless as a delegator and utterly lacking in social skills, a control freak.  The team self-managed in the sense that we mostly worked around the leader.  May have had something to do with our average age of about 50, all with at least 10 years in contracting. 

Teams can self-manage, but you need to start with self-managing (self-actualizing) people.  You don't toss your kid into the deep end of the pool and expect him to swim without some training, and you don't gather a random collection of "professionals" and say "go forth and self-manage".

The team was from all over the country and we never saw each other after that project.  Sent 7 emails on Wednesday, 4 bounced, 2 answered promptly, and I have no expectations either way for the seventh, you guessed it, the "leader" to respond.

[Walter Mitty]

I don't know, I've been in a few outfits where the tech lead produced stuff that gets posted in Daily WTF and insisted their way was best and there was no talking them out of it.  In those cases a strong lead is a bad thing.  Combine that with a hands-off manager and it's a recipe for disaster.

Um, when I said that strong leaders are well matched with weak followers,  I should have included some kind of irony alert.

What I really meant is this:  if a strong leader is placed where no strong leader is necessary,  that's a recipe for disaster.  If a strong leader is placed where all the followers are weak,  that's a recipe for disaster, because of the weak followers.