Test Oriented Programming
I know, somebody has thought of it before, but I don't particularly care. *I* thought of it today, and thats whats important.
Basics are really simple. Everybody Works In Pairs.
Yeah, yeah. XP did that. But XP slaps two people with *one* keyboard in front of *one* computer doing *one* thing.
Me, I do it differently. One person writes whatever the heck he/she is writing, and the other writes the test harnesses. There Must Always Be Two.
See, except for the real deep architectural stuff, virtually everything I write - modules, apis, accessors, database futzers, whatever - tends to consist of small chunklets. I almost *always* proceed to then unit-tests these like mad (maybe. ok, probably not), then writes some more, then realize that I only tested the stuff that I thought of, and not the stuff that *you* thought of but which turns out to be terribly important, and so on and so forth.
In fact, when I really get down to it, around 50% of my writing literally consists of me writing little harnesses to validate what I'm *going* to write, then writing my code against said harnesses. Which is nice, but it
Lets also pretend that it is *my* baby, and I'm the only one that can do this in the style, manner, and gravitas that it deserves.
I just blew half my time doing *other* stuff!
Factor in general inefficiencies in the process, and you may as well use two people, because, face it, someone else writing Test Harnesses is pretty much guaranteed to expose the weakness of your style, manner, and gravitas....
TOP - Test Oriented Programming.
You heard it here first (unless you heard about it somewhere else first)
Note: How is this not Test Driven Development? Well, it is, kinda, 'cept that the key point here is that it is not you writing the tests.
Update: I've pretty much junked any/all variations on Test Driven Development. It turns out that, like anything else, you end up having people learn how to get really, really good at writing tests, but the actual work still never gets done.
Sigh.
My latest approach is to just get heavily functional about everthing (erlang! w00t!), and minimize the amount of testing that is even necessary - if you decompose the f**k out of everything, the tests become, kinda, sorta, redundant...
Basics are really simple. Everybody Works In Pairs.
Yeah, yeah. XP did that. But XP slaps two people with *one* keyboard in front of *one* computer doing *one* thing.
Me, I do it differently. One person writes whatever the heck he/she is writing, and the other writes the test harnesses. There Must Always Be Two.
See, except for the real deep architectural stuff, virtually everything I write - modules, apis, accessors, database futzers, whatever - tends to consist of small chunklets. I almost *always* proceed to then unit-tests these like mad (maybe. ok, probably not), then writes some more, then realize that I only tested the stuff that I thought of, and not the stuff that *you* thought of but which turns out to be terribly important, and so on and so forth.
In fact, when I really get down to it, around 50% of my writing literally consists of me writing little harnesses to validate what I'm *going* to write, then writing my code against said harnesses. Which is nice, but it
- causes target fixation. I know what I'm testing so of course (well, usually) its going to pass.
- automagically means that i am spending 50% of my time not writing the *real* stuff.
Lets also pretend that it is *my* baby, and I'm the only one that can do this in the style, manner, and gravitas that it deserves.
I just blew half my time doing *other* stuff!
Factor in general inefficiencies in the process, and you may as well use two people, because, face it, someone else writing Test Harnesses is pretty much guaranteed to expose the weakness of your style, manner, and gravitas....
TOP - Test Oriented Programming.
You heard it here first (unless you heard about it somewhere else first)
Note: How is this not Test Driven Development? Well, it is, kinda, 'cept that the key point here is that it is not you writing the tests.
Update: I've pretty much junked any/all variations on Test Driven Development. It turns out that, like anything else, you end up having people learn how to get really, really good at writing tests, but the actual work still never gets done.
Sigh.
My latest approach is to just get heavily functional about everthing (erlang! w00t!), and minimize the amount of testing that is even necessary - if you decompose the f**k out of everything, the tests become, kinda, sorta, redundant...
Comments