| Reflection |
[31 Mar 2009|12:15pm] |
|
Well we demoed the bug fixes to drop 1 and the first half of drop 2 to the client end of last week. Getting to that point has meant the last two months have all been long days, so this weeks feels like a bit of a lull in comparison. Hence I thought it time to put down my thoughts and reflections. I was last writing about NUnit so let's start there...
NUnits are good, when you're working in a 15 developer strong team you need to keep an eye on any "treading on toes"; will a change in one corner of the model affect a different corner; will a change to the model affect the business layer in a corner you're not expecting; likewise with the UI. Unit testing is very helpful here - run all the tests to make sure not only your bit goes green but the rest all stays green - but it is not a panacea.
Where unit testing can trip you up is on integration. This is not surprising really because unit testing it about testing the units, and that where "continuous integration" tools can help; more on them in another post. However, seeing all that unit test green can give you a false sense of "it working". Especially if you're in management :-) And yet just because all the little bits work doesn't mean it'll all work when you put it together*. I can attest to that having spent most of a week getting the front end to talk all the way through to the back end ... and back again. Serialisation issues, checksum issues**, impedance mis-match issues***, model mapping issues**** all came into play.
Of course that time was time well spent: getting one operation / action working all the way through, taking out the "TODOs:" and other bits of workaround code unless they were for some other action, is important stuff. Once you've proved it really really works end-to-end you can be much more confident that the other actions, with their green unit tests, will work end-to-end too.
So as a "word to the wise" remember to put time aside for integration on the project plan; try to see the unit test green as the first step to "it's working". A phrase from my days learning maths at school springs to mind: "necessary but not sufficient".
There is still "devil in the detail" though: because you are the first route through, you don't know what obstacles you'll come across and how long it will take to overcome them hence estimating integration time really is just an estimate. It's why we found estimating drop1 a lot more difficult than estimating drop2. It why I'd recommend in the early stages keeping that part of the plan as flexible as possible; in the early integration stages I worked best when I didn't have a to estimate how long it would take rather I just had to get it done.
* Of course it's much more likely that if the bits work then the whole will work and it is most improbable that if the bits don't work then, through some miraculous cancelling out - the whole will work :-)
** Our project is a finance project so we need to be 100% sure that it is robust, hence we checksum the model as it moves in and out of the business layer to make sure the UI layer or transport hasn't changed the model in any way. Hence the only layer than can change the model is the business layer, hence we can put all our effort in making that layer robust.
*** One layer may represent a list as an array but in another layer the framework might only accept a comma separated string.
**** Turned out not every corner of our model was mapped correctly in our ORM, though this might really have been caught if we'd had time to write even more unit tests.
|
|