Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why don’t software development methodologies work?

typicalprogrammer.com

Post reply on HN
Print view View original

131–140 of 201 posts

Re: Why don’t software development methodologies work?

#131

Post by polskibus »

falcolas wrote: post #43
njharman wrote: post #33

> rigorous studies of software development methodologies haven’t been done A simple search proves this is false. Paired with author's other unsupported and stupendous claims I have to doubt the validity and worth of anything else author says.

Could you please link to some of these studies that adequately control for the constituent programmer ability & personalities?

Let me recommend you "Lean Software Strategies" book. It refers to many software development experiments and observations, some of them from Lockheed Martin. While the book does not claim to present the ultimate methodology, it draws on progress in other engineering disciplines to create a better, continuously improving process.

http://www.amazon.com/Lean-Software-Strategies-Techniques-De...

Re: Why don’t software development methodologies work?

#132

Post by gaius »

DenisM wrote: post #87
msluyter wrote: post #45

It's fun to watch observations like the following re-discovered again and again. From the NATO Software Engineering Conference in 1968: Ross: The most deadly thing in software is the concept, which almost universally seems to be followed, that you are going to specify what you are going to do, and then do it. And that is where most of our troubles come from. Fraser: One of the problems that is central to the software…

Having read "the mythical man-month" I came to conclusion that majority of the problems we have today were discovered an described by the 1970-ies.

The majority of everything in software was discovered by the 70s. Since then we have been reinventing the wheel every 5-10 years on better hardware.

Re: Why don’t software development methodologies work?

#133

Post by aidenn0 »

jshen wrote: post #112
msluyter wrote: post #45

It's fun to watch observations like the following re-discovered again and again. From the NATO Software Engineering Conference in 1968: Ross: The most deadly thing in software is the concept, which almost universally seems to be followed, that you are going to specify what you are going to do, and then do it. And that is where most of our troubles come from. Fraser: One of the problems that is central to the software…

Imagine you are a large company and there are 10 ideas for things you can build next, and you can't do them all. You gather the people that build such things and ask them, "how much will it cost to make each of these, and how long will it take". Do you think it is an acceptable answer if the builders reply, "I have no idea how much it will cost, I don't know how long it will take, and I don't know what you will have…

You can answer with order of magnitude approximations (days, months, years, might be impossible).

The order of magnitude approximation is good enough, and for ones in which you can't make an order of magnitude approximation you should be able to back it up.

e.g. c.a. 2002 a PMM said "All we need for this idea to work is speaker-independent voice recognition in a noisy environment; how long will that take?"

The correct answer to that question isn't a time estimate, or "I don't know" it's saying that doing so is an R&D problem, not an engineering problem.

Re: Why don’t software development methodologies work?

#134

Post by RamiK »

jshen wrote: post #112
msluyter wrote: post #45

It's fun to watch observations like the following re-discovered again and again. From the NATO Software Engineering Conference in 1968: Ross: The most deadly thing in software is the concept, which almost universally seems to be followed, that you are going to specify what you are going to do, and then do it. And that is where most of our troubles come from. Fraser: One of the problems that is central to the software…

Imagine you are a large company and there are 10 ideas for things you can build next, and you can't do them all. You gather the people that build such things and ask them, "how much will it cost to make each of these, and how long will it take". Do you think it is an acceptable answer if the builders reply, "I have no idea how much it will cost, I don't know how long it will take, and I don't know what you will have…

Businesses never had the stomach for basic research. It's why progress is traditionally done in one form or another of a governmentally sanctioned monopoly.

Re: Why don’t software development methodologies work?

#135

Post by SomeCallMeTim »

Consultant32452 wrote: post #127
segmondy wrote: post #29

Because it tries to fix human problems logically. Humans are not very logically creatures. We love to think we are, but most of us are very emotionally driven. Our emotion comes into play when it comes to drive, motivation, hard work, creativity, and organization. Creating software requires motivation, creativity, organization, etc. Our emotion is behind software and we simply try to manage it with software developme…

The success of dieting programs is that people change their habits from unhealthy behaviors to healthy behaviors. The most successful ones are done in groups that offer emotional support in addition to health education. The point of these methodologies is to help replace unhealthy development behaviors with healthier ones and to use groups that offer reinforcement of the healthy behavior as part of the process. Of co…

I think diets are just a poor metaphor here.

A big part of the lack of success of most diets is that the diets themselves change your emotional state. Not to mention that most actually encourage less healthy eating habits.

The American Heart Association for years recommended a low fat diet for heart health, when the studies they were using to justify this decision showed a higher overall mortality for people on low fat diets; they just died of fewer heart-related problems. (If I'm remembering correctly, there were a LOT more suicides in the low-fat group.)

The people who say "just eat less and exercise more!" are also completely full of it. It simply doesn't always work -- handled wrong it can lead to really bad emotional states brought on by the lack of food. Like the above example, you could end up with a lot more suicides, which are pretty bad for your health, no matter how you slice it. Presumably most people who make this claim are not fat or have never tried it, but it's frustrating to see it repeated over and over by people who exercise less than and eat more than a lot of "fat" people.

On the other hand, maybe the metaphor does work: We're recommending or enforcing practices when we really have no clue as to their efficacy. We don't always know what is healthy and what is unhealthy; we have guesses, but then we latch onto them like religion.

Re: Why don’t software development methodologies work?

#136

Post by invalidOrTaken »

jshen wrote: post #112
msluyter wrote: post #45

It's fun to watch observations like the following re-discovered again and again. From the NATO Software Engineering Conference in 1968: Ross: The most deadly thing in software is the concept, which almost universally seems to be followed, that you are going to specify what you are going to do, and then do it. And that is where most of our troubles come from. Fraser: One of the problems that is central to the software…

Imagine you are a large company and there are 10 ideas for things you can build next, and you can't do them all. You gather the people that build such things and ask them, "how much will it cost to make each of these, and how long will it take". Do you think it is an acceptable answer if the builders reply, "I have no idea how much it will cost, I don't know how long it will take, and I don't know what you will have…

Beats me. But I have every confidence that you'll figure it out. You're smart, that's why they put you in charge.

Re: Why don’t software development methodologies work?

#137

Post by radicalbyte »

AnthonyMouse wrote: post #47
mnw21cam wrote: post #10

Earlier quoted context omitted.

I left my last job because my time had degenerated from doing cool stuff to fixing the stupid errors that my colleagues were making because they were lazy. Allowing some coders to be lazy in terms of adherence to coding standards and methodology has to be one of the best ways to get rid of your good programmers. For example, we had coding standards requiring a comment explaining the contract for each method written,…

That sort of thing has an obvious problem. Take a fairly simple class: class Shape { public: void SetAbsolutePosition(uint x, uint y, LengthUnit units = LengthUnit::PIXELS); void SetRelativePosition(int x, int y, LengthUnit units = LengthUnit::PIXELS); void SetXAbsolutePosition(uint x, LengthUnit units = LengthUnit::PIXELS); void SetYAbsolutePosition(uint y, LengthUnit units = LengthUnit::PIXELS); void SetXRelativePo…

The problem you're describing - detail overload - is a problem that should be solved by the IDE, not by removing comments.

The comments are most likely used to generate documentation, which can be very handy later.

Re: Why don’t software development methodologies work?

#138

Post by HeyLaughingBoy »

ericHosick wrote: post #115
mattgreenrocks wrote: post #14

Earlier quoted context omitted.

How else do you characterize an industry that seems content to re-learn lessons of the past over and over?

It seems like almost all professions have a body of knowledge. Software Engineering doesn't. Imagine getting open heart surgery, your chest is open, and doctors start arguing over the best methodology to do it.

It does, and it has for quite some time: http://www.computer.org/portal/web/swebok

Re: Why don’t software development methodologies work?

#139

Post by connerbryan »

pnathan wrote: post #70
connerbryan wrote: post #38

Earlier quoted context omitted.

Too pragmatic. Where are the meetings?!

Snarky, but frankly, there will be meetings very regularly with people who care & fund the project, as well as meetings within the engineering team to keep everyone abreast of what's going on. The trick is not to have pointless meetings. Someone should get something out of the meeting besides warm fuzzies and new doodles.

> The trick is not to have pointless meetings. Someone should get something out of the meeting besides warm fuzzies and new doodles.

Agreed. I should have been more specifically snarky.

Re: Why don’t software development methodologies work?

#140

Post by AnthonyMouse »

mnw21cam wrote: post #85
AnthonyMouse wrote: post #47

Earlier quoted context omitted.

That sort of thing has an obvious problem. Take a fairly simple class: class Shape { public: void SetAbsolutePosition(uint x, uint y, LengthUnit units = LengthUnit::PIXELS); void SetRelativePosition(int x, int y, LengthUnit units = LengthUnit::PIXELS); void SetXAbsolutePosition(uint x, LengthUnit units = LengthUnit::PIXELS); void SetYAbsolutePosition(uint y, LengthUnit units = LengthUnit::PIXELS); void SetXRelativePo…

While I understand the argument behind not commenting getters and setters, and it is quite valid, no it is not obvious what each of those methods do. For instance, what is the relative position relative to? Is the colour for the outline of the shape or the fill? Why do you have a width and height for a shape - does that mean it is a rectangle? But of course I meant my earlier comment particularly for quite complex me…

> But of course I meant my earlier comment particularly for quite complex methods that had very ambiguous behaviour unless defined in a comment that could act as a contract.

Which is kind of the point. You do need some kind of documentation for nontrivial methods. But requiring boilerplate documentation for everything encourages the opposite of that because it becomes "fill in the fields" rather than "say something useful." I mean let's say you're right and SetRelativePosition isn't clear about what it's relative to. Which of these is better?

  /**
     * SetRelativePosition sets the Shape relative position
     *
     * @param x The relative X coordinate
     * @param y The relative Y coordinate
     * @param units The units of the coordinates
     * @returns Void
     */
    void SetRelativePosition(int x, int y, LengthUnit units = LengthUnit::PIXELS);
-or-

    /* SetRelativePosition: sets position relative to current position */
    void SetRelativePosition(int x, int y, LengthUnit units = LengthUnit::PIXELS);
Post reply on HN