This is my coming out: I’m not a test-driven developer. I have stopped trying to force it onto myself.
Yet I do test.
TDD never seemed to work very well for me personally. As a consequence the process never took hold in my habits of writing code, it did not prove itself as the uber-strategy to advancing to the next engineering level.
It took me a while to free myself of thinking that by not following TDD, that I am somehow an undergraduate software engineer. Or worse. As is sometimes implied by more religiously test-driven developers.
Eventually I realized that test-driven development is a thing that you’re born to love, or you aren’t. A process that works better or worse depending on personal habits, circumstances and environment - in that sense I now regard test-driven development along other relatively subjective and debated processes, like pair programming (XP).
Moreover, like pair programming, the minimum requirement is two programmers. If there are only two programmers in your team, it’s a freakin’ waste of time to do pair-programming round the clock. In the same light my experience with TDD is specifically in environments where I was/am the sole programmer, perhaps only occasionally sharing code development with one or two other developers at most.
This is where TDD’s proposed benefits lose a lot of their weight, while its drawbacks are more pronounced, and a more “agile” process works just as well for sole developers and tiny teams.
TDD is a personal preference
Unit testing is a tool used in test-driven development. If you don’t “test first” and then write the class’ code and then refactor, you aren’t doing test-driven development, you are testing. On the other hand, you can do just that without following the formal TDD process.
In test-driven development, the tests are written first. They are made to fail because the class they test hasn’t been written yet, it’s only a stub. Therefore all tests initially fail. Then you write code. Then you test and verify. Then you refactor. Then you test and verify again.
TDD is a fairly rigorous, rinse and repeat kind of process. It formalizes the process of writing code. It sometimes feels great, other times it feels terribly constrictive. Unfortunately TDD is not someting that you can do on and off, and still expect it to be very effective. Which means you have to be a rigorously test-driven developer. That might also explain why some developers are quite religious about TDD.
I wager that TDD is significantly harder to subscribe to for certain developer archetypes than others. It makes little sense to force it on developers. A lot of the process has to do with personal preference and a certain enlightened feeling that comes when applying and succeeding with it. Likewise, others may still be in shock after weeks and may forever struggle to adapt.
What is often forgotten when adapting TDD is to actually measure key metrics for the team and individual programmer, both before and after - for some teams/individuals the benefits may be tremendous, for others it may reveal fewer defects but also slower development. Then what remains is a tradeoff: do you prefer fewer defects or faster development? This is a valid question in any product development.
It should also be considered that it takes significantly greater effort for an experienced software engineer to change his or her personal process of developing code than it is for a student. Talk about teaching old dogs new tricks. The students are also more likely to find great rewards in test-driven development as TDD encourages them to learn and experience many software engineering principles.
Undeniably, test-driven development has benefits even for experienced developers. But since I’m talking about TDD specifically for sole developers and fairly small projects, then TDD is simply much less effective in my experience. A more informal process works just as well.
TDD benefits are generally overrated
There are benefits and drawbacks to TDD. Most remain inconclusive and subjective, only few have been measured in some very narrow-focused case studies (here and here). Continue reading »
Here’s a crazy thought: with commercial game kits (game source code products) being popular and financially rewarding – why not crowd-fund an iOS game by selling it’s source code, resources and development insights while you’re creating it?
Marcus and I will give this idea a spin. Marcus is a game designer I worked with at Electronic Arts Phenomic for 6 years. I’m sure you know me. Together we’re going to create a tilemap-based physics game using cocos2d and KoboldScript (Lua scripting for cocos2d). And we are going to sell everything we’ll create practically from day one.
If that sounds even slightly intruiging to you, we’d love to get your feedback!
Visit the launch page and take our survey which has already helped us tremendously to focus on what’s important for you. For example I’ve converted the entire KoboldScript library to use ARC seeing how important ARC is to you.
But do keep on reading for more details … Continue reading »
A couple months ago I wrote a tutorial explaining how to upgrade Cocos2D in an existing project.
I was able to cut the description down to only five concrete steps, but there’s still a lot of text to follow and caveats to consider. I designed Kobold2D exactly to make it easy to solve the issue of upgrading projects to newer versions of the game engine.
