unclebobmartin

The advantages to Java: * Lots of programmers know it. * Execution speed is very fast. * Static typing can help you find some bugs. * The tooling (The IDEs) are spectacular! IntelliJ!!! Refactoring!!!!

The Disadvantages of Java: * It's wordy. List<Integer> l = new ArrayList<Integer>(); * Static typing is constraining. * The data representation is clumsy. Can't say: [1,2,3] * Minimal meta-programming, limited to reflection.

The Advantages of Ruby: * Terse and elegant. You can say a lot in a few words. * Very flexible. * Simple to learn (not counting Rails). * Very convenient data representations. * Powerful meta-programming capability. * REPL! * You can write really lovely DSLs. * Rails can get you going on a web app in a jiffy. It's very slick. * Development speed can be _much_ faster than Java, at least at first. Carelessness is the great equalizer!

Disadvantages of Ruby. * Slow. Damned slow. Really damned slow. * Did I say it was slow? It is. Really. * It's really slow. * Jruby is faster, but still really slow. * There aren't as many programmers. * Rails has a steep learning curve once you get past the basics. * People use meta-programming too much. This is a people problem, not a language problem; but it's real. * The tooling is nowhere near as good as for Java. Refactoring tools are pretty weak. * It's really easy to make a mess if your are careless.

The speed of Ruby is not really a huge concern in most cases since processors are cheap. But the language is really, awfully, slow.

If I were starting a new website project, and had to choose bewteen Ruby and Java, I'd pick Ruby and Rails, and then I'd be _very_ careful with programming disciplines.

If I was starting a new enterprise project for a large company, I'd write the backend servers in Java, and I'd consider writing the frontend in Ruby, especially if the frontend was web based.

For thick client apps, I'd likely write them in Ruby using LimeLight on the front end.

BTW, immutability has nothing to do with encapsulation. Encapsulation is the hiding, or access restriction, of data structures from "foreign" functions. Those foreign functions may only manipulate the encapsulated data through a prescribed set of functions.

We achieve this in clojure through clojure's lovely typing mechanism which allows you to declare types that have publicly known functions without any data declarations; and private implementations of those functions that know the data they are manipulating.

One last note. C was much more encapsulated than C++, Java, or C# because in C you would declare your functions in a .h file, and your variables in a .c file. No other .c file could see your variables, so they _had_ to use your functions. The public/private keywords were added to C++, and then to Java and C# because the act of putting variable and function declarations in the same source file broke encapsulation, and we needed a way to re-assert it. That reassertion was only partially effective.

The bottom line is that all the C based OO languages are _less_ encapsulated than C.

Think about what immutability means. It means that there's no assignment statement. If there's no assignment statement, there can't be any side effects. If there are no side effects, you can't race conditions or concurrent update problems. You can't have resource leaks. You can't have order dependencies.

Does Clojure guarantee all these things? Not entirely; because Clojure allows you to invoke the java stack, which is decidedly not immutable; and because clojure provides mechanisms for changing state; albeit with significant discipline imposed.

The end result is that clojure is _much_ safer to use in complex and multi-threaded systems, and is likely much, _much_ safer in extreme multi-core applications.

What I find fascinating in all this is the sheer amplitude of the invectives. Apparently TDD pushes some people's buttons. I think that's a good thing.

Your edit is one of the reasons. However, writing two or three functions in order to get a test to pass is something I frequently do. The functions are small, and usually have very little implementation at first; but I don't follow the "One Function - One Test" rule.

The rule I follow is: Every line of code you write is to make a failing test pass. If that means writing three new functions, so be it.

Interestingly enough, in 2009 Keith Braithwaite concocted a metric that can pretty reliably determine whether a system has been written with TDD or not.

See: http://peripateticaxiom.blogspot.com/2006/05/complexity-and-...

Keep in mind that surgeons had plenty of empirical evidence that hand washing saved lives; but refused to adopt the discipline for several decades claiming, among other things, that doctors did not have time to keep washing their hands.

The idea that TDD involves some kind of blind faith that the tests will generate grand designs and beautiful code is both silly and wrong. You are right about that. Good design and good code require skill, thought, and knowledge irrespective of whether you are using TDD. So as I practice the discipline, I am thinking all the time about larger scale issues, and I am _not_ being blinded to those concerns.

However, the act of writing tests first has a powerful benefit: the code you write _must_ be testable. It is hard to understate this benefit. If forces a level of decoupling that most programmers, even very experience programmers, would not otherwise engage in.

It also has a psychological impact on the programmer. If every line of production code you write is in response to a failing test, you will _trust_ your test suite. And when you trust your test suite, you can make fearless changes to the code on a whim. You can _clean_ it and improve the design without trepidation.

Gaining these benefits without writing tests first is possible, but much less reliable. And yet the cost of writing the tests first is no greater than writing the tests second.

There have been several posts on this thread in which research papers in support of TDD have been referenced. You can find them if you simply google it. I suggest you do that.

And _my_ point was that startups cannot afford _not_ to adopt TDD. TDD does not take time, it saves time. It saves time _today_.

The safety of TDD comes from having a test suite that you trust. Given that suite, you can safely refactor the code. If you can refactor safely, you can improve the design safely. If you can improve the design, you can stop the inevitable slowdown that comes from making a mess.

What is the risk of _not_ doing TDD? The risk is that slowdown. We've all experienced it. What is the cost of TDD? You'd like to say that it takes time; but since the risk is a slowdown, the net is positive no matter how you look at it.

That's the irony of all these complaints. They assume, and sometimes they simply state, that TDD slows you down. And yet, the primary effect of TDD is to speed you up, and speed you up a lot.

Some folks suggest that it's a short-term slowdown for a long-term speedup. But in my experience the short-term is measured in minutes. Yes, it might take you a few extra minutes to write that test first; but by the end of the day you've refactored and cleaned the code so much that you've gone much faster _that day_ than you would have without TDD.

With regard to Dalke's complaints, I participated in that thread a bit; but others were doing a better job than I so I walked away. In short, Dalke's complaints were the complaints of someone who had little or no experience with TDD; and so weren't really significant complaints. Profit's paper complained more about the experimental procedure of Phil Hack's paper in support of TDD, than about TDD itself.

The reference to a "silver bullet" is a straw man. TDD is not a silver bullet. TDD doesn't keep you from screwing up. TDD will not guarantee success. But adopting and following the discipline of TDD can be remarkably beneficial, and shift the odds more towards success.

Quite a few actually. I can name two off the top. You've probably never heard of them (why would you, they failed). Saber, and Lucid. Oh, there are certainly others. What kills them is a code base that's too tangled to manage. Estimates grow by an order of magnitude, costs skyrocket, defects mount, customers flee, investors cut their losses.

I agree that in a startup software needs to be incredibly malleable, and the developers can expect to be constantly refactoring and throwing away big chunks of code. That's precisely what TDD helps you do. You _can not_ refactor without a suite of tests to protect you; all you can do is hack.

If you need your code to be malleable, for God's sake make sure you have a suite of tests you trust with your life. Otherwise you'll be slowed down by the fear that you'll break the code.

Over the years I have found that writing tests first is usually a faster way to get creative feedback. The reason is simple, the tests are easy to write, and they give you confidence that the feedback you are getting is accurate and not the result of something stupid.

Writing tests doesn't take much time since it's just a restatement of the code you already know you want to write. If you don't know what code you want to write, you can't write it. So you think about it. Once you know what you want to write, the test is trivial. Yet that trivial test let's you see the code execute, and gives you the confidence that the code you write was the code you _intended_ to write.

I agree with you about shipping faster. I don't agree with you about bugs. TDD can eliminate the more stupid of those bugs, while helping you go faster.

That is certainly your fear. It is a fear I don't share. Firstly, I think you'll get there faster if you work well. Secondly, as MySpace showed, being first isn't really all it's cracked up to be.

Please use the air-sickness bag located in the seat back in front of you.

The earlier startups ('76 and '87) gave me the experience of what a startup is like. I _was_ the warrior god. I worked 60, 70, 80 hours per week. I _knew_ I could overcome all. In one case it worked, and in another it failed.

By relfecting on those experiences, and many other experiences in companies large and small I have since learned a great deal about programming; and about human nature. One of my greatest realizations is that you cannot go fast by rushing. Every shortcut you take slows you down. Every attempt at cutting corners, adds more corners. And so I adopted the mantra: "The only way to go fast is to go well."

In 2002, when I started the FitNesse (fitnesse.org) project, TDD was the rule. I didn't know how well it would work, because I was very new to TDD at the time. But since the risk was low, I gave it a shot. It succeeded beyond my expectations, both as a programming discipline, and also as an open source project. The power TDD gave us (and still gives us) to keep the code clean and under control is something I'd never experienced in any other project. It was profound. It was powerful. It allowed us to go fast, and _keep_ going fast because the code stayed clean. I have come to view it as a moral imperative. No project team should ever lose control of their code; and any slowdown represents that loss of control.

I have since consulted on many projects using TDD, and have helped many others to adopt it. My son, Micah, who was the lead programmer on the FitNesse project, continued to practice TDD in other projects for clients of my company, with great success. When he founded his own company, 8thLight.com, TDD was a founding principle.

When it came time for me to start another company, (cleancoders.com) TDD was, and has remained, a founding principle. TDD keeps the code under control. That control keeps me going fast. I can't imagine surrendering control of the code ever again.

There's an old saying: "Your true beliefs are exposed under pressure." I'm glad your AgileZen story had a happy ending; but I think you got lucky. When the pressure came, your true beliefs came out, and they did not include TDD. You abandoned the discipline because you thought it was slowing you down. And now you are communicating that meme to the world at large. That's a shame.

As long as someone thinks TDD will slow them down, they will abandon it whenever the pressure is high enough. I, on the other hand, know that TDD speeds me up. So when the pressure comes, I hold to my discipline.

I know I can't convince people that TDD will speed them up. But as I look out over the industry from my rather long perspective, I see the change rolling across it. TDD was unknown in 1999. It has gained in awareness and adoption every year since that time. The momentum continues to build.

In another 10 or 15 years TDD will likely be as prevalent and important to programmers as hand-washing is to surgeons or double-entry bookkeeping is to accountants. I stand a good chance of seeing that happen.

To those of you who asked for "links" to studies that prove that TDD works; google around, you'll find plenty. Some are positive, some are negative -- what else is new. Now, please show me the studies that show that _your_ discipline works.

To those of you who consider TDD a religion; you are being silly. TDD is a discipline, like double-entry bookkeeping, or sterile procedure. Like those disciplines it has aspects that are dogmatic; but that aim at a purpose. That purpose is to help you write software fast and well.

To those of you who think I'm a process peddler. You're right; I am. I make a very good living teaching people how to do TDD. I have been doing so for over ten years now. I hope to continue for some years to come. My goal is to help raise our industry to a higher level of professional behavior; because at the moment our behavior is pretty poor.

To those of you who wonder whether I've ever worked at a real start-up. I've worked at several over the years. My first was in 1976; and it was very successful. Another was in 1989, and it didn't do so well. I've recently founded cleancoders.com a startup in video training for software developers. The website is done entirely with TDD. And this doesn't count the rather large number of startups I have consulted for in the last 10 years. So I've got a _lot_ of experience with startups.

Folks, I am 60 years old. I got my first job as a programmer when I was 18. I wrote my first program when I was 12 (on a plastic 3-bit computer). I started using TDD in 1999, after I'd been programming for thirty years. I continue to write code using TDD today. I've seen the startup trap. I've lived the startup trap. I strongly advise you to avoid that trap.

The winners in a brutal race have learned how to avoid as much risk as possible. The prize does not go to the biggest risker. The prize goes to those who do everything they can to minimize the risk of going slow.

What slows a programmer down? Debugging. Messy code. Fear of change. How do you minimize those risks? A comprehensive suite of tests. How do you get that suite? TDD.

For the record, I have been a software developer since 1970, and have worked at several different startups. One in 1976 which was a great success; and another in 1987 which muddled and eventually failed. I have started several of my own companies since 1990. I have recently founded cleancoders.com, which is a very successful video training startup using TDD for the website. I also work for 8th Light which is a consulting company started by my son 6 years ago, and is dedicated to TDD.

I have been practicing TDD since 1999; and have found very few situations in which it does not help me be both better and faster at my job. I would certainly never hire anyone who did not practice it.

Great post. Love all the point except 11.

You can have my IDE when you pry it out of my cold dead hand. -- Uncle Bob.

36? Of course not. Try a bit of programming for a month or two. Pick up a book on Ruby and work through a few of the chapters. If you find you start thinking about programming more and more, then keep at it. It's never too late to learn something new.