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

111–120 of 201 posts

Re: Why don’t software development methodologies work?

#111

Post by jerf »

mathattack wrote: post #98
DenisM wrote: post #87

Earlier quoted context omitted.

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.

Great book. He anticipates a lot of the problems, and "Adding idiots at the end" rarely fixes things. (Look at the Obamaacare website) It's been a while since I've read it, but I don't think he captured the benefits from agility.

He mentions the importance of automated tested once or twice I think, but it isn't hammered on as a modern Agilist would. But, remember, 1970 was a different world. You may literally have not had room to include unit tests in your code, or literally be unable to afford the sort of abstractions that would enable unit testing, for instance.Other parts of that book talk about the difficulty of squeezing bytes out of pages. A lot of modern Agile practices are not possible back then, or are so different as to be entirely different things. TDD would probably get laughed at by all, for instance. "What, you want me to waste my precious timeshare time to run tests I know are going to fail?"

Re: Why don’t software development methodologies work?

#112

Post by jshen »

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 at the end of the process." How should a business handle this problem?

Re: Why don’t software development methodologies work?

#113

Post by ericHosick »

desireco42 wrote: post #95

I actually found that rapid-prototyping works best for me and I was able to deliver fairly good results using it. In fact I am starting a consultancy in month or two that will use rapid prototyping and other best practices I observed as effective. My goal is to provide environment where clients would feel their input is steering project and they are getting results they want, also that developers and others working o…

> rapid-prototyping works best for me

> provide environment where clients would feel their input is steering project

> others working on a project would like clear direction

What tools would you/do you use?

Re: Why don’t software development methodologies work?

#114

Post by acdha »

mcguire wrote: post #72
emddudley wrote: post #69

Earlier quoted context omitted.

The 1968 NATO SE conference is also the earliest reference I know of discussing software reuse (page 79 of the PDF, "Mass Produced Software Components"). Interesting to see how some of the problems then are still problems today.

Some?

Things which are a LOT easier:

1. Interactive editing 2. Interactive compilation (these two are probably the biggest reason programmers now are more productive) 3. Having enough storage for most problems 4. Having enough computation to solve most problems interactively 5. Handling numbers larger than one machine word 6. Handling floating point numbers 7. Handling precise decimal numbers (except for the lucky few using mainframes / COBOL) 8. Handling text using characters which wouldn't have worked in a telegram 9. Exchanging text with other systems (you couldn't even assume ASCII with other encodings (e.g. EBCDIC) being common) 10. Tracking changes to source code 11. Distributing shared code and tracking new releases 12. Communicating with other systems

We've gotten a lot better on various technical details. The parts which remain difficult are generally different aspects of human limitations reasoning about complex systems.

Re: Why don’t software development methodologies work?

#115

Post by ericHosick »

mattgreenrocks wrote: post #14
mynameisasdf wrote: post #8

Earlier quoted context omitted.

>anti-intellectualism that is so pervasive in the software development scene Errrr....

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.

Re: Why don’t software development methodologies work?

#116

Post by mattgreenrocks »

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.

This is exactly why software engineering needs to professionalize.

I don't see developers always having more leverage than their business counterparts. Really, I'd love to see developers wholly accountable to their peers, along with some sort of entrance exam. I think the world at large would take developers a bit more seriously.

Re: Why don’t software development methodologies work?

#117

Post by MartinCron »

georgemcbay wrote: post #109

This is a fantastic post and I agree with it fully. I get why process exists, I know management sees it as a way to make software development less lumpy; to bring below average teams up to average productivity, but it isn't a one way lift. Extensive process might raise the below average toward the average, but it can also lower the above average toward the average. Twice I've seen situations where a team of better th…

Extensive process might raise the below average toward the average, but it can also lower the above average toward the average

The way that I see it is that at best, rigid processes can set set both a ceiling and a floor. It's sort of like going to (a real) Starbucks. 99 times out of a hundred it's not going to be terrible, nor is it going to be great. It's going to be just OK.

If you're the kind of organization that looks at software as a necessary evil instead of a strategic advantage, "just OK" is an appealing thing to strive for.

Re: Why don’t software development methodologies work?

#118

Post by MartinCron »

mcguire wrote: post #67

" Surprisingly, left to themselves programmers don’t revert to cowboy coding—they adopt or create methodologies stricter and more filled with ritual than anything I experienced in 1980. In fact programmers today can be much more rigid and religious about their methodologies than they imagine a 1970s-era COBOL shop was. I now routinely get involved with projects developed by one or two people burdened with so much pro…

I like the Kafkaesque idea of inventing new best practices specifically so you can avoid using them.

Re: Why don’t software development methodologies work?

#119

Post by ebiester »

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…

I can't give you an exact cost and time, but what I can do is give you relative cost and time. "This is easy, this is easy but will take a while (low variance), this is hard (relatively long time, high variance.) -- so that's giving you your estimate and your tolerances.

Further, I can work with you to figure out what portion of each project will give you the biggest bang for your buck. So you can say, "I want to spend x00,000 dollars." -- and I come back and give you a demo each week that you can play around with. At any point, you can say, "This is enough to generate value for me, let's move to the next thing for a while."

Further still, I can build it with enough test coverages and good design practices that it will be possible to extend upon the design at a later point without scrapping everything.

On the other hand, you can spend half of that x00,000 developing a specification. If detailed enough, I can give you a very low variance estimate of how long it will take. However, you won't know if it will actually meet your needs until you see it. You won't know about problems in what you really need until it's too late, and you'll end up spending more money in the end.

That's the message that should go out.

Re: Why don’t software development methodologies work?

#120

Post by jaggederest »

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…

> 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 at the end of the process."

If that's the actual answer, then anything else is just obfuscating the truth.

Why should we encourage lying to try to cover for the fundamental lack of knowledge? If you don't know, trying to make up numbers never makes things better.

Post reply on HN