Code Retreat in Wroclaw

Next weekend there’s a Code Retreat in Wroclaw: http://coderetreat.wroclaw.pl. I’ll be there so If you want to cut some code together retreat with us =)

The book is out!

Toni, Felix and the gang invited me to contribute to the brand new book. The Practices of the Proper Christian Programmer will be available on Amazon shortly!

excuses for not doing dev testing

Yesterday I heart loads of excuses why the tests have not been written. I immedietaly remembered Misko Hevery‘s session at amazing geecon conference (be sure to attend next year!). Misko told a story about influencing developers to write more tests, testable code and TDD. I liked his slide where he collected all the excuses he heart from devs explaining why they haven’t written tests. Basically, Misko’s conclusion was that the only valid reason of not writing tests/TDD was lack of skill. TDD or ability to write tests is a skill like any other and it is no shame if you haven’t acquired it yet!

However, some of the excuses I heart yesterday were beyond any common sense:

• this is not really worth testing
• this is a small application
• we don’t have time
• (my favorite one) tests would make it harder to refactor

That was all bullshit and the only reason the tests were not written was that it was hard to write them. Devs didn’t know how to write tests for the DAO layer (how to ensure db is in correct state, how to maintain test database, etc.). Devs didn’t know how to write integration tests because of lack of experience with tools like Selenium. So they didn’t write any tests, not even plain jUnits.

Half a year ago, the same development team wrote loads of tests achieving high quality code base & high test coverage. Those days they wrote a django application. Django is a modern framework with built-in means of testing. It significantly contributed to the fact that developers wrote tests without cheating themselves with it’s-not-worth-testing kind of excuses (complete list above).

The interesting thing about the situation I encounter yesterday was this: junior developer wanted to write tests for some DAO code that did not have any tests (actually, there were zero tests at all…). So I asked senior developer responsible for architecture to help out setting up a TestCase that can prepare connection to test database, etc. Instead of helping, the senior guy started his mantra of excuses trying to convince junior developer not to write tests. Fortunately, I was there…

coacheating

A bit about coaching, a bit about cheating this time.

A colleague asks me for help with some random problem about random technology.

I might say: “push here, run that, do this…”

Or I’d say: “I don’t know. What do you think? Hang on… I bet this tool should allow doing something like that. Let’s pair on this for a moment…”

A geek like me tend to enjoy showing off with how much he knows. Sometimes it’s really hard to shut up and pretend I don’t know. There is a reward, though. It’s when we finally work out the solution together and I feel we both made a little step ahead to be better software engineers.

One wants to get things done. One aims for fabulous architecture. Many times I seem to have quite different agenda. I’d rather make someone learn stuff. So I might say “I don’t know” even if it means things are not done as quickly or the design ends up imperfect. Is it clever or just… unethical?

Whoa, deep blogging. I bet it’s this Christmas time inspiration. This blog post is sponsored by Mariah C. (All I want for Christmas is… closure in java?).

talk indicator

I did an interesting experiment quite a long time so I I drafted a blog entry about it. Today I’m finishing this draft off.

The experiment was to visualize how much certain individuals speak. Why? Well, I felt that some team members didn’t speak up because they were not loud enough or there was no room for their opinions. Worth mentioning is that the subject really concerned the entire team. Half-way through the meeting the visualization on the white board became quite interesting. Red bars indicated how much one spoke:

Note that some guys didn’t speak at all yet! The interesting thing about the loud guys is that they are truly smart, experienced and creative. And yet the team would benefit more if they just shut up… It’s so easy for the silent guys to listen less and less, stop caring too much and finally disconnect. Fortunately, it didn’t go that badly and here is what we ended up with:

The loud guys didn’t talk too much after they saw how they monopolized the ether. Hopefully, the drawing on the white board let everyone speak up.

I wanted the “talk indicator” to help involving all the team members in an important meeting about our short-distance plans. Hopefully, it helped teaching some guys how to listen :)

I guess the experiment may have triggered a positive change. After all, we never needed to do it again…