There is No Right Way to Develop Software

The problem here is that these arguments are bulking together many completely different things under the heading of 'software'. This is like trying to find a correct way to 'grow plants'. If you try to grow rice the same way you grow wheat, it's not going to work. This is obvious for plants and should be very obvious for software also.

For example, if you're developing a web-based payment processor, you should have unit tests everywhere and possibly additional runtime tests ensuring transactions are completing properly and are stored in the database, etc.

If you are developing the software for a pacemaker, unit tests just aren't going to cut it - you will need to logically prove all parts of the software work. You will need to test each piece of hardware to ensure it meets requirements. You will need to do hundreds of hours of physical testing to ensure everything works in different environments and with different electromagnetic interference. Just doing a bit of TDD is laughable here.

Lean startup validating an idea? History shows that simply shipping and having something that users can try to use is more than enough. If it breaks and goes down for hours? No problem - customers will sit there hitting F5 for hours for the chance to use it again. If nobody wants to use it, your tests are wasted anyway. In this environment, having something that partially works is better than something that isn't done yet.

There are millions of other cases, each of them unique. Software development is not building bridges. Please never use that analogy - a bridge is a fixed, known, and obvious requirement and solution. Software is the very opposite of this - if you compare 'software' to the combined industries of fabrics, farming, engineering, carpentry, electrical work, industrial building, home building and many more, then your analogy is closer to the truth.

I have an interesting experience with this recently. I have been doing ruby now for a few years, I have immersed myself in the culture and concepts. I am wanting to level up on my programming skills, so I am trying to learn Go.

I went into a golang irc channel, and was labeled as "ruby brainwashed" because of the way I approached my questions on Go syntax and concepts. I admit I had a hard time mapping object oriented concepts I had come to love in ruby to the different OO model of Go. These guys genuinely thought I was doing things wrong! - it has been a been a wake up call to the many different approaches and opinions.

Eh, the standard "I don't know which way is best, so there must not be any objectively better or worse ways".

There clearly is a correct way to develop software. It's just not clear that we've got enough experience with it to a) have found it, b) to recognize it, and c) to correctly confirm it to a reasonable degree.

As I commented on the article, the whole thing sounds a lot more silly if you replace "software development" with "building bridges" or the equivalent civil engineering task. There are clearly better, safer ways to construct bridges, and I'm fairly certain the same is true of software.

The truest statement I have read in these comments so far is that we don't yet know the best way or ways to do software development. There might be one or more best ways, but we don't know.

The article is valuable in pointing out that most purported "best ways" are dogmas, and, despite claims of being scientific, they tend to veer off into pseudoscience.

And yet, if you don't have a plan, if you don't apply the best available tools, and if you don't have expertise and experience, you're going to have a bad time.

That leaves software development as something less than engineering, and more like a craft. You can't make it happen, or manage it, without expertise, creativity, and intellect.

Attempts to stuff it into a contained, measurable space almost always result in perverse incentives and efficiency comparable to a Soviet 5 year plan.

But that doesn't mean that a best way doesn't exist, or that it will never be found.

Novices generally don't have enough experience to distinguish between situations that require a "best" practice and those that don't, hence advice given to novices is generally phrased in absolute terms: "Never...", "always...", etc. Experienced programmers have used the "best" practices enough that they know their limitations, and so they pick and choose accordingly.

pragdave gave a great talk on this very subject a few years ago: http://www.infoq.com/presentations/Developing-Expertise-Dave...

It all boils down to maintainability. Do I want to even attempt debugging or adding features to a 10,000 + line ASP.NET Web form page? What about a MVC project where someone took the time to observe separation of concerns and wrote unit tests for everything? Automated tests of any sort will save you when the code base grows, and it will. There are different code smells for different languages and platforms but the real developers will smell them out and see them for what they are, the wrong way to write software. Bad code is bad code and it is always the wrong way.

I completely agree with the author. I think this can be summarized as "do whatever works best for you". Best practices are great - if they work for you. "Best" is highly subjective in my opinion.

No, look, there really are good and bad ways to develop software. If there weren't, no-one would have invented TDD, in fact we'd still be doing everything in FORTRAN. Yes there are disagreements, but we should respond to that by looking deeper and figuring out which parts of each approach are good and which are bad, not throwing up our hands with some relativist "oh, whatever works for you must be the right way, there are no absolute truths".

I love "strong opinions weakly held"!! I couldn't agree more.

wisdom is to know when to apply a theory, knowing when to use a methodology. :)

WHen someone says, hiring remote workers is necessary they are talking about it in certain context. Although they might fail to mention that context, or may even fail to notice that underlying context. Not noticing the context doesnt make them fundamentalist, it means that they are not much rigorous or they reached the particular conclusion by trial and error.

However to believe in any such conclusion without trying to understand the context or just not being aware to the fact that there might be a context is a folly on your part and not someone who mentioned a particular strategy which worked for them.

Agree that there's more subjective than objective in best practices. That said, there's nothing wrong with developing and publishing best practices. The fault is in those who turn them into a rigid "bible", rather than food for thought.

These kind of posts are a natural response to all the TDD hype.

This reminds me of the politically correct, relativist nonsense that one often sees in response to the existence of multiple, mutually exclusive religions.

There may not be a single right way to develop all software, but as with questions of morality, there are certainly better or worse ways, and in principle, we can find them through science. Hopefully we can at least come to some definitive conclusions about "worst practices", if not best practices.

There is no right way, because the term "right" is ambiguous and subjective. Even a ridicuously bug-ridden software can be considered "done right" if the requirements were quick development time and correct results for a single certain case (think of single-use one-liners). However, for example, the only known way to [provably] have a bug-free code is, unsurprisingly, to prove the code is mathematically correct.

In fewer words:

There exists many context-related local maximas.

I think the key here is environment. If you are in startup, writing thousand lines per day, then sure tests are not for you. But guy, who takes over code after startup is sold, will have different opinion.

nope. you're wrong. there _is_ a right way.

and furthermore, the best way to write an essay is to organize a meticulous outline in advance. and then _stick_ to it, executing it faithfully.

and the best way to take a trip is to _plan_it_, with maps and tourist books, and not waver from the schedule you made, even if (especially if!) you're lured to a bar by someone you wanna boink.

stop doing it wrong!

-bowerbird

ah, the sweet voice of sanity

My comment without even reading this article: Yes. There is.

I asked an experienced Bridge player about bidding conventions, and if there was one right way to bid a hand. He said, "there isn't one right way to bid, but there are plenty of wrong ways."

That's how I feel about software development (and business operations in general). Is there an inflexible, one-size-fit-all, "right" methodology? Hell no. Even open allocation (which isn't really a methodology) isn't right for every company out there. There are, however, a ton of wrong ways to do things. The sad thing is that, because most people are driven by a mix of ego and incompetence, wrong ways of doing things are the most common.

You're Doing It Wrong if:

* managers have more power than engineers.

* mutually positive contributions (good for engineer and for firm) are disallowed for political reasons.

* people can't get shit done because of too much pointless process (to start writing code, you need a Jira ticket).

* stand-up takes 45 minutes and people sit down.

* people are micromanaged and start doing things badly, or overmonitored (the hidden danger of too much Jira activity) and start panic-coding.

* designs are made by incompetents.

* ... and many, many more.