
Why Software Development Methodologies Suck - jpro
http://java.dzone.com/articles/jez-humble-why-software
======
blindhippo
Managers and methodology pundits are focused on a dogmatic application of
their particular religion regardless of whether it makes sense for the actual
application. I have never seen a specific methodology work in reality when it
was followed to the letter - people just don't work like that.

This is a very big reason why I doubt the effectiveness of creating a class of
"managers" who's skill set is "managing". How can a graduated MBA lead a
software development team without knowing the business or the domain?

Management, to me, is a skill that is learned through experience, not taught
in a classroom. And it is in the classroom's where dogmatic methodologies are
most prominent.

~~~
api
In other words: like most dogmatic religionists, they're in search of a way to
live without thinking.

"How can a graduated MBA lead a software development team without knowing the
business or the domain?"

The MBA is the American capitalist equivalent of the Soviet apparatchik.

------
agentultra
The methodologies don't, "suck," and the author points out in eir conclusion
that not having any methodology is bad.

It's the organization part that's important. Methodologies will work
differently depending on the make up of the team. The important part is
discussing what works and eliminating what doesn't. Only then can you flush
out the gremlins of the mind and focus on the work.

That being said -- too much methodology is a gremlin of another kind. There
needs to be enough process and practice to ensure everyone understands what
needs to be done and how to consistently go about it. My favorite motivator is
responsibility. Let the team members in the trenches make the decisions and
make them own the consequences of their decisions. Winning feels so much
better that way compared to being led by a dogmatic agile-XP-scrum-master.

~~~
peteretep
I think (and have argued: <http://xrl.us/bmeqcm>) that the problem with most
development teams - Agile or not - is that the people who are on point to make
the deadlines (the Project Manager and/or Product Owner) usually don't have
the agency to increase resources or move deadlines - they normally just have
the ability to bully programmers and decrease software quality (pressure on
tests and documentation)

~~~
wpietri
Let me just say this flat out: if the product manager can't change scope and
deadlines, then they are not doing anything I recognize as Agile. Fixed
scope/fixed date approaches are the exact opposite of what every Agile pioneer
had in mind.

------
luu
I’ve read a lot of software engineering research[1], because I’m interested in
being as productive as possible, but SE research reminds me of a lot of
empirical economics from the 70s. People were (and still are) trying to figure
out what can be done for developing countries. Back then, researchers more
much more likely to try to figure out what methods were the absolute best,
period. Now, people are much more likely to acknowledge that there’s path
dependence, and that something that works in one context may be completely
useless in another context.

It’s rare to see serious empirical work in SE that’s up the same standards as
empirical work in modern economics (either an RCT, or a good pseudo-experiment
from a clever instrumental variable), and when you do, there’s little to no
discussion of how generalizable the work is. There’s often a paragraph about
how the study may not generalize, which seems to be enough to satisfy peer
reviewers, but isn’t nearly enough to figure out if the methodology under test
has any applicability whatsoever to your setting.

[1] if you're curious, and want to look up what's in vougue, the premier SE
conferences are ICSE and FSE

------
ChrisNorstrom
I always thought methodologies suck because of their lack of evolution.
They're too rigid in a fluid world. They stay the same for years while the
world around them is constantly changing. They attempt to take one idea, one
theme, one solution and apply it to every problem rather than looking at
everything on a case by case basis.

Humans don't like thinking, it's expensive, it requires time and effort. So
people like to think once, find an answer, copy and paste that answer over and
over, and never think again.

It's the ultimate human mistake, trying to use simple dumbed down solutions to
complex problems. The same goes for
liberal/conservative/christian/muslim/jewish/athiest/republican/democrat/libertarian
ideologies. Any time you group a series of solutions together into an idea,
party, or organization you've given them planned obsolescence.

------
strife25
I found the following to be the main point of the article:

==================================

You might think that puts us in an impossible position when it comes to
deciding how to run teams. But consider why software development is not a
regular environment, and why it is so hard to run experiments, to acquire
skills, and to measure which practices and decisions lead to success, and
which to failure. The root cause in all these cases – the reason the
environment is not regular – is that the feedback loop between making a change
and understanding the result of that change is too long. The word “change”
here should be understood very generally to mean change in requirements,
change in methodology, change in development practices, change in business
plan, or code or configuration change.

There are many benefits to reducing cycle time – it’s one of the most
important principles that emerges when we apply Lean Thinking to software
development. Short cycle times are certainly essential for creating great
products: as Bret Victor says in his mind-blowing video Inventing on
Principle, “so much of creation is discovery, and you can’t discover anything
if you can’t see what you’re doing.”

But for me this is the clincher: 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.

==================================

Jez seems to believe that Development Methodologies suck when they reach the
point of __getting in the way of developers creating things __and when you
have long cycle times before you can see the fruits of your labor, wonderful
ideas are potentially lost. One of the important aspects of Continuous
Delivery is to reduce that feedback loop as much as possible - people start to
do amazing things and create wonderful ideas with immediate results to the
changes they are making.

------
jakejake
One of the reasons I think we don't have a clear understanding of methodology
effectiveness is that there's too many other variables. For example you could
take the same team, completing the same project and have them work under
different methodologies in order to see which one was the fastest, best
quality, etc. but even that isn't possible since the team would be better the
second time around. Also what works for one team may not work for another due
to personalities, work culture, etc. different projects may be better suited
to a different approach. We tend to want to find the one true methodology, but
I don't think it exists.

I tend to think that just using any methodology at all will tend to give
better results because it means the team is at least attempting to manage the
process. It usually means that at least somebody on the team cares about
keeping some kind of organization. Even if it's a loose version of a
methodology. Having no methodology at all can work too, but tends to rely on
heroics and can be more stressful for everyone - especially the other people
in the company who need to plan their work around the development schedule.

