multi-touch-dev team mailing list archive

[Duncan McGreggor <duncan.mcgreggor@xxxxxxxxxxxxx>]

Hey folks,

I wanted to bring this by everyone's radar, as I'll be talking more 
about it after Beta Freeze. There are a few crucial things I want to 
emphasize when it comes to our development process:

 * we need to use the test-driven development strategy (no matter the 
initial pain)
 * we have to release our software early (regardless if you think it's 
crap)
 * it is of the utmost importance that we embrace the peer-review process

I cover these in more detail below. Please read; I will, no joke, be 
quizzing everyone about this :-)



TDD:

This can be a real pain to get used to, so I'll be helping you guys out 
on this one. The peer-review process will also reinforce TDD. For 
starters, whenever you find a bug, add a unit test that demonstrates the 
failure. The test suite should should run and fail with the new test. 
Add your fix, the test suite should then pass.

After that, we need to get everyone in the habit of starting with unit 
tests as a natural part of problem solving and exploring possible 
solution spaces. We do this anyway in our heads. We need to literally 
codify that process. You'll thank me later.

Finally, we will get to the point were every code path has a unit test, 
and we'll hit 100% test coverage :-)



Release Early/Often:

One of the biggest hang-ups that developers have to get over once they 
start working on team projects (when they've been used to developing on 
their own, or on focused tasks) is the feeling of incompleteness and 
vulnerability when it comes to making software publicly visible. I need 
to get some therapy on this one right away :-) This slows *everyone* 
down. I you think that by working a few more days in isolation, you can 
make it *just right* and *then* it's safe to release, you're wrong! Very 
often what happens is all that work goes to waste, because a fellow 
engineer comes along and says, "Oh, but what about this?" resulting in 
the need to refactor all that work.

We cannot afford that. We need to make sure those conversations happen 
right away. Trust me, there will still be plenty for you to do. And 
since everyone is so busy, you'll still get to do it. Ultimately, this 
will save more time and tears; everyone benefits :-)



Peer Review:

Finally, peer review. The ego-buster. The early-bug-finder. The 
well-oiled machine. This is where we're heading, and the sooner we get 
there, the better Multi-touch will be in Ubuntu (and anywhere else 
uTouch is used).

Now that we're moving out of panic-driven development into test-driven 
development, we need to make sure that we start doing the following, 
starting in Natty at the latest:
 * examining the project goals for a cycle as a whole
 * determining a good initial guess at task break-downs for each 
feature, creating new tasks as features are better understood
 * filing tickets/bugs for each task
 * creating a branch for each task and linking it to the ticket
 * working in those branches, asking questions of our team members and 
the community while doing so
 * submitting branches for review ("merge proposal" in Launchpad 
terminology)
 * looking at each others' code, providing review feedback, running the 
test suite against the code, checking for the addition of unit tests for 
new/changed code
 * merging branches to trunk, only after a final approval

Starting now, this needs to become your Developer's Guide to the Galaxy 
:-) I know that parts of the code base are in strong flux right now, and 
will be until Beta Freeze. Until then, keep these thoughts in mind, 
'cause in two weeks, this is what we all need to be doing.

We want small, light teams. Small, light tasks and branches. Heavy-duty 
awesomeness. Following this as a guide, we can accomplish just that.



Thanks for reading :-)

d