

The best approach for software development - sandromancuso
http://craftedsw.blogspot.co.uk/2012/08/the-best-approach-to-software.html

======
chimi
TLDR:

    
    
      > The bad news is that there is no best approach 
      > to software development.
    

The article is mostly rants about all the current "best practices" everything
from NASA strategies to TDD, DDD, lean, agile, etc. He thinks you should avoid
dogma and be pragmatic.

~~~
gilini
That's a very loose interpretation of what the author meant, IMO. Actually,
pragmatism in this industry leads to a series of different interpretations.

Avoiding dogma is a no-brainer, there's absolutely no advantage on being
dogmatic in software development. But the pragmatism part, I think it's OK as
long as being pragmatic doesn't mean carelessly building stuff without putting
much thinking beforehand, in whichever methodology you chose to follow.

I do believe in testing, not just software testing, but testing in general.
Let's try and test the better set of methodologies and techniques for our
scenario, mashup stuff together and come up with our very own "dogma".

------
llimllib
> My main criticism here is about how the vast majority of developers react to
> all these things. It is not just because someone, somewhere wrote a book,
> recorded a video or gave a talk in a conference about something that it will
> make that thing right, in all contexts.

The vast majority of developers probably don't care much at all about
development methodologies. The author notices the vocal minority and mistakes
it for the majority.

~~~
JamesLeonis
To play the devil's advocate, what happens when that vocal minority happens to
be in a leadership position at your company, like the director of engineering
or CTO? It doesn't even have to be a programmer who is infatuated with a
methodology in order to push it out onto other developers. Very rarely do we
individual programmers choose to use the methodologies of which we are
subjected.

~~~
llimllib
That's fine, but the author explicitly stated that the article was written
because "the vast majority of developers react to all these things." My point
was that this statement seems to me to be untrue.

------
gklitt
This is particularly timely given the recent success of the Mars rover
landing, which is a good reminder that having a ton of meetings and spec-ing
something out robustly in advance is still a valid approach in some contexts.

~~~
zumda
To be fair, especially the landing sequence (the only thing they couldn't
really patch) was very well defined from the start. They knew exactly what the
Rover had to do, when he had to do it and what steps were involved.*

Generally software just doesn't work that way. (But maybe that was that you
implied with "some contexts". In that case, I agree with you)

* I'm not saying they weren't trying out things until they decided how to land the Rover, but when they wrote the software they had very clear requirements.

------
bitdiffusion
What I took away from reading this article is that because the umbrella of
"software development" is so wide; everything from a static html page for your
local charity up to curiosity/ mars rover - it's not practical to define a
single set of methodologies, tools and techniques that will work, be pragmatic
or make sense for all situations.

Do what you think is best for whatever it is you're building :)

------
yorak
I think one reason why dogmatic advocating is so prevalent is that
introduction of new processes and methodology to a team or organization
requires considerable push. You have to overcome huge amounts of resistance
from the people the changes concern, even if your role in the organization
allows you to make the decisions. Strong opinions of your chosen approach make
it possible to overcome obstacles.

If all developers would be "inquisitive, curious and pragmatic" you could
probably rationalize the decisions and carry the necessary actions without
evangelism. Unfortunately the world is sometimes awfully imperfect.

------
mythz
Amen.

Seen too many devs pursuing the perfect 1-size-fits-all holy grail
architecture, only to leave a pile of over-abstracted technical debt in their
wake.

Quite simply, if you can't understand __why and when __a particular pattern or
methodology is effective, you can't take advantage of it and shouldn't be
using it.

An experienced programmer is confident in all his choices and able to pick the
best tool for any particular situation. Blindly subscribing to religions or
Cargo cults just clouds your judgement and leads you to falsely believe that
you wield the only hammer that gets all jobs done.

~~~
slantyyz
Yes.

You can't choose a methodology without considering the personalities and
habits of the team members. Unless you have the luxury of replacing an entire
team with people who want to work with a particular methodology, dogma gets
you nowhere.

And I'm only talking about a team. Go up a level or two to the department or
organization, and things get even harder.

~~~
HeyLaughingBoy
My god, I _wish_ people understood this. Process Methodology, by and large,
exists to create a "quality floor." Follow methodology X and you are likely to
have a product that is no worse than Y, for whatever set of metrics Y is.

But process does not create skill.

Process should exist to provide a framework or a set of limits to work within.
It won't make a mediocre developer a superstar, but it will keep him from
propagating dumb mistakes out to the customer. As a result, Process results in
less improvement from good developers, because they're already operating at a
level well above the quality floor.

In the end, randomly choosing a methodology without considering the team's
personality and culture is a recipe for frustration for some, apathy for
others and maybe a small bit of product improvement.

~~~
slantyyz
>> Process Methodology, by and large, exists to create a "quality floor."

I agree. I have this saying that doesn't win me any friends: "Methodologies
are for monkeys". (Keep in mind I use that term for project management
methodologies and not so much for development methodologies)

A lot of big companies want/like trendy methodologies because they assume it
lets them to hire less skilled people (i.e., _cheaper_ ) and continue to
produce quality work. It doesn't.

What I have found is that when you have a team of quality senior people with
_good communication skills_ and throw them together, they will hash out what
processes work best for that team without any need of formalizing their
process. This way, everyone gets to work the way they want individually with
some adjustments that allow them to work as a group.

------
jseims
To add an opinion: the most important factor in a team's productivity isn't
the process, it's the quality of the developers.

------
k_bx
What's cool about this article is that I've put a lot articles to read later
about :) Thanks.

------
rjzzleep
best approach for software development: trial and error

~~~
rjzzleep
next best approach for software development: stop talking start acting

~~~
k_bx
No, it's been there for a while already <http://programming-motherfucker.com/>

~~~
emeraldd
That one made me laugh!

------
nsxwolf
1\. Write some damn code

2\. Release the damn code to QA

3\. When QA finds a bug, write a damn test

4\. Fix the damn code until the damn test passes

5\. Release the damn fix to QA

