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

161–170 of 201 posts

Re: Why don’t software development methodologies work?

#161

Post by robotys »

pekk wrote: post #124
jaggederest wrote: post #120

Earlier quoted context omitted.

> 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 m…

Making up numbers doesn't make things better for you or for delivery of the project. But it makes you liable to the boss, so they can make your head roll if they need to. A surprising number of people in business think this way: not that they need to make sure of something, but just that they need someone to tell them everything will be OK, and then put the blame on if anyone is unhappy. That someone will naturally b…

This remind me that business is pure gamble, and business people is bad gambler. They want to play but do not want to lose and if they lose they want to blame somebody.

Managing ego and heart is harder than managing a project i think.

Re: Why don’t software development methodologies work?

#162

Post by drewcrawford »

ebiester wrote: post #119
jshen wrote: post #112

Earlier quoted context omitted.

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 spe…

You have successfully solved the problem posed, but it was not well-stated. In a real-world scenario, it is important not just to identify which of the 10 ideas is most promising, but to defeat the null hypothesis that the programmers should be fired and no idea should be pursued. After all, to choose the best of 10 bad ideas is to have failed as an economic enterprise.

In order for a business to be investable, it is necessary to demonstrate that it will be profitable to an investor. (And of course all businesses need investment, whether that is VC money or just a lone developer's part-time effort.)

We have avoided this problem because in the early days of software, most software was profitable. But as the software industry has grown, this is proportionally less true. And I seriously question in 2014 whether more LOC are committed each day to "black" or "red" projects.

Re: Why don’t software development methodologies work?

#163

Post by sirmarksalot »

Refefer wrote: post #89
sirmarksalot wrote: post #40

Earlier quoted context omitted.

I think that's one aspect of the problem, but the migration from make-do to mathematically rigorous code can be equally fraught with peril. While the code itself can be made predictable, and easy to reason around, the time estimates and project planning often cannot. There is never enough time to factor out all of the commonality, remove all of the unnecessary use of state, codify all the assumptions into data types,…

Ah, but that's a matter of design - except now we have strong constructs from which to consider our problem. We will never get away from developing the architecture of our system, which is cost dependent on how well understood the domain is. Ideally, that's where we should aim to move: problem specifications that render implementations rote. A lofty goal, I know, but within closer reach every day and possible in many…

The dark side proof is that most mathematical problems are incredibly contrived. Taking a business requirement and translating it into known mathematical problems is harder than it sounds. Once you can do that, you're 90% of the way there, and people who can do that reliably are regarded as geniuses.

But most of the time, development is done without full understanding of the problem space. Usually, the problem doesn't become fully understood until you've already spent a good amount of time coding up your solution. If you wait until you fully understand the problem before starting, then you'll never start, because your brain simply can't comprehend the entire scope.

So instead, you get code bases full of sort-of well-factored code, but with lots of unwittingly reinvented wheels. This status is occasionally improved when somebody really smart happens to notice the commonality, and remembers a classic problem that it resembles, and manages to refactor the entire thing using the general solution. However, this almost never becomes apparent during the first revision.

Re: Why don’t software development methodologies work?

#164

Post by marcosdumay »

HeyLaughingBoy wrote: post #138
ericHosick wrote: post #115

Earlier quoted context omitted.

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

OMG. I just hope you are being sarcastic.

That's everything we are complaining about right there on the index.

Re: Why don’t software development methodologies work?

#165

Post by gboudrias »

desireco42 wrote: post #152
gaius wrote: post #132

Earlier quoted context omitted.

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.

This is so true. And not even amusing, it is like we can't come up with anything new, we even go backwards.

It's the politics that change. Sometimes we use a different tool to prove a point. What we lose in productivity we sometimes make back in social progress (ex: yanking control away from certain corporations).

I do hate the reinvention of the wheel too, but it's not all pointless.

Re: Why don’t software development methodologies work?

#166

Post by jsankey »

pnathan wrote: post #158
MartinCron wrote: post #121

Earlier quoted context omitted.

The move from labor-intensive, big-bang, monolithic deployments to fully automated, tested, non-event deployments has been a bigger positive change for me than any defined methodology or specific technology.

Continuous testing/building is a major component to a good project. I know it'd been done for years by some groups Agile became a Thing.

I tried to track the history of CI once[1] -- a similar practice may date back as far as the 60s at IBM. There are multiple sources indicating daily builds with tests at Microsoft from at least the early 90s (not quite CI but at the scale of the projects probably as close as practical at the time). Long before Agile became trendy in the 00's.

[1]: http://www.alittlemadness.com/2009/01/09/continuous-integrat...

Re: Why don’t software development methodologies work?

#167

Post by derefr »

drewcrawford wrote: post #162
ebiester wrote: post #119

Earlier quoted context omitted.

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 spe…

You have successfully solved the problem posed, but it was not well-stated. In a real-world scenario, it is important not just to identify which of the 10 ideas is most promising, but to defeat the null hypothesis that the programmers should be fired and no idea should be pursued. After all, to choose the best of 10 bad ideas is to have failed as an economic enterprise. In order for a business to be investable, it is…

> to defeat the null hypothesis that the programmers should be fired and no idea should be pursued

Now I'm imagining a website like oDesk or ELance, but which requires employers to "defeat the null hypothesis" for any job contract they want to post. What a wonderful world that would be.

Re: Why don’t software development methodologies work?

#168

Post by derefr »

jaggederest wrote: post #120
jshen wrote: post #112

Earlier quoted context omitted.

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 m…

"Make up numbers" glosses over a bunch of actually-useful techniques, though. You might not have any data to begin with, but you can certainly get some.

For example, since a time estimate can trivially be converted into probability estimate for something happening on time, all of this is relevant: http://lesswrong.com/lw/3m6/techniques_for_probability_estim....

The best technique from that set, I usually find, is betting (with actual money) on results: setting up a intra-company prediction market for when your software will ship can tell you more than you ever wanted to know about how much time it'll truly take.

Re: Why don’t software development methodologies work?

#170

Post by stretchwithme »

I guess to answer that question, you first have to define what a working methodology is supposed to accomplish.

How do you know something is developed in a timely fashion, for example? All we really have is a gut feeling.

We could implement the same project multiple times and use a different methodology each time. Then compare. But you'd want to use people who understand the methodology and care about winning the competition.

Even then, I bet if you ran that experiment with 5 different projects, there'd probably be a different outcome every time.

Post reply on HN