No Matter What They Tell You, It's a People Problem

Bruce Eckel deftly identifies the root cause of all software development problems:


This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2008/01/no-matter-what-they-tell-you-its-a-people-problem.html
1 Like

So very true. We once lost this awesome guy at my last job (he went to some Vertigo company) and work became just so aweso.

The quality of people and how you mesh/clash determines happiness.

It’s what you know and who you know. The who you know trumps what you know. Get the people on your side.

How might your project go if everybody was on your side?

Don’t forget that this goes all the way up the management ladder. There’s certainly a discount factor for each level up, but that truthy saying still applies.

Not all development environments are created equal. At one firm you may be able to pick and choose individuals to work with and will possibly be successful. At another you may be forced into a group of people you don’t get along with at all and have no say in the matter: “Stop arguing and get it done.”

Hm… wel written.
This is such a simple thing that it must not be written about at all. We all need to know this stuff.

I completely agree with this. I think it’s just a universal truth rather than specific to programming. I don’t even work in software development, but any project I am tasked with or simply my day-to-day duties successfulness are determined by:

How well have I planned today (or this project) prior to starting?
What is it that I’m trying to accomplish, when am I done?
Do I get along with my co-workers?

Jeff, I have to agree. I wrote a similar article recently about the importance of the people in a team: http://shipsoftwareontime.com/2007/11/12/building-a-great-team/

one reason why I like this blog is that you often write about something what I was just exactly thinking a few hours before. I’m sure there are plenty other developers feeling the same and that’s why is your blog so popular.

I’m an actuary (and part time developer) in a large consulting firm, and I see this working there, too.

I also spent a lot of time researching how to make our spreadsheets safer and more accurate, and the answer I found was to make them easier to check (simpler, clearer, consistent, etc), and having a strong culture - all of which comes back to people, not technology.

“What’s stopping you?”

Well, (not me personally), it’s LOTS of things:

  • companies hire people that are jerks, and hide them from you in the interview process only to be unleashed after you accept an offer

  • companies hire people who are “properly” emotionlessly professional as managers, and you think that once you get to know them and work for them they will be pretty cool

  • companies hire lots and lots of people with form but very little function, who use words like “collaborate”, “user experience”, and “systemically”, and cause your heart to shudder and cringe

  • companies reward people for the wrong things, and not often enough for the right things

I could go on, but perhaps that’s why I work for myself. The best job in software I had lasted from 1986-1990, and it hasn’t been matched since. Now THAT’S a freaking shame…

I think Alistair Cockburn rules! He has done what one should do, and that is to compare realworld projects and their methologies.
http://itc.conversationsnetwork.org/shows/detail175.html

Things are the way they are because they got that way … one logical step at a time.

Wow, someone must have had a blessed career to think that. Most of the disasters I end up fixing are due to people not putting any thought into the things they do at all, let alone logical thought.

If you don’t get the processes right, you are in trouble.

“Individuals and interactions over processes and tools.”

http://www.ambysoft.com/essays/agileManifesto.html

It is possible to go to far in either direction (heroics) but I think it’s important to have some perspective: process doesn’t write code. People do.

In Weinberg’s writings, there’s more to the “people” aspect than whether you like your coworkers or not. There’s the way organisations are set up and how different people will view the business using quite different preconceptions.

A reoccurring theme is to look at the system as a whole, starting from the viewpoint of the “Helpful Model” - that people are trying to be helpful according to the way they see things, which may well appear as if they are being very unhelpful from one’s own viewpoint.

So my own people-oriented criterion for project success is “is what you are trying to do reasonably well-sligned with the way that people interact in the organisation?”.

Part of this is whether your own personality fits into the wider culture well. For instance I personally like having a reasonable autonomy, for people to act in a generally agreeable fashion to each other (particualrly if they are at different levels of the organisation’s hierarchy), and trying out fresh approaches to problems. This makes be a good match for some organisations, and a terrible match for others. Whether I like my co-workers is not quite so relevant.

I agree.

If you work with people you like (and I do) it’s easy to say things like “I don’t know how to do this. Can you help?”, or “I think you did that wrong. Let me show you how.”, or “Dammit, I screwed up: how do we fix this?”

Also, with the right people, process can be fixed.

The right process cannot, however, fix the people.

By one study, using the Myers-Brigg (MBTI) personality catgegorization system, the most effective software team were composed of Extroverted (not Introverted) programmers, a Feeling (not Thinking) manager, and a Thinking architect. My own personal experience would suport the belief in extroversion as being important in software teams. On one team I was the leader of, the extroverts shared information and worked together while the couple on introverts on the team lacked initiative, rarely got involved, and generally did not share ideas.

I agree with this on the whole, however, there are some cases where the line between people and technology blurs.

This is more related to larger organisations, technology can help remove mistakes caused by people, like the obvious build and deployment tools or code repository’s.

Where tasks can be automated and simplified, reducing the need for communication between people, then technology can have a huge impact on the ‘success’ of a project. But perhaps some would count that as process, rather than technology?

The editor of c’t (big german computing and technology magazine) recently wrote “Time is to valueable to hang in the wrong places” … that’s correct but what defines the right places? The people you find there!

so … Time is to valueable to hang with the wrong people!?