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 »
I frequently see questions like Should I use game engine A or game engine B? Sometimes the question is slightly more specific like Is game engine A right for this game?
These questions are not unlike giving a list of features or requirements and then asking Is potential partner A better for me than potential partner B? And some are closer to asking the general public a very subjective question that requires intimate knowledge about the person who is asking: With whom will I have better sex, A or B?
Well … while there’s a checklist of features that A and B may or may not have that might have some influence on the decision, more often than not your choice depends a whole lot more on whether it just feels right.
You may feel attracted to A because A is so reasonable and the support is responsive and helpful, or you may simply find yourself attracted to how B is open to everything and free of charge. You may also find that despite A or B lacking a specific feature you crave, other aspects that you didn’t even think of more than make up for it. Features aren’t everything, more important is the spirit and ease of use.
Not uncommonly a fully featured game engine (or partner) with all bells and whistles may turn out to have a really steep learning curve, many restrictions, limitations, policies, quirks while “free” may cost you a lot more than you bargained for.
Following is my game engine dating advice that you can take to places like MobileGameEngines.com to make your pick. These are the things that I consider the most important when choosing a game engine for small projects, and that is irregardless of the type of game I might want to develop.
