Development mottos to keep the team spirit alive

Today we were talking over some things as we start up the next sprint (sprint #4, 1 maybe 2 to go!). The conversation turned towards the fact that one guy on the team was away on holiday but he was the "report guy" and currently one report was causing problems. Unfortunately we've run astruck of the code ownership problem that I really wanted to avoid, namely being dependent on one resource for one slice of the application. Not a good place to be in and something you want to avoid. As we were chatting this set of syllables came streaming out of my mouth:

"If all you do is what you know, you'll never grow."

Plain, simple, and short. Now maybe I heard this somewhere before but after saying it, it made me think (and laugh) and we all had a good chuckle over it. However it really does ring true. Sure everyone has individual skills and some people are better at database programming vs. UI design vs. domain modeling, but in the end a well-oiled team needs to be able to respond to any problem. In any module. In any area of the code. While you might be great at writing the same thing over and over again, it isn't challenging let alone pushing any kind of thought-provoking edge so how do you expect to move with the times?

We wrote the quote on the whiteboard and it resonated. It's one of the mantras we're adopting to always remember not to paint ourselves into a corner and be dependent on any one resource and to tread into those uncharted areas of the your capacity. So get out a little bit, explore your code and if you've never written a view using MVP, now's as good as time as any to learn.

Later in the conversation we came up with another one (we thought we were on a roll). It started with the U.S. Army's "Be all that you can be" motto and became this:

"Test all that you can test."

Yeah, a little corny but then my co-worker Dale came up with this widget:

"If you don't write tests... you're dead."

It was getting later in the day and things started to go downhill but walk with me on this one. We laughed at it but then combined the two statements:

"Test all that you can test and if you don't write tests you're dead."

While it may sound a little chilling and morbid for a software development project, after we wrote it on the whiteboard it just clicked. The team was dead in the water if we don't write tests. We're currently facing new functionality and dealing with some bugs coming up and doing lots of fairly aggressive refactoring. You can't successfully refactor parts of your codebase if you don't know what it does or what the downstream impact is, so when you come upon muddy waters where there's no tests our mantra is to write one then move on. While we do have about 70 good tests (after 3 months of development) we could have more and we've been procrastinating to write more tests (especially for the presenters) for a long time. Pressures from the users, not enough time, blah, blah, blah, blah, blah. So with this little motto and some team re-enforcement of asking everyone at the Scrum when they mark something as "Done" we'll ask if they have tests for it. If not, we're not going to consider it done. Hopefully that'll get us back on track and be productive at the same time.

Finally, later today we had a technical overview and discussion of a new Smart Client project I'm leading up. It was the usual wallow through all the tools, techniques, technologies, process, and standards that we're going to do (with a load of the usual acronyms [CAB, SCSF, TDD, DDD, BDD, FIT, etc.] all thrown up on the whiteboard for discussion). About halfway through as we were talking about testing and specialization of code, I threw the two statements up on the whiteboard again. 

"If all you do is what you know, you'll never grow."

"Test all that you can test and if you don't write tests you're dead."

A completely different team with varying levels of experience on the various tools and processes, yet everyone agreed with what we had written. Yup, that's what we have to do for this project to be successful (well that plus deliver a quality solution to the customer).

Anyways, just something to think about. Even if something sounds corny it's a morale builder and an item to talk about. Remember to keep these little team building exercises fun and light and hey, who knows, you might come up with a little motto for your team to keep things interesting!

3 Comments

  • If you wait for the pressures from users to go away to write tests, you'll never get them done! Whichever way you do it, I found the best practice is to integrate test writing right into the coding of features themselves. Then it doesn't become a separate task that can continually can be delayed but it becomes part of the 'normal' development process.

    I personally prefer TDD as it saves you signficant time in the shortrun and exponential in the longrun. Also it's easier to write tests that you build code around rather than vice versa. However there are other possiblities such as writing the test after the feature is already developed but before you mark it as 'complete'. TDD is certainly not for everyone.

  • written on the whiteboard behind me is: 'success is thru discipline', 'productivity thru panic' and 'happiness thru penetration' !!

  • As I sit here uninstalling VS2005, I am reminded of my favorite quote from years ago ... "Good Judgment is the result of Experience; Experience is the result of Bad Judgment."

Comments have been disabled for this content.