This one I'm going to have to say ... prove it. It's quite a stretch to say a "core truth" is that most software has used absolutely none of those principles.

Can you site an example?

You are talking about taxes, airplanes, and bill pay, and telling me all of those applications just got thrown together by cowboy coders?

I'm having a tough time swallowing that one. Yeah, there are bigger picture items, but to say that a list of "classic mistakes" proves these aren't used is quite a leap, isn't it? Maybe the reason the list is that way is precisely because the practices were used, so the flaws ended up somewhere else in the pipe/chain/hierarchy?

I'm just really interested to see any sort of basis for assuming processes aren't used on a wider scale, other than just a wild blog post claim. Sounds a lot like "duct tape" programming post ... let's go against the grain just to go against the grain without some tangible evidence to support it.

@Jeremy Likness  

Jak is being cynical in its usual ways, but I guess what he's talking about is about lack of perspective from a lot of developers who think that only the latest methodologies/principles/patterns/technologies can solve problems that could be solved with thorough human testing and/or bespoke automated testing.

There is indeed *a lot* of software out there built on 100s of pages of technical requirements and sometimes our lives depend on them.

Those systems, usually costly, relied on thorough human testing and probably used bespoke testing techniques too such as full scale demos using systems completely replicating live systems.

I think the difference between then and now is that a lot more software gets written and the overall pace of technical change is much faster, hence the emergence on new those new methodogies fit for these kind of environments.

Daniel

Considering I was part of what started this whole stupid arguement, I guess I'll comment.  I still don't think that Scott knows what my concerns were even after making it abundently clear over and over again.  I think he's the type of guy who sees what he wants to see (that I was somehow attacking TDD) so he can make another blog post.

I think Jak nails it right on the head here, that the developers really aren't all that important in the success or failure of a project.  When they do have impact, it's the quality of the code that matters, not how they achieve that quality.  TDD, BDD, or any other flavor of the month achronym  in no way produces good code, good developers produce good code.  Good developers also tend to use SOLID, DRY and YAGNI, not because they are cool, new tools, but because they make sense, and let's face it, are very easy to do.

TDD, BDD, et al on the other hand?  Not so easy, they fundementally change the way you work, so for some people they have a negative impact.  So we shouldn't be surprised to find out that not everyone wants to follow them.

Also, @Jeremy Likeness, are you saying that the author of this post has to prove that most software has been written without TDD, BDD, SOLID, etc.?  So, by saying that are you saying that you feel most software is written using "core" principles?  Because otherwise, I have no idea what your point is.  Anyone who has either job hopped or who enjoyed the golden age of consulting (how I miss thee) will tell you that the vast majority of applications they've seen adhere to little (if not any) of the "core" principles.  Is that proof?  No, because the sort of proof you want isn't possible to acquire.  I can tell you that I've done work for over 20 companies, most of which are world leaders in their respective fields, and the code is pretty much, universally bad.  Take that for what it's worth.

I agree with you, the process is VERY important.

Most of the problems can be avoided by having a fast feedback. If they aren´t avoided, at least they are solved early. Agile practices helps us to do that.

I think that, some practices like TDD and SOLID Principles are necessary to allow fast changes and gradual evolution of the system.

My understanding was that (SOLID and DP at least) were kind of a study of best software already written. The point was that upon closer inspection, well-written software exhibited these kinds of practices.

As for TDD/BDD, the two biggest values I get out of it, are: viewing my code from the consumer's point of view, and the low-level regression suite that's left behind means, I don't have to fire up the app and go through the entire thing again to check to make sure my latest changes haven't broken anything. Alt+T runs my test suite and I can be sure that everything that was tested is still working in a few seconds. There is certainly a learning curve, but the benefits tend to outweigh the initial slow down. At least it did for me. Now, I think I code faster with "specs" to guide my way.

FWIW - Lee

Diogo,

I'm not disagreeing, but I'm more curious. Why do you think TDD is necessary to allow fast changes?

Steve, for me TDD helps in the design, reducing the class coupling and if I have to do any change in the system the tests help me to be sure nothing else breakes.

I know this is not a rule. But, for me, those practices help allowing to be more agile.

@Diogo

TDD is about TEAM work not the individual, if you work in isolation (in a team) or solely on your own then TDD is going to be any faster to make changes, but if you're in a team it gives all members a level of certainty about the code and therefore reduces time & cost of development...

of course this is just another opinion...

sigh.

should have read...

' then TDD isn't going to be any...'

@Akward Coder,

How did you conclude that TDD is not going to be any faster to make changes? I often work alone, and my TDD habits makes me painfully aware of how often I break my own code. If I skip that part, it will take longer before I discover my mistakes. How will that speed me up?

Unsurprisingly, I agree with this.

What is as scary as the myopia, is when the myopics talk about 'drumming people out' of the profession.

I think Jak has a point in a way that Methodologies are not the most important point.

But to say that Methodologies are not important is far stretched. Everyone follow a methodology to develop software. And methodologies != TDD,BDD etc. There are lot of other methodologies and every one does follow some form or the other.

It's about "which" rather then "if". YOU as a developer has to choose a methodology based on your constraints of time and budget as well as your familiarity level.

What this whole duct tape debate has said to me is that as developers we are more concerned with the internal structure of our code than the external behaviour of the products or services we produce.

When do you ever see a developer blog about usability issues of a UI app which let us face it is what a lot of us are working on.

Usability is one of the main reasons for failure.

The echo chamber is quick to insult a code base they have never seen like stackoverflow and not congratulate what is a well performing high volume website.

People seem very quick to blogboast about how they have adopted kanban, scrum, git or whatever the hell is du jour but it is all inwards facing.

TDD is a flawed paradigm by the very nature of having to write more lines of test code than production code.  It has undoubted good side affects like higher quality code but nobody ever wants to discuss the flawed nature.  Anybody who dares challenge it is slated as unprofessional.

+1 @Paul

TDD is flawed from that respect only because developers try to use it as a measure of acceptance by\for the business - the business shouldn't even know how code quality is measured...

@Awkward and Paul,

You aren't doing TDD, obviously, because you don't want to use flawed methods. So how do you create your quality code? How do you verify your code does exactly what you intended it to do? How do you avoid to write code you don't need? How do you avoid to break working code when you apply your changes?

@thomas

You can tell I am not doing TDD without seeing any code?  That is quite a talent.

I can point you to the OSS project I am working on and you can judge for yourself and have a look at the tests:

code.google.com/.../hornget

TDD is good but it is flawed, too many things can go wrong.  We need to tighten the feedback cycle somehow.

But as ever the minute somebody dares to question it we get the usual accusations of unprofessional or in your case "You just are not doing TDD".

Why can we not debate it's worth or it's undoubted flawed nature rationally.

TDD is the best we have got right now but there is plenty of room for improvement.

@Thomas Eyde

"You aren't doing TDD, obviously, because you don't want to use flawed methods. So how do you create your quality code? How do you verify your code does exactly what you intended it to do? How do you avoid to write code you don't need? How do you avoid to break working code when you apply your changes?"

Why is TDD the only way to guarentee this?  

@steve,

I practice TDD quite successfully, which enables me to deliver fewer mistakes within the same time frame. When people say TDD is flawed, or doesn't work, that doesn't match my experience.

So I wonder, what did I miss? What do those people do to deliver fewer of their mistakes?

@paul,

I am sorry. I put words in your mouth you never said. My mistake was that I never put "good" and "flawed" in the same sentence to describe the same thing.

Why is writing so much test code a bad thing? You keep doing it, so it must give us something?

@Thomas

While I doubt it was your intent, you did make is sound like TDD was the only way to accomplish your goals.

Does BDD to an extent also accomplish everything you want and them some?  At the very least, it promises that your code does what the customer expects it to do (something TDD does not).

I'm in no way saying TDD is bad, but this perception that people are tring to give that everything done without TDD is crap really needs to go.