Good products, happy teams

I was transferring some data in chunks this evening via Internet, using SSHFS. Seeing as how the various folders ranged from several hundread megabytes to several gigabytes, I constanly had to <Alt-Tab> to the Terminal window to check if the transfer completed. Needless to say, I was annoyed. After a little bit of searching, I came up with a cute solution: command chaining.

Unix lets you run multiple commands in sequence if you separate them using a ";", like so

$ command1; command2

If only I could find a command who would send a message to my Gnome environment, I'd be all set. After a bit of searching I found libnotify, which is the perfect solution. You need the libnotify-bin package for it (install it using apt-get).

So now I get a very nice, simple notification when the copy process is finished.

$ cp srcdir destdir; notify-send done

I'm a big fan of Vim's editing capabilities. I'm also a big fan of Eclipse's refactoring support. So when I found a way to have Vim editing inside Eclipse, I just had to share. There are several alternatives, but the one I'm currently finding satisfactory is an Eclipse plugin called Vrapper.

Steps to installing it:

1. Go to Help > Install new software...
2. Under Work with, add http://vrapper.sourceforge.net/update-site/stable
3. Install Vrapper
4. Restart Eclipse
5. At this point, you should have a small Vim icon in the main toolbar. Click it to enable Vim-like editing.

For the full set of features, see http://vrapper.sourceforge.net/documentation/.

So many people referenced this book in various tweets, blog posts and presentations that I could not avoid it anymore. And I'm glad I didn't.

The Goal is not your typical business book -- dry and filled with definitions and lots of abstractions. Instead, it cleverly uses a novel format, depicting a few weeks in the life of Alex Rogo, a plant manager facing termination of his establishment due to poor results. Under the mentorship of Jonah, a physics teacher, Rogo discovers a five-step process for improvement (called TOC - the theory of constraints), that ultimately not only saves his plant, but also promotes him to division manager.

In a nutshell, the process for augmenting a system's throughput would be this: identify the current constraint, change the process to elevate it, repeat. As simple as it seems at first glance, TOC has profound implications if you start applying it at every level of the company: strategy, product portfolio, product, project, team, individual.

While reading it, I realized that the very concept of the retrospectives might have some of its roots in the TOC: what are our current problems? -- fix them -- repeat.

I encourage everyone to read the book. It will give you another set of tools and techniques for attacking problems and implementing change.

This evening I read an essay called Tact Filters (via J.B. Rainsberger) that divides people, in a slightly simplified view of the world, into nerds and normal people. The difference being that while "normal" people tend to filter outgoing communication for potentially upsetting messages, but not the incoming one, nerds do it the opposite way -- they censor incoming communication, but not outgoing. This would explain why us nerds are very blunt when stating ideas, but tend not to care much when being criticized, while the rest of the world would easily get offended by criticism, but at the same time refrain from inflicting it on someone else.

While I do agree that to an extent the dichotomy has some substance, since most developers I know are more direct and egotistical than people in other industries, I recently came to the conclusion that "telling it like it is" is detrimental to having a constructive discussion.

At my current employer, we changed team structure recently, so a lot of adjustments have to be made until we will gel together as a team. As Scrum Master, I consider one of my main responsibilities to be getting the team to respect the Scrum and XP rules during our first sprints, so that we would share a common process to improve later, as a result of our analysis.

I am constantly trying to determine if we are not respecting best practices (pair programming, refactoring, unit testing, frequent commits, limiting work in progress, developing the most important stories first etc.) and remind people that they should change in order to "get back on track".

Needless to say, my constantly being a pain in the rear has led to numerous arguments while I was trying to make a point. Returning to the tact filters, analyzing my behavior in light of its terms (input vs. output filter), I realized that change was easier for everyone to accept if proposed in a tactful manner, that is when my output filter was on. 

Of course, information is more easily provided without trying to camouflage it in a non-controversial format, but I found that a lot of minds shut down when you start a conversation with "You are doing X wrong, because it leads to Y". Our minds simply freeze and we enter a defensive mode that prevents us from discussing the idea, but instead we try to justify our ways. The least resistance comes when discussions start in a conversational format, such as "How do you think Y will be affected by doing X?", which lead to idea swapping.

Especially in our industry, where a lot of practices are based on small-scale observation or educated guessing, trying to nudge the team in a certain direction requires a lot of diplomacy and attention so that dialogues do not end up as monologues, and eventually as a complete waste of time.

To be effective communicators, we should "switch on" both our input and output filters.

I've been slacking off lately and haven't published any more links in quite a while, but the Internets keep pushing too much good content forward for me not to take stance.

• Should you estimate bugs using story points? InfoQ and Ron Jeffries give some advice.
• Kakanomics: Why we sometimes declare to seek quality, but tacitly accept (and expect) crap.
• (RO only) Ctrl-D, a joint launched by three tech companies in Timisoara
• Rails 3.1 will replace Prototype with jQuery says @dhh. About time it did.
• TDGochi is a cute virtual pet/Eclipse plugin that thrives if you practice proper TDD.
• Hudson, the popular Continuous Integration tool, was renamed to Jenkins earlier this year
• How much unit testing coverage should you strive for? Pick your favorite from three answers.

The narratives reminded me of the style used in The five dysfunctions of a team: the authors use a fictional story to give context, then provide distilled checklists that you could easily print and review periodically. During a seven week period, we get to witness Sam, a newly appointed manager, employ his management skills to build a strong, effective team.

The topics covered include holding meetings (both group meetings and one-on-ones), planning the project portfolio, delegating, coaching or giving feedback. I particularly enjoyed the parts about coaching and project portfolio planning.

Overall, a very good book for learning some management basics, but I am sure even seasoned team leaders will find valuable advice while reading it.

• Watch videos from this year's Annual Google Test Automation Conference
• The Project Management Institute (you know, the one with the PMP certification) now offers an Agile certification. I'm waiting for Uncle Bob Martin to come up with a Waterfall Certification next.
• I'm not sure I liked the question of this post: Should Younger Developers be Paid More?
• Need to debug some Ruby code? rbtrace - like strace, but for ruby
• Learn how to improve the quality of your thought process using sketching, a "visual thinking power tool"

We are totally overloaded with information. So we have two choices: remain largely ignorant of news or spend endless hours trying to catch up with HTML5, CSS3, Node.js, Ubuntu releases, Ruby/PHP/..., their respective frameworks, testing tools and so on.

That's why I appreciate efforts such as that by Gojko Adzic to distill information and provide a selection of relevant links. 

Starting this week, I plan on doing the same: share with you the pieces of information and links I found most valuable. So, without further ado, here goes:

• JDK 7 is Feature Complete - It does not bring anything exciting however
• Stop using Comic Sans, for crying out loud. Don't be a Comic Sans Criminal.
• Get an eloquent intro to Javascript. Good enough even for intermediate programmers.
• [Video] Curious about the fuss around functional languages? Let Rebecca Parsons give you an overview.
• Think you can trade between quality and new features? Think again, argues Marin Fowler. The actual trade-off is between new features today versus speed tomorrow. Sustainable pace, anyone?
• [Video] You've heard about SOLID principles, haven't you? Now meet their counterpart: the HORIDD principles for design.
• Tired of spending endless nights at the office? Learn to delegate.

The first half is a generic introduction for beginners, dealing with the building blocks: what is unit testing, what are stubs and mocks (Mocks aren't stubs, remember?) and how to use isolation (mocking) frameworks.

The second half is addressed to more experienced programmers, touching on higher-level concerns: organizing tests, writing maintainable tests, integrating unit tests into the organization and testing legacy code.

What I liked about the book: the gradual introduction of concepts and the way the author puts everything into perspective, not claiming that unit testing is a silver bullet, but instead pointing to places/projects it is not best suited for. Also, the state testing vs. interaction testing dichotomy felt more intuitive than the state testing vs. behavior testing I had learned from xUnit test patterns.

What I disliked about it: the chapter on testing legacy code felt a little forced in the context of the book. Also, as an avid reader of Addison-Wesley books, I felt that graphical appearance proposed by Manning could use more attention.

All in all, a good book on the topic, which I will use as a primary recommendation for anyone starting to write unit tests.

For anyone familiar with agile and lean methodologies, advice such as Throw less at the problem or Go to sleep will sound familiar. However, unlike their previous work, Getting Real, Rework also has a lot of business and productivity-related advice (Build an audience, Let your customers outgrow you).

Their experience is presented in almost 100 two-page essays. Though the general point of view is clear, sometimes I felt the need for more substance than what could be covered in such limited space.

All in all a good, quick read that can serve as a checklist for small companies trying to keep it real, but also for bigger companies trying to lose mass and streamline their operations.