The best approach for software development | Hacker News Reader

The best approach for software development

craftedsw.blogspot.co.uk

73 pointssandromancuso33 comments

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.

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.

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

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

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

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

Providing a consistent interface to the development team adds value. Consistency within the team itself adds value as well. Picking something from the big list of methodologies and doing it consistently gives better results than doing whatever on wednesday afternoon. If nothing else, it lets teams identify procedures that don't work for them, so they can customize the methodology for their environment.

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.

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.

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.

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.

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 :)

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.

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.

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

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.

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.

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

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.

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

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

best approach for software development: trial and error

next best approach for software development: stop talking start acting

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

That one made me laugh!

lol cracked me up. this is pure gold, thanks!

I always tell my team "there are people who program and then there are people who /talk/ about programming, be the former"

I always try to hire the ones who program. People who program learn domain knowledge and become better developers through ... writing code.. their managers leadership and not talking about methodologies all day long but actually executing and learning from their mistakes!

I tell them if they'll get to work -- I will worry about requiring things like testing frameworks that add overhead but only when they add more value than the overhead costs.

methodologies attract cringeworthy acronyms, lets dub this gtfowidd, get the fuck on with it driven development, and lets all just go back to however we were doing it already ;)

A.k.a., Programming, Motherfucker!

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

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

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

wow, i can't tell if its irony or not. who said you can't do trial and error coding without a certain amount of standards, which include coding standards, dry, peer reviews etc.?

sure, you can squeeze out some ok code from bad developers, by making them follow enough conventions. but are they really what you want in your company?

"i don't have a choice, that's not my company and not my employees" - sure you do. build your own

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

Reply on news.ycombinator.com