The Artima Developer Community
Sponsored Link

Weblogs Forum
Owners vs Caretakers

39 replies on 3 pages. Most recent reply: Jan 22, 2010 4:58 PM by James Watson

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 39 replies on 3 pages [ « | 1 2 3 | » ]
Kay Schluehr

Posts: 302
Nickname: schluehk
Registered: Jan, 2005

Re: Owners vs Caretakers Posted: Jan 20, 2010 10:28 AM
Reply to this message Reply
Advertisement
> I love that sound principles are referred to as dogmatism.
> You're obviously very enlightened. That's just great.
> Personally, in cases like this, I'm a big fan of
> "dogmatism". I hope they continue to dogmatically build
> bridges, roads, vehicles, radar systems, medical
> instruments, nuclear devices, and so on and so forth....

This is just stupid. Either you have sound principles then they are transparent to reason and everyone has to commit to them, no matter if it is Twitter or Boeing or you act in blind faith and you have none.

I'm certainly not recommending to build insecure systems in either way but I'd like to hear why Agile is inadequate for this purpose and what are the intrinsic reasons? I guess it is not TDD?

Merriodoc Brandybuck

Posts: 225
Nickname: brandybuck
Registered: Mar, 2003

Re: Owners vs Caretakers Posted: Jan 20, 2010 11:09 AM
Reply to this message Reply
> > I love that sound principles are referred to as
> dogmatism.
> > You're obviously very enlightened. That's just great.
> > Personally, in cases like this, I'm a big fan of
> > "dogmatism". I hope they continue to dogmatically build
> > bridges, roads, vehicles, radar systems, medical
> > instruments, nuclear devices, and so on and so
> forth....
>
> This is just stupid. Either you have sound principles then
> they are transparent to reason and everyone has to commit
> to them, no matter if it is Twitter or Boeing or you act
> in blind faith and you have none.
>
> I'm certainly not recommending to build insecure systems
> in either way but I'd like to hear why Agile is inadequate
> for this purpose and what are the intrinsic reasons? I
> guess it is not TDD?

@Bill "However, to Kay's point, it would be interesting to find out if other methodologies have been tried - as well as analysis of errors not handled properly in software designed with the current methodology."

I have no doubt it would be interesting. But are you willing to take that risk? I'm not. We've had planes in the air for almost 100 years now and we are pretty good at making planes fly. I think it's a bad time to change what we're doing for curiousity's sake.

I'm not a huge fan of TDD, either, by the way. I'm not really a fan of any Methodology, simply because they all seem to try to be all things to all people. Or they believe that the Methodology is The One True Way.

And dogmatic is such a loaded word that I don't think you could have picked a worse word. It implies that anybody that follows a process is just blindly following it. That the process was just pulled out of thin air and wasn't arrived at through a lot of trial and error. As if learning from the people that came before you and not repeating their mistakes is bad.

Personally, for most of the projects I have worked on, the agile manifesto works for me. But all the methodologies that have sprung up around it (scrum, xp, etc.) all just drive me batty. They put such an emphasis on just throwing something out there and iterating the hell out of it that, from what I have seen in practice, a lot of things fall through the cracks that should not have had these folks been as smart as they think they are.

As for why Agile would be bad for building planes, in my opinion:

1. Individuals and interactions over processes and tools - We know how to build planes. We want repeatable results every single time. That is, flying planes. Sound, repeatable process and good tools make this much easier.

2. Working software over comprehensive documentation - I don't feel that there is an 'over' here. In this case, they are equally important. Given that people die if a plane fails, I want to know what went into the building of the plane, where it went, why it went there and who put it there so, in the case that something SHOULD go wrong, I have a good idea of what to change and where. I'm assuming that part of the documentation is a flight recorder that is keeping track of as much plane data as possible while the plane is operating.

3. Customer collaboration over contract negotiation - Ya know what, this one is ok as is.

4. Responding to change over following a plan - As James pointed out, there was a time when planes were built in this fashion. But, we are pretty sure at this point in our history about what goes into a plane, what makes it fly and what materials are good to use for the planes we fly in. How much change to we need to respond to? I think the plans are much more important here.

Also, planes cost millions of dollars to build. Twitter probably cost a few thousand in its first incarnation. I would guess that hundreds of people have to collaborate in the building of an airplane and everything has to be precisely right when it's done, or people die. How many people did it take to build twitter? A dozen at most?

If twitter isn't precisely right, I don't get to hear that Jessica Simpson's dog got snatched by a coyote and she offered a reward for its return, as if the coyote was holding it for ransom. No great loss there. Or I miss that Phil Helmuth busted out of a poker tournament at the hands of yet anther idiot from Northern Europe. No great loss there either.

Twitter's scaling problems are pretty well documented. Other applications in the past have had scaling issues and in some cases Twitter repeated previous mistakes. They could have avoided these mistakes had they taken the worst case assumption that it would scale MASSIVELY and prepare for that eventuality by doing a lot of research and making the architecture rock solid up front. As pointed out above, the worst case of twitter being out is that somebody misses some piece of information that is certainly not life threatening. And the twitter folks didn't KNOW it would take off, so why spend the time, money and effort to make it rock solid if nobody is going to use it anyway?

Planes crashing are also pretty well documented. Newly built planes can avoid some of the mistakes that led to plans crashing by researching the causes, planing for them and building the plane in the best manner possible to avoid previous errors in airplane construction. The worst case scenario of repeating a previous mistake is that the plane falls out of the sky, a few hundred people die a horrific death and we get to watch it on the evening news and talk about it for weeks on end. So please, if you are building a plane, plan the hell out of it. Try to account for every bad thing that might possibly happen. Because twitter going down vs. a plane going down isn't even comparable.

Mostly, I hate the use of the word dogmatic.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Owners vs Caretakers Posted: Jan 20, 2010 12:03 PM
Reply to this message Reply
> I'm in full agreement that IT management deserves plenty
> of blame. However, during the hiring spree in the mid to
> late 90's, too many people were hired for developer
> positions who had no experience. The situation could have
> worked if the same people, who were only apprentice level,
> were not also put into critical roles. The documented
> failures since then made people who decide on strategy
> look for "Silver Bullets" in the tool and process areas to
> mitigate the lack of skill in the people area.

I think that's about right. But the problem is that if you really truly understand what programming is about, you would never try to use mass-production approaches, for example.

I have a good example of the kind of issue I am talking about happen the other day. I asked how a certain component would order it's responses. I responded that there was no determined order i.e. the order was indeterminate. The person I was speaking to responded by implying that such a thing was impossible. Basically, I had two choices at that moment. Break out into a computer science lesson, say "yes it's possible", or let the (incorrect) statement stand. Given the setting, the first option was not reasonable, the second would seem argumentative and the third is the only 'correct' option.

I don't have to teach every manager I work with. They need to come into the job with enough understanding of technology to allow me to explain things in the time I do have. I am not the only person that has this issue and the result is that decisions are largely made without regard to their technical merits and often without regard to basic rational thinking.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Owners vs Caretakers Posted: Jan 20, 2010 12:04 PM
Reply to this message Reply
> I don't have to teach every manager I work with.

Should be "I don't have time to teach every manager I work with."

robert young

Posts: 361
Nickname: funbunny
Registered: Sep, 2003

Re: Owners vs Caretakers Posted: Jan 20, 2010 12:12 PM
Reply to this message Reply
>> 3. Customer collaboration over contract negotiation - Ya know what, this one is ok as is

The notion that contract negotiation will _ever_ take second place to any other consideration in Enterprise Software (even when it's between internal IT and an internal cost/profit center) is naive. Which I guess is the problem with this discussion. We're talking about the right way to eat a chocolate bar when the plate is full of pig turds.

Merriodoc Brandybuck

Posts: 225
Nickname: brandybuck
Registered: Mar, 2003

Re: Owners vs Caretakers Posted: Jan 20, 2010 1:15 PM
Reply to this message Reply
> We're talking about the
> right way to eat a chocolate bar when the plate is full of
> pig turds.

MMmmm..... pig turds....... :-P

Bill Pyne

Posts: 165
Nickname: billpyne
Registered: Jan, 2007

Re: Owners vs Caretakers Posted: Jan 20, 2010 1:34 PM
Reply to this message Reply
> The notion that contract negotiation will _ever_ take
> second place to any other consideration in Enterprise
> Software (even when it's between internal IT and an
> internal cost/profit center) is naive.

When dealing with external customers your observation is true. For internal customers, it depends completely on the organization dynamics. (I'm using "dynamics" as a catch all for personality interactions and organization structure.) Some organizations I've been in didn't have "contracts" at all and others did charge backs so in-house contracts were necessary.

It depends also on whether or not "Enterprise" necessarily means mega-corp or does it apply to, e.g., a medium sized hospital. My experience is that large organizations need more formalization of relationships and expectations.

Bill Pyne

Posts: 165
Nickname: billpyne
Registered: Jan, 2007

Re: Owners vs Caretakers Posted: Jan 20, 2010 1:43 PM
Reply to this message Reply
> I think that's about right. But the problem is that if
> you really truly understand what programming is about, you
> would never try to use mass-production approaches, for
> example.

Mass-production is, unfortunately, over used as an approach in many areas of our society. Food service is one that particularly irritates me, but that's a different topic.

> I have a good example of the kind of issue I am talking
> about happen the other day. I asked how a certain
> component would order it's responses. I responded that
> there was no determined order i.e. the order was
> indeterminate. The person I was speaking to responded by
> implying that such a thing was impossible. Basically, I
> had two choices at that moment. Break out into a computer
> science lesson, say "yes it's possible", or let the
> (incorrect) statement stand. Given the setting, the first
> option was not reasonable, the second would seem
> argumentative and the third is the only 'correct' option.

Option 4: Nod your head, give a vague response, proceed to the nearest tap, and down a pint.

> I don't have to teach every manager I work with. They
> need to come into the job with enough understanding of
> technology to allow me to explain things in the time I do
> have. I am not the only person that has this issue and
> the result is that decisions are largely made without
> regard to their technical merits and often without regard
> to basic rational thinking.

At the least, an IT manager w/o technical knowledge should have the self-awareness to know what he/she doesn't know and the humility to trust those who do.

robert young

Posts: 361
Nickname: funbunny
Registered: Sep, 2003

Re: Owners vs Caretakers Posted: Jan 20, 2010 1:59 PM
Reply to this message Reply
>> others did charge backs so in-house contracts were necessary.

And all of the ones I've worked for, large and medium, had a charge-back mechanism; with all that implies.

Bill Pyne

Posts: 165
Nickname: billpyne
Registered: Jan, 2007

Re: Owners vs Caretakers Posted: Jan 20, 2010 2:00 PM
Reply to this message Reply
> I have no doubt it would be interesting. But are you
> willing to take that risk? I'm not. We've had planes in
> the air for almost 100 years now and we are pretty good at
> making planes fly. I think it's a bad time to change what
> we're doing for curiousity's sake.

My curiosity is specifically about aviation software. I'm in complete agreement that we know how to design and build planes and shouldn't mess with it very much.

> I'm not a huge fan of TDD, either, by the way. I'm not
> really a fan of any Methodology, simply because they all
> seem to try to be all things to all people. Or they
> believe that the Methodology is The One True Way.

Methodologies of themselves are not bad but they must be chosen to match the organization and its goals. My own personal choice is to work for an organization that doesn't do life-threatening work and develops iteratively. (Of course, I screwed up with my current employer: got the first criterion right but missed the second by a long shot. C'est la vie.)

> And dogmatic is such a loaded word that I don't think you
> could have picked a worse word. It implies that anybody
> that follows a process is just blindly following it. That
> the process was just pulled out of thin air and wasn't
> arrived at through a lot of trial and error. As if
> learning from the people that came before you and not
> repeating their mistakes is bad.

Actually, Kay used the word and his use is totally in line with the dictionary definition. I agree with the sentiment that we shouldn't throw away anecdotes and oral history.

> As for why Agile would be bad for building planes, in my
> opinion:

Again, I wasn't trying to argue about building planes, just the aviation software. Everything you say sounds pretty good though with respect to plane building.

Bill Pyne

Posts: 165
Nickname: billpyne
Registered: Jan, 2007

Re: Owners vs Caretakers Posted: Jan 20, 2010 2:11 PM
Reply to this message Reply
> And all of the ones I've worked for, large and medium, had
> a charge-back mechanism; with all that implies.

Only the 2 large companies I worked for did it. The other six or so organizations did not.

Merriodoc Brandybuck

Posts: 225
Nickname: brandybuck
Registered: Mar, 2003

Re: Owners vs Caretakers Posted: Jan 20, 2010 2:33 PM
Reply to this message Reply
> > I have no doubt it would be interesting. But are you
> > willing to take that risk? I'm not. We've had planes in
> > the air for almost 100 years now and we are pretty good
> at
> > making planes fly. I think it's a bad time to change
> what
> > we're doing for curiousity's sake.
>
> My curiosity is specifically about aviation software. I'm
> in complete agreement that we know how to design and build
> planes and shouldn't mess with it very much.
>

Given that the software on the plane is responsible for flying it, landing it, managing the fuel, the cabin, and just about everything else the plane does, it is very hard for me to separate the two. If I'm not mistaken, most fighter planes couldn't even fly without the software managing the plane because they fly at such high speeds and are such precision machines. Auto pilots on commercial airliners almost make pilots irrelevant.

This just seems like a bad place to scratch a curiosity itch. I'll let other people fly that plane first.

> > I'm not a huge fan of TDD, either, by the way. I'm not
> > really a fan of any Methodology, simply because they
> all
> > seem to try to be all things to all people. Or they
> > believe that the Methodology is The One True Way.
>
> Methodologies of themselves are not bad but they must be
> chosen to match the organization and its goals. My own
> personal choice is to work for an organization that
> doesn't do life-threatening work and develops iteratively.
> (Of course, I screwed up with my current employer: got the
> first criterion right but missed the second by a long
> shot. C'est la vie.)
>

I totally agree with that. I just haven't heard that much from the people pushing their pet methodology. If you use their pet methodology and your project fails, the discussion usually goes "You were doing it wrong". It couldn't possibly be that the methodology is a bad fit, or just plain bad, could it?

> > And dogmatic is such a loaded word that I don't think
> you
> > could have picked a worse word. It implies that anybody
> > that follows a process is just blindly following it.
> That
> > the process was just pulled out of thin air and wasn't
> > arrived at through a lot of trial and error. As if
> > learning from the people that came before you and not
> > repeating their mistakes is bad.
>
> Actually, Kay used the word and his use is totally in line
> with the dictionary definition. I agree with the sentiment
> that we shouldn't throw away anecdotes and oral history.
>

Yeah, there are also plenty of other words that could have been used that have a similar meaning without the disparaging overtones.

> > As for why Agile would be bad for building planes, in
> my
> > opinion:
>
> Again, I wasn't trying to argue about building planes,
> just the aviation software. Everything you say sounds
> pretty good though with respect to plane building.

Since software controls just about everything on a modern plane, I have problems separating the two.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Owners vs Caretakers Posted: Jan 20, 2010 3:17 PM
Reply to this message Reply
> At the least, an IT manager w/o technical knowledge should
> have the self-awareness to know what he/she doesn't know
> and the humility to trust those who do.

That's a start but really doesn't solve much it just moves the issue into a different problem domain. If you don't have some level of technical acumen, you don't know who to trust. I know a number of managers who just trust whatever the consultant du jour tells them even when that consultant has obvious conflicts of interest. I usually see the least talented of all technical staff was the 'go-to guy' for technical decisions on new high-visibility work.

I've been pondering this phenomenon for a while and I think it comes down to "I don't understand you, so you must be wrong". People who over-simplify or plain just make shit up that's easy to understand seem smarter if you don't know your ass from a hole in the ground.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Owners vs Caretakers Posted: Jan 20, 2010 3:23 PM
Reply to this message Reply
> Yeah, there are also plenty of other words that could have
> been used that have a similar meaning without the
> disparaging overtones.

It would seem unlikely based on the way he writes but I believe English is not Kay's mother tongue. I understand where you are coming from but the word may not have the exact same implications to Kay.

Bill Pyne

Posts: 165
Nickname: billpyne
Registered: Jan, 2007

Re: Owners vs Caretakers Posted: Jan 20, 2010 3:58 PM
Reply to this message Reply
> If you don't have some level of technical acumen, you
> don't know who to trust.

Important observation and a failure in my own statement. Thank you.

> I've been pondering this phenomenon for a while and I
> think it comes down to "I don't understand you, so you
> must be wrong". People who over-simplify or plain just
> make shit up that's easy to understand seem smarter if you
> don't know your ass from a hole in the ground.

I think that's too often how people in the US become leaders.

Flat View: This topic has 39 replies on 3 pages [ « | 1  2  3 | » ]
Topic: Posse Roundup Early-Bird Ends Sunday Previous Topic   Next Topic Topic: The Autoproxy Plugin - Part II


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us