unclebobmartin

10 ms·

31.
by unclebobmartin 14y ago
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 wo
32.
by unclebobmartin 14y ago
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 prescribe
33.
by unclebobmartin 14y ago
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 problem
34.
by unclebobmartin 14y ago
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.
35.
by unclebobmartin 14y ago
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 "O
36.
by unclebobmartin 14y ago
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-...
37.
by unclebobmartin 14y ago
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.
38.
by unclebobmartin 14y ago
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 irrespect
39.
by unclebobmartin 14y ago
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.
40.
by unclebobmartin 14y ago
And _my_ point was that startups cannot afford _not_ to adopt TDD. TDD does not take time, it saves time. It saves time _today_.
41.
by unclebobmartin 14y ago
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 inevitabl
42.
by unclebobmartin 14y ago
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 s
43.
by unclebobmartin 14y ago
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. Estimat
44.
by unclebobmartin 14y ago
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
45.
by unclebobmartin 14y ago
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 th
46.
by unclebobmartin 14y ago
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.
47.
by unclebobmartin 14y ago
Please use the air-sickness bag located in the seat back in front of you.
48.
by unclebobmartin 14y ago
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 relfect
49.
by unclebobmartin 14y ago
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 work
50.
by unclebobmartin 14y ago
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 d
51.
by unclebobmartin 14y ago
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 c
52.
by unclebobmartin 15y ago
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.
53.
by unclebobmartin 16y ago
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 lear