|
|
Re: Owners vs Caretakers
|
Posted: Jan 20, 2010 8:09 AM
|
|
> > 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.
|
|
Previous Topic
