The other weekend we weeded our garden at home.
It was a funny old thing, one of us would start on an area that was covered in weeds, pull them out on mass and then eventually move on to another area (either believing we had done a good job and finished the area, or because we got bored, or because we saw the greener weeds over the fence.
A second member of the family would come along to the freshly weeded area, and of course see some weeds remaining. They would make a derogatory remark on the quality of the previous weeders work and remove the weeds they could see, then move on to greener pastures.
Rinse and repeat until all the family members had been through that area, and whoa and behold it was pretty weed free.
Sound like any development teams you have worked with before?
Its a common behaviour for somebody to come along and pick up another dev’s code. Regardless on how well it was written, documented, tested etc, they will always find something they don’t like and change it.
And thats a good thing, if they are making it better (focussing on the weeds left, and not introducing new weeds in the process!)
But often we discourage this behaviour, or we react by chastising the original dev etc. And this is when bad behaviour starts to appear in reaction to this.
In the world of Agile and Test Driven Development (TDD) the aim is to start small and make the code work quickly, then identify additional test cases and amend the code to pass them. At the end when its all working and passing the test cases, you refactor the code to run faster, look prettier etc. Again ensuring it still passes the test cases.
And then in subsequent sprints somebody else might extend the code to add more features etc.
All kinda sounds like my weekend of weeding really.
Many hands and continuous improvement is a good thing. Just a pity weeds seem to grow back not so long after ….
Recent Comments