Your questions raise the issue of culture and organisational structure.

A company focused on people will have a much more committed workforce than one that is focused on process or products. That's a truth that underpins things like 'outside-in thinking' and focusing requirements on problems (value) rather over features (things.)

What can you do to try to maintain that cultural focus on people?

The answer is leadership at the top, and leaders in local areas within larger organisations. We can -and should - all take responsibility for taking care of people.

Organisational structure - reporting lines, grouping of functions and incentives - can all get in the way of our desire to work with people for people. And that's the mark of your leadership. How well can you resist the short term disincentives around you? It can be very hard when you are a lone voice.

The best anwer I have found is to surrond yourself with like-minded people. A community is stronger than an individual and more abole to effect change (or maintain the staus quo.)

If there isn't one where you work? Move. Or build one, one person at a time.

> And to the comments; > > If you go to the on-line places where aviation software> developers and their ilk hang out you may well find that> they are using XP, TDD etc.> > I guess it's not a big effort to go and ask. The answers> may be enlightening. At least several major aviation and> defence have been using these techniques since the 90's.

My best friend worked on the radar system for the Blackhawk helicopter. If they are using agile, Sikorsky has done a 180 on everything they've ever done for software development practices. I suppose it's possible. I don't personally know anybody that works there anymore, though.

> And to the comments; > > If you go to the on-line places where aviation software> developers and their ilk hang out you may well find that> they are using XP, TDD etc.> > I guess it's not a big effort to go and ask. The answers> may be enlightening. At least several major aviation and> defence have been using these techniques since the 90's.

Can you provide a reference? And if so, are they using it to build onboard computers or are their internal websites (or similar.) The cost of a single iteration in defense and aviation can cost billions of dollars and the cost of the software developers is a tiny fraction of that. I find it highly unlikely that they are building prototype after prototype and watching them crash and burn. Perhaps against simulators but there's a big difference between running software on software and running software on something that is flying in the air.

> And to the comments; > > If you go to the on-line places where aviation software> developers and their ilk hang out you may well find that> they are using XP, TDD etc.> > I guess it's not a big effort to go and ask. The answers> may be enlightening. At least several major aviation and> defence have been using these techniques since the 90's.

XP, TDD etc. might be just under consideration for development in the embedded systems sector which is the domain we are talking about. Embedded systems development faces special challenges and there aren't simple universally applicable methods so far which are reified and can be just plugged like XUnit frameworks. Embedded developers often use a mixture of debugging + black box testing with tests provided by dedicated test developers who do not verify APIs but validate the complete system ( or at least parts of it ) against specifications.

It should be clear that this isn't quite optimal. Development practices are often superior in business / enterprise programming whereas blackbox testing practices are more exhaustive in the embedded sector. Polemics aside I do find uniformed rants against Twitter, just because Twitter is not life-saving, not very productive and we should avoid appeal to authority and bad common sense.

> It should be clear that this isn't quite optimal.> Development practices are often superior in business /> enterprise programming whereas blackbox testing practices> are more exhaustive in the embedded sector. Polemics aside> I do find uniformed rants against Twitter, just because> Twitter is not life-saving, not very productive and we> should avoid appeal to authority and bad common sense.

Who ranted against twitter? I think I'm the only one who mentioned it at all, and that was because it was in reference to the original post from Tim Bray that got this ball rolling. I would hardly call what I said a rant. Unless there's a post I missed that was a rant?

And what did I get wrong? The methods used to bring twitter to market would be bad if applied to aviation software? Twitter made a bunch of mistakes that could have been avoided with some planning, research and putting a little more thought into the system's architecture, but it certainly wasn't cost effective to do so at the time.

It is VERY cost effective to put that sort of effort, research and design into aviation software.

I'm sorry if I had a point to make and used some examples to back it up and explained my position. Not all of us feel as if we can get away with a couple of pithy sentences and consider it Q.E.D., I'm right, you're wrong, have a nice day.

If you consider anything I wrote a rant, God help you if you ever catch me on a bad day :-)

Oh, and if I said something wrong, inform me. Please. I'm here to learn. It's why I frequent these forums.

I don't know how many people build the orginal twitter software, but I know it wouldn't take many and I'm sure one person could put the original incarnation of the basic service together if they were sufficiently motivated. Google twitter scaling problems and you will find no end of information regarding the issues they had and the measures they took to improve performance several orders of magnitude.

That lives are at stake with aviation software is exactly the point to me. It wasn't meant to be disparaging in any way. I don't work on anything these days that would compare to something that would go into an airplane or car or be managing millions of dollars of other people's money. Those things have a value, to most people anyway, that something like twitter or facebook or Google just don't have. I don't see how you can dismiss them from the discussion.

And why should we avoid appeal to authority? I'm as cynical as the next guy (I've been told by some that I'm more cynical than most) but sometimes authority actually knows what they are talking about. To automatically dismiss authority would seem to be as short sighted and narrow minded as automatically following it. Maybe that's not what you meant, or what you feel, but that is certainly how it sounded to me.

I find that particular trait in software professionals interesting, because, generally speaking, they are very suspicious of authority, don't trust it and are very skeptical as a rule. Yet most software professionals I know are the first to get really fired up when somebody won't listen to them and take what they say at face value, no questions asked. How many times have you gotten out of a design meeting or off a call with a customer and spent a considerable amount of time commiserating with your co-workers about how stupid their decisions are? About how blind they are to how technology D or methodology X and it would save them so much time and so many headaches and WHY WOULDN'T THEY JUST LISTEN TO ME??? I KNOW WHAT I'M TALKING ABOUT!!!!

I know I have. I know most of my co-workers have at one time or another, too. I've seen it one time or another on almost every blog I've read, often with no substantiation. I'm right and everybody else is an idiot is what those posts come down to when you remove all the big words and fancy arguments.

I've tried very hard over the past decade to figure out where people are coming from when they make decisions and find out what they are really after. Having been on both sides of the "shove it down their throats because I'm the authority figure" exchange, I know it doesn't work, even when you ARE right. Sometimes especially when you are right, because instead of taking an opportunity to teach something to somebody, you've made them resent you and dismiss your position instead of gaining something from it.

> I do find uniformed rants against Twitter, just because> Twitter is not life-saving, not very productive and we> should avoid appeal to authority and bad common sense.

I don't quite follow. Since the point of Tim Bray's post was that applications like Twitter are superior to IT apps in most every category, why shouldn't the issues with Twitter be up for discussion? The reliability of that system was very bad for a long time, I haven't heard much about it lately so maybe they've fixed those problems.

That's great for a startup because your initial number of users is effectively zero. When you are already an established business, your initial implementation will be viewed as a sign of your overall business quality. You can't start off with a weak solution and worry about getting it to work later.

That doesn't necessarily explain the problems with IT or excuse the failures in IT projects. But to say "look at this handful of successful web apps" (that mostly were pretty awful at first) and say that's how IT should work seems, frankly, pretty silly.