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

141–150 of 201 posts

Re: Why don’t software development methodologies work?

#141

Post by twobits »

emddudley wrote: post #69
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…

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.

May not be a problem for them any more..

Re: Why don’t software development methodologies work?

#142

Post by raverbashing »

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…

To know how long something takes you must have done it already.

And that's the problem with software, there are no equals. And there are always "surprises".

A car manufacturer knows how long it takes to build a car, because it does that thousands of times for a same model. Now, designing the car, that's a different issue. (And don't give me the BS enterprise "model" of architects throwing some UML from a high tower and "developers" filling the voids because that's the worse way you can build a software)

Ok, it's one thing to build a simple ACID application, another thing is to build something that "has never been tried before" .

Re: Why don’t software development methodologies work?

#143

Post by [deleted] »

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.

[deleted]

Re: Why don’t software development methodologies work?

#144

Post by mathattack »

fishtoaster wrote: post #101
mathattack wrote: post #100

I'm a fan of repeatability and process. Here's my take on why they don't work: 1) You can't get around that things don't work as planned, and too many methodologies assume that things will. 2) It is better to have a PM with A level content and B level process, than the other way around. Professional PMs don't have the intuition to solve the daily project problems, but they're the ones selling the methodologies. 3) To…

#1 and #3 sound like they're right out of http://agilemanifesto.org/

Typed from memory w/out referencing it. (I'm not agile certified, or anything to that effect)

Re: Why don’t software development methodologies work?

#145

Post by artsrc »

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…

What about the other half of the uncertainty?

The company does not know how much revenue each of those ideas will deliver.

Re: Why don’t software development methodologies work?

#146

Post by tokipin »

it seems to me that iterative methodologies (like basic "agile") are an implicit acknowledgement that development methodologies don't work. periodic re-adjustments based on local circumstances are necessary because the terrain on which our current software systems rest is too unpredictable

Re: Why don’t software development methodologies work?

#148

Post by vonmoltke »

pnathan wrote: post #86
Retric wrote: post #77

Earlier quoted context omitted.

That's a great solution when you understand the problem. Process is great when nobody can understand the problem. Windows is a great example of this, nobody at Microsoft really understands even 1/2 of what Windows does internally down at the code level. Now, how do you ensure a useful update comes out the door in 2015? PS: Granted if you deal with less than 30 people process tends to be overrated.

I have no beef with process, I just find that the hooting and hollering over software methodology fairly asinine. Worse, the most stupid rules wind up getting embedded into company policy if you're not careful. So, let's assume that different approaches work for different numbers of people (shocking). How would you break down work for a > 1 MLoC codebase with lots of people on it? How do you ensure it gets done? I wo…

Its refreshing to see someone suggesting systems engineering as the solution to managing complex software projects. I have felt, and occasionally advocated, this for years. I'm actually surprised how little systems engineering methodology has penetrated the tech industry. Have CMMI and similar initiatives soured commercial enterprise on the idea?

Systems engineering is especially important when software is part of a larger multidiscipline project. All discussions here seem to focus on pure software projects.

Re: Why don’t software development methodologies work?

#149

Post by jasonwocky »

beat wrote: post #83
huherto wrote: post #46

They work, but you still need very capable people (developers, managers, product owners, etc). Furthermore, if you have a very capable team, you may not even need a formal "Methodology".

Depends on the size of the team. If you have a 5 or even 10 person team, then maybe. If you have 100? You need methodology. Once you break a project down into subcomponents that interact, you need to coordinate release of any changes to interfaces, so the work of one team doesn't break the work of another.

Exactly. Lots of things "work" for small projects. Try to scale some of those strategies, however, and things break down.

Re: Why don’t software development methodologies work?

#150

Post by vonmoltke »

mcguire wrote: post #78
Refefer wrote: post #31

An important realization I made a while back was that design methodologies do little to address program correctness, which is almost always the wildcard on deliverables; buggy software means missed deadlines and budget. Some, such as TDD, work to address the rapid building of tools to a particular spec, but often fail to promote static guarantees, especially in languages and environments where such provability is lar…

" I find it no surprise that the larger companies have made foundational maths, such as category theory and abstract algebra, the underlying abstraction for their general frameworks. " I would like to learn more; do you have a specific example? Having worked with real "engineer" engineers, I've found that they have, and value, a considerable amount of mathematical education, but that education is all in continuous ma…

As an electrical engineer who briefly flirted with computer engineering, I had 4 semesters of continuous math and 1 semester of discrete math[1]. I also had classes like linear systems and electromagnetics where I had to actually use continuous math heavily.

While I do not think continuous math is particularly useful for general software development, I think it is very valuable for specific problem domains. I have found my Calculus/DiffEq foundation to be very valuable for my work with radar signal processing and NLP code, more so in the former because it was basically translating electrical engineering algorithms, formulas, and concepts into C. It is also important for any type of development that makes heavy use of geometry.

As a side note, I saw some of the bias you describe out of the more "pure" EEs I worked with when I first started. There was a strong bias against software engineers, particularly those who went the CS route, because they didn't understand the math and physics behind the hardware. Admittedly, some were clueless and probably should not have been writing software for multi-million dollar hardware[2]. Most were competent, though, and able to pick up the basics they needed to know when tutored for a bit.

[1] Which was actually titled "Discrete Mathematics", and was just covered basic set theory, combinatorics, and linear algebra. [2] Like the one who added a reset routine that blindly opened power contacts on the UUT without verifying that the power supplies were off first. Fortunately, that was caught before they actually opened with hundreds of amps going through the bus.

Post reply on HN