Not to long ago one of my developers came across a little mockup tool called Balsamiq and then I saw a post from Clark Ching who checked it out as well. I love the sketchy look and feel and rendering a quick mockup form was good fun. We’ll probably try it out on a future project and see if we can get some value out of it. Much like the Swing Napkin look and feel the value is from being obvious that this is not to focus on look and feel, but more on the functionality of a web site.

Denis over at One Brike At a Time recently expressed frustration at having to use low trust practices:

It used to be that I did not care much for defensive programming outside of a system’s boundaries. It used to be that I did not really care or believed in strict source control (as in authorise only some people to touch a particular file). It used to be that I did not really believe in code reviews.

I now care for these and it is not a good thing. I care about these things because I do not trust the developers I work with to do the right thing, whether it is making the code better, improving their style, teaching me new things, or even write decent unit tests.

The frustrations are real. Teams are often at many different levels of skill and experience. Even minimal unit testing is not a common practice in many shops. You can still find developers who look surprised when you ask where their code is checked in.

Lower trust practices can be a bridge:

• Source control is a given. Developers who check in bad code you might force you to lock things down for now. Continuous integration is a way to grow out of this. If all of your projects are being built with any change, you can quickly discover if someone’s injected some issues. This might mean setting up notifications for even successful builds for non-active projects.
• Code reviews don’t have to be a negative. I’ve used them and still use them more for mentoring than as an audit of bad code. Code reviews are easy to get wrong, but used safely they can improve the code base and improve your coders through sharing. And I always leave the easy out–no code reviews if you’re pair programming. *

After about 45 minutes of frustration trying to work through some maven exercises in the Sonatype book I kept arriving at the following message:

I had the sample code downloaded and got the same error, so I investigated possibly not having access to the maven repositories. I’m on my in-laws network, possibly there’s something being blocked. I tried other mirrors without any success. Finally I just deleted the local maven repository and re-ran

and everything just worked. I had forgotten how finicky the local repository can be.

It’s 3:30 on a Friday afternoon and you just got the test passing for a nasty intermittent bug after spending most of the day on it. Now you can jump back into the main code base and add that new feature. Only, that would be a bad idea.

The Friday Rule:

Try to leave every Friday with a success.

You want to head into the weekend with a win. That win can be small, but carrying frustration into the weekend means you’re less effective next Monday. You walked away frustrated and probably thought about it over the weekend. Weekends are a critical for recharging batteries, spending time on hobbies, and hanging out with friends and families. They are not a good time to mull over bits of bad code or a misconfigured server. Walk out with a win.

There are some implications worth noting:

• Say you fix the critical bug at 2:00PM on Friday. Switch your energies to something lighter like clearing your inbox, filling out release notes, updating the wiki, or completing a mandatory online training class.
• If you’ve had a really long week already now is probably a good time to head home.
• From a coding perspective leaving a good breaking point is to write one last test that fails. Then you can easily pick up where you left off.
• As a manager when a developer swings by to explain how they finally got something working and you see it’s already well into Friday afternoon encourage them to take the victory with them over the weekend and not continue to code away.
• This can apply as a daily rule, but it’s more critical on Friday where you can affect your mood for the whole weekend.

I’m working on a justification for capable developer machines including dual 24″ monitors. It occurred to me that I needed a simple test to define the problem.

def test_two_24_inch_monitors_are_cost_effective
  baseline_productivity = developer.productivity_in_hours_per_year
  developer.add_monitor(24_inch_monitor)
  developer.add_monitor(24_inch_monitor)
  productivity_gain = developer.productivity_in_hours_per_year - baseline_productivity
  assert(productivity_gain * 50_dollars_per_hour > cost_of_two_monitors)
end

So with two 24″ monitors running say $800 I need to show just a 16+ hour increase to justify the increased productivity in a single year. To make the math easy with say 1600 hours available a year, we’re talking about just a 1% productivity gain. Given a recent study showing 20%+ gains this should be an easy test to turn green.