Having problems with message search?
They poked fun at us for a bit, then after we finished and nothing bad appeared on the radar besides a couple of misinterpretations of the data, they decided that TDD and paired-programming was a good thing to be doing. For those that didn't realize it was only temporary, they started asking where my partner was. heh.
I tried convincing them that they could be my next partner, but no one else was willing to do paired programming; too different from what they're used to, they stated.
Too bad for them. :(
At least I was able to convince the management to get the rest of the team some TDD training with that example. It remains to be seen whether or not they are going to stick with using it.
-Chris
On Sun, May 10, 2009 at 12:55 PM, Jonas Andersson <jonananas@...> wrote:
Once on a No Fluff Just Stuff-seminar Venkat told a story about how he started out doing code review by just deciding with a collegue that they would team up doing it together. People around them were teasing them about doing code review until the first release, when the measured number of bugs per programmer clearly showed the benefits of code review.
Maybe you could try the something similar with you're ideas. Let's hope "your" people is smart enough to care :)
-- Jonas2009/5/8 Raoul Duke <raould@...>
> This was definitely not a silverbullit reply. Still thought I'd give youthank you for taking the time to share the perspective. it is
> some feedback :)
definitely helpful, and is sparking some thoughts for me. i'm starting
with the negatives since (a) i'm a pessimist and (b) i'd have to start
there to then be able to dream up possible solutions.
1) the role i'm talking about (just to get specific here; i'm not
saying this generalizes) would be inheriting code from people who both
decided the goals and wrote the code. i think that sorta reduces the
power of one possible leverage point: get the customer involved in
making e.g. Fitness tests so that the developers start to get into the
gestalt of things like testing, and further, continuous integration,
and thus hopefully refactoring, and thus hopefully ever more
appropriate testing.
2) the other issue is that projects are in theory changing every few
months, and so there is no guarantee of working consistently with the
same upstream people. which reduces the chance of me trying to "manage
up" some nurturing of software engineering. on the other hand, maybe
it means one group will turn out to be very receptive, and then that
will help influence other folks.
potentially interesting times...
:)
i guess i figure that the root issue is to be able to bring people
around to seeing that code quality matters, and then what is involved
in that, and that there are dividends for them if they invest in it.
which is not a new statement or insight. trying to figure out how to
map that down to specific situations is a curious exercise.
sincerely.
Offline 
Send Email