This article on Techcrunch sure ruffled some feathers. Quite frankly, it's conclusion was mediocre at best, but we're already talking about Techcrunch. Developers and the press and software makers love to run to new tools. I have of course been guilty of it myself on occasion. I used to think hibernate was the Holy grail back in 2003. The flocking is due to what the article mentions. Software development feels broken.
I don't think so.
I work with startups. Either as a consultant, or I've been inside them working as and with founders that weren't technical. My favorite metaphor across an organization is building a house. There are a lot of ways to do it! We've been building houses for 4000 years if not longer. Yet talk to someone who just had a house built or is renovating one. It can be a nightmare.
But it's not always a nightmare – It is just complex.
I tweeted about the article and then discussed it with one of the developers that works for portfolio company 123Linkit. Daniel is one of the best Ruby developers I've seen work for me or my portfolio companies. He fully explains what he's going to do and he's cautious about his estimates. He gets things done. He is a huge advocate of Test Driven Design and Unit Testing. There are many at Indy Hall that fall in this camp. I on the other hand have never been in a TDD shop nor have i run any of my own shops that way. I just never could see the value in it.
The article mentions the hate of TDD, it doesn't really go into why. I never had a why either. It just felt inefficient. I've tried it. I've gotten committed and put the work in for a couple months. But then I always prefer features. I never felt the tests were "catching anything." So I stopped.
I've never looked back. My latest software project was 9 months of development and has been running in a real-time environment for 18 months without a single outage. There are constant enhancements that are deployed by the dev team without a test.
How?
1) Code Review. Code Review takes less time than TDD. People hate it more that testing but can get with it.
2) Communication - features are documented simply. In email with excel or google doc explaining what it will do.
3) Typed langauges. On this project we used Java and Google Web Toolkit. Half the things Unit tests would find are found at complie time (really coding time, because the IDE flags it immediately)
But really it's number 1. Tests won't find flawed architecture. Tests won't find bad algorithms. Tests won't even find bad code. Just wrong code. Code Review gets everyone talking about the problem AND the solution. The team gets on the same page. And that is what is most important.