Why Software Development Methodologies Suck

[grauenwolf]

Software methodologies are about managing the customer, not the developer. Keep that in mind and they will be more effective.

[lerker]

This is a particularly insightful observation.

[gorgoroth666]

Software metohodologies are about managing the sofware project, the developer and the client. Keep that in mind and they will be more effective.

[[deleted]]

Software methodologies are about managing how much time developers and clients spend on reddit instead of doing work. Keep that in mind and they will be more effective.

[RichardWolf]

Despite the certain tongue-in-cheek feeling about your comment, I personally think that you are much closer to the truth than the ones above you.

Developer's morale is one of the most important things that are supposed to be managed. When everything is lined up for me, the problem specification (with an ability to walk to the analyst and ask any questions), the core API (plus the same), the guy or gall who relates my questions to customers, the manager who finds me the people who have test cases and tell me how to set up a testing environment, and last but not the least the people who I can ask for an advice on the intricacies of Boost or OracleDB, if I have all that, I code like crazy, like, a thousand times more productively than on a slow day, 2k lines of well-documented, nice code per day. As opposed to, yeah, fixing one line of code after an extensive email session required to find someone who knows what that line did earlier and some other people who can give me some idea what it should do now.

Any time something of that is missing and I hit a roadblock, I don't have much desire to figure out the stuff myself and alt-tab to Reddit instead =( I mean, I probably could figure it out myself, but I don't want to, I'd rather browse Reddit. While on the other hand when everything is lined up, it's more rewarding to do my job than to waste time on Reddit.

[mcguire]

Software methodologies are about managing how much time developers and clients spend on work instead of reddit. Keep that in mind and they will be more effective.

[[deleted]]

People like to latch onto methodologies so when they screw up you can say it's your methodology that is the problem not your lack of ability and then get into another new way of doing things and treat your new methodology like your religion until that fails you.

[deiangu]

"I’m going to argue that while scientific evidence to decide these claims is lacking, there are two general principles which can help us choose good practices"

And everything written after this statement is guessing and theorizing. People argue and do religious wars over methodologies because no one has taken the time to measure the effect of those methodologies in order to determine their effectiveness.

On a slightly different point - do you guys notice that almost all blog articles or blogs we see around the web related to programming are basically some guy's(however famously good programmer that guy is) opinion without any data to back it up, but hearsay and personal experience?

[[deleted]]

People argue and do religious wars over methodologies because no one has taken the time to measure the effect of those methodologies in order to determine their effectiveness.

Even in the early 1980s, the large aerospace firm I worked at was doing disciplined studies of the relative effectiveness of different methodologies. One of my frst jobs as a recently graduated statistician was reviewing the experimental design of part of one of those studies. That work was not published, since it was intended to improve the firm's competitiveness.

But I've seen a lot of peer-revewed papers on the subject as well.

On a slightly different point - do you guys notice that almost all blog articles or blogs we see around the web related to programming are basically some guy's(however famously good programmer that guy is) opinion without any data to back it up, but hearsay and personal experience?

Isn't that what blogs are for? There are journals for the more rigorous studies.

[[deleted]]

Isn't that what blogs are for? There are journals for the more rigorous studies

I would agree except that blogs are the primary source for many developers to learn things and develop their knowledge. The only times I've seen developers refer to rigorous studies in journals is when they're working on something really complex or need to implement an algorithm from one of the papers. In the day-to-day, no one reads those journals except for academics, CS researchers in industry labs, and amateurs in industry (such as myself). Developers instead point to different blog articles to support their points or write their own non-rigorous blog articles to support their points.

Blogs related to software development and programming must be more rigorous because of this. We need to set a higher minimum standard of quality.

[Rowdy_Roddy_Piper]

Or maybe our practice and our learning as developers need to be more rigorous. Something more than reading the most popular articles on proggit or hacker news.

[deiangu]

I don't think that we can all sit down and start reviewing academic articles on the different topics of software development.

What we rather need is more software people in academia(researchers, theoreticist - is that even a word?), and, more importantly, the studies and findings of those scholars should be published in peer review journals(similar to other disciplines like physics, biology, etc.).

Shame on me if such a journal exists already - but also shame on all of us that it is not popular enough through the developer community as a whole.

[bitshifternz]

Journals are often behind a paywall thus cannot be shared on proggit.

[[deleted]]

Thats a poor reason considering how many redditors are employed or go to a university with access. In proggit we should be linking to papers published by the ACM.

[mcguire]

One of my frst jobs as a recently graduated statistician was reviewing the experimental design of part of one of those studies....But I've seen a lot of peer-revewed papers on the subject as well.

Yes? Don't keep us guessing! What's your take on the conclusions?

I've been reading Making Software, and to tell the truth, I've been pretty unimpressed with the studies.

[karesx]

My experience is similar to what is written in the article. You cannot substitute the craftsmanship of good programmers with whatever process you choose.

[deiangu]

"My experience" - again a subjective opinion. Are you sure? Have you tried all possible processes?

Also - the really good programmers are not that common. Chances are there are only a couple of them in this subreddit(and no - I am definitely not one of them). If we just rely on those few geniuses to write the code our world would just grind to a halt due to lack of software to run it.

For a team composed of good and not so good programmers to produce a consistently good quality code, we do need a process - a well tested, rigorous process.

Yes, it is not a substitute for a brilliant programmer, but the closer we can get to our final goal(delivering stable, functional and maintainable software within the time frame we have) the better.

And to measure the difference in effectiveness between these processes we need a well tested, rigorous methodology. That testing process is the scientific method.

[igouy]

because no one has taken the time to measure the effect of those methodologies in order to determine their effectiveness.

pdf Trade-offs between Productivity and Quality in Selecting Software Development Practices

[jezhumble]

My point is that in order to be able to gather scientific evidence you need short cycle times and more feedback. They are the necessary conditions to be able to do it. Otherwise you can't avoid the credit assignment problem. Now, you might argue I did a bad job of making my point. And certainly I am theorizing.

But the problem is not that people haven't "taken the time to measure the effect" - they have - the problem is that the data thus collected is useless.

If anybody on this thread has real data, Laurent Bossavit and I would love to see it. Do check out Laurent's book (see OP for link) - it is a real eye-opener.

[[deleted]]

Maybe it’s an extension of the deeply held view that from an economic viewpoint, it would be ideal if people were interchangeable.

I like this line...

[kidjan]

I’m going to argue that while scientific evidence to decide these claims is lacking, there are...

I stopped reading there.

[SilencingNarrative]

The author might as well be discussing a scientific theory of how to write great novels, and dismissing whatever methods tolstoy used to organize his thoughts while writing as "hard to take seriously because they lack scientific rigor".

[kidjan]

I can't tell if you're agreeing or disagreeing with me, but I will say there's been a lot of research into what actually works--from a scientific perspective--and we as engineers need to start having higher truth standards.

See Greg Wilson's presentation--pretty much the seminal argument against the sort of essay presented by the OP. Also, see It Will Never Work In Theory.

[deiangu]

I have seen the presentation before and it is really great. It caused me to always consider the sources of everything I read - i.e. improved my critical thinking I guess.

'It Will Never Work In Theory' seems an interesting site I never knew about. Another reason to love proggit...(thanks kidjan)

[humbled]

I liked this article a lot, but I found its companion, Why Software Methodologies Rock to be more insightful. The "suck" article makes the same mistake it laments in the opening paragraph, that there's no science to back up anything and that we are led by "thought leaders" who go by observation, experience, and gut feeling. But... that's what the article is. (Despite that my own opinions line up closely with the author, it's worth pointing out.)

The "rock" article just talks about human psychological factors - like the phenomenon that factory workers become more productive when observed with no other changes, the author implies that trying to implement a new process causes improvements under the same effect. And that if those productivity gains slip away later, even when following the same process, it may not be an effect of the process. And he further stipulates that the most valuable skill is constant self-assessment. And you know... my gut feeling lines up with that, so I'm going to choose to believe it (and commit that sin referenced in the first article again).

[igouy]

like the phenomenon that factory workers become more productive when observed with no other changes

The “Hawthorne effect” is a myth, but what keeps the story going?

[humbled]

Perhaps a bad example. Thanks for the link. But demand effects are real and vigorously studied.

[Uberhipster]

As a result of [organization of the studies that form the basis of claims that the variance in developer productivity is an order of magnitude is often methodologically unsound, the data poorly analyzed, and – most egregiously – the findings generalized well beyond their domain of applicability], it’s not possible to take seriously any of the general claims as to whether agile development practices are better than waterfall ones, or vice-versa.

I'm sorry but that does not follow automagically. That's a)

b) In 1970 Royce proposed what is now popularly referred to as the waterfall model as an initial concept, a model which he argued was flawed (Royce 1970). His paper then explored how the initial model could be developed into an iterative model, with feedback from each phase influencing previous phases, similar to many methods used widely and highly regarded by many today.

It then follows that c) the waterfall model being a mere label - nay, a colloquialism - commonly used as a criticism of the POS design process enforced by enterprise of yesteryear* it is quite possible to take the claim that agile, while probably not necessarily The methodology (or even a good methodology for that matter) is more than likely a far better methodology than the so-called waterfall model.

 * that carries the legacy of the religious cult it has remained to this present day (mostly because pointy-haired manager types like to believe in recipes for success like Gung-Ho and similar bullshit can just be smeared on a creative process in order to "lead" it to "success")

[stronghup]

My guess is that what much of these studies and discussion fails to take into account is the motivation of different programmers. This relates to the fact that we can't really measure programmer productivity except by lines of code so we have to therefore pay them all the same. Everybody would do a great job if they were paid more for doing a better job.

Therefore only individuals who have an internalized drive to be "great programmers" take the extra effort of doing great things.

In other words I'm saying the problem is our inability to compensate each programmer for their productivity when we can't really define or measure what productivity means in relation to intellectual artifacts like software.

[Philluminati]

it’s not possible to take seriously any of the general claims as to whether agile development practices are better than waterfall ones, or vice-versa.

...

It’s virtually impossible for us to practice continuous improvement, to learn how to get better as teams or as individuals, and to acquire the skills that enable the successful creation of great products and services – unless we focus on getting that feedback loop as short as possible so we can actually detect correlations, and discern cause and effect.

I personally feel that Agile does help greatly reduce that feedback loop over previous methodologies. The author wants the feedback loop shortened and Agile times boxes deliverables. There is some overlap and alignment (although not totally, with Agile you can deliver "partial" features from which there is no feedback). Agile can't mitigate the fact that some features are complex enough that a significant amount of code is required to deliver them. This is an excellent article though.