The best approach for software development

[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".

[k_bx]

My version of TLDR:

Article is good-written irony-style novel about relation between developers and "best practices" out there. Author is making a high-level (a bit sarcastic) review of bunch of methodologies like NASA strategies, TDD, BDD, DDD, Toyota Kaban, Scrum etc.

There's no point just reading TLDR, go and read the article itself.

[zenogais]

So another reiteration of "The Mythical Man Month" theses.

[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.

[morphyn]

True. Not caring about development methodologies doesn't seem like a better approach though.

[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.

[lmm]

>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.

Which is a result of the wrong methodology, and what the modern approach tries to prevent.

And you know what? It really is better. I don't for a moment believe that everyone was doing agile-type development and then in 1968 they discovered NASA used BDUF and decided to adopt it. Software engineering is a remarkably young field, we really do know things now than we didn't know ten or twenty years ago. If you're following what was the best methodology a year ago, it probably isn't the best methodology now - there is no contradiction there.

Just don't for a moment try and tell me that the old ways are better. Because that's really not true.

[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.

[einhverfr]

Additionally the tools are not necessarily all mutually exclusive. I don't see why you can't put real engineering effort into your database and build the app on top of it in an agile way for example.

[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

[Apocryphon]

Like all methodologies, it has a formal name despite its informal nature:

http://c2.com/cgi/wiki?CodeAndFix

[rjzzleep]

next best approach for software development: stop talking start acting

[jawr]

I think the best approach is whatever feels like the best.

[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