Turns out for me Wednesdays are a good day for one-on-ones. Until recently I had been running weekly one-on-ones with my ten or so direct reports across Wednesday and Thursday afternoons.

One-on-ones have really improved my relationship with my employees and vice versa. Problems are detected and corrected sooner, even really quiet team members get and give feedback at least once a week, and there’s a regular opportunity for coaching.

To be effective you need to fiercely defend your times for one-on-ones. During the meetings even the ringing phone goes unanswered. I don’t even glance at it to see who’s calling. If it’s the CIO with a fire to fight they’ll come down and pull me out of my office.

Two afternoons in the middle of the week turn out to be a tempting target for almost any other manager to schedule competing meetings. There’s an assumption I can re-schedule my one-on-ones since they’re only 30 minute meetings with employees. After 18 months of fighting this reality and having to re-arrange at least two meetings a week because of my schedule, I got a better idea.

Why not just schedule all my one-on-ones for a single day? The idea was appealing on several fronts:

• It’s easier to defend a single day on your schedule rather than defending two afternoons.
• It frees up larger strategic chunks of time on the other 4 days of the week.
• Some of my staff start fairly early in the morning so scheduling a one-on-one at 8:00 AM is feasible.

Barely into implementation now I’m realizing unanticipated benefits:

• I do a better job prepping for one-on-ones. You only need to prep for about 2-3 minutes per employee to jot down things you want to cover, but when the sessions were in the afternoon I often tried to do that during lunch. Now I pull down my one-on-one folders and start prepping first thing Wednesday morning.
• I get a better sense of where my whole team is. By compressing all the one-on-ones I get an insight into what the general mood of the team is especially about business issues that impact the company as a whole and how they’re handling them.
• My follow-up on action items is better. Fairly regularly some action item comes out of a one-on-one. Unfortunately when I mixed and matched one-on-ones with regular meetings I’d be dashing around and often I wouldn’t get around to looking at the notes and trying to do follow-up until Friday. Now I’m getting to those follow-up items on Wednesday or early Thursday morning. Faster feedback loops.
• Selfishly, I get a sense of accomplishment. Going home at the end of the day having heard and talked to all of your employees gets me a little bit of a charge as a manager.

My results may differ in a few months but so far I’ve been able to defend my Wednesdays and achieve a better outcome for my one-on-ones.

I shuddered reading this post:

After months of using Eclipse, of being forced to use Eclipse, I decided I just can’t continue down this path any longer. Like a burglar in the dead of night, or a drug smuggler on the border, I committed a most sinful and most treacherous act — I installed IntelliJ IDEA to continue with day to day Java development. In the context of the company I work for, this is tantamount to lying on your resume or sexual harassment. It’s big.

IDE choice shouldn’t be grounds for a disciplinary action. An IDE is just a tool, and for pretty much any java project you can use:

• Eclipse
• Netbeans
• IntelliJ IDEA
• JDeveloper

Forced standardization might make sense when you say make a decision to use Oracle over SQL Server for the database, but for an IDE you can use any of the above tools with no real additional costs. IntelliJ IDEA does have a nominal $250-$500 cost, but I find that not to be much of a barrier. Some developers including myself regularly switch between IDEs to take advantage of different features or plugins. I spend most of my time in IDEA, but occasionally I drop into IBM’s Eclipse based RAD. Other developers might jump from Eclipse to Netbeans to do some profiling.

One of the fatal issues that leads to things like forced IDE standardization is when you don’t have a fully automated build. If you can’t run ant, maven, or even rake from the command line, no IDE, you’re dead. This tends to lead to developers who can only build from within the IDE. Next comes ‘works on my machine’ problems. Then to further reinforce the bad decision to become completely reliant on an IDE you force all developers to use it all the time.

Automated builds avoid IDE lock-in.

Then there’s the shops that believe everything must be standardized. Avoid these standardization-happy shops.

Jef Raskin suggests comments are more important that code (via a link from Raganwald). Like test first design, you should try out comment first design:

A competent programmer who has learned the documentation-first style will sometimes think of a solution in terms of code, write that first, and then document, or will apply a mixed strategy—especially when no convoluted algorithm design is involved. This should not be discouraged so long as the programmer generally adheres to (and sincerely supports) the documentation-first approach.

— Jef Raskin

I actually remember working this way long ago in my perl days and finding it a reasonable way to get started. It’s perl so generally you’re not writing a large application all at once so outlining some of the design with comments and then beginning to build functions worked for me as an approach and as a bonus I got a decent level of documentation for my perl scripts.

Javadoc was also a great find as I migrated into Java. Here you could have generated HTML comments all inline with the code. This used to be pitched as a major advantage over Java other older languages. It’s been a long time since I saw Javadoc talked about as a major feature of the language anymore.

Gradually I left comments behind except when documenting a tricky design decision or a hack that was left in the code for now. I use it still fairly extensively when attempting to add a bug fix or enhancement to some legacy code base so at least future maintenance programmers can have an idea of what I was fixing.

With TDD driving my designs I found more readable code more compelling than any sort comments. I like Ken Pugh’s concept of ‘extreme readability’ from Prefactoring. The idea is the code is so much like the business user’s language that they could review the code and pick up the meaning. At least that’s the goal. Jef Raskin argues that while this idea from XP is a step in the right direction:

When programmers speak of “self-documenting code,” they mean that you should use techniques such as clear and understandable variable names. Instead of n or count, it is better to use a readable, self-explanatory name such as numberOfApricotsPickedToDate. This is a minimalist’s documentation. Nonetheless, it helps—the use of explanatory names, whether of variables, modules, objects, or programs, should be encouraged.

Comments still need to come first because they can’t explain the why of a design decision. His example here is a comment about why an algorithm was chosen:

:Comment: A binary search turned out to be slower than the Boyer-Moore algorithm for the data sets of interest, thus we have used the more complex, but faster method even though this problem does not at first seem amenable to a string search technique. :End Comment

I wonder if this isn’t a straw man type argument. Obviously comments on why a certain algorithm was chosen would be helpful and a good idea for any developer to include. Otherwise they either get lost or end up a design document people are unlikely to read.

It’s a very short article so he doesn’t spend much time with the issues around comments as documentation such as when they get out of sync with the code. There’s no talk of tests as executable documentation.

If one were actually to take a comment driven design approach I can’t see how you’d be able to write useful comments about design decisions. You have to actually write tests and code to make any reasonable comment about why a design was chosen. And then how are you doing document first? Does your comment look like:

// A binary search is used here for better performance.
public String findShortestNode() {

Then doing a few cycles of writing tests and refactoring the code you update it to:

/**
 * A binary search turned out to be slower than
 * the Boyer-Moore algorithm for the data 
 * sets of interest, thus we have used the more
 * complex, but faster method even though 
 * this problem does not at first seem amenable
 * to a string search technique.
 */
public String findShortestNode() {

I think I’ll just keep adding the rare comment to explain why when I need it rather than starting out comment first.

In the last two years of using Scrum on projects the Sprint Backlog was:

Excel Spreadsheets: 6

Task Boards: 4

Spreadsheets are winning.

Our environment is a medium sized financial services company with independent projects. We don’t have Scrum of Scrums or any need for them at this point. Everyone is located on-site with the rare exception of one project that temporarily has to coordinate with a vendor off-site. All but one of the projects has worked with a collocated team.

Given our situation current practice would assume we’d probably be better off with task boards then Excel spreadsheets. Even Ryan Martens, CTO of Rally Software, agrees that:

… there is no better tooling answer than white boards and cards for individual teams and bottom-up team adoption of Agile. However, white boards and cards are not enough to support Agile development on larger programs, teams of teams, or distributed teams. In these environments, people need tools and techniques to bring the benefits of Agile to medium and large teams.

Similarly, Mark Crowe of VersionONE mentions that:

A small team huddled together in a single workspace with an on-site customer (or product owner depending on your terminology preference) can very well use index cards and whiteboards as their planning and management tools to run an incredibly effective agile process.

Other members of the Agile community can be even harsher on the spreadsheet debate including Tobias Mayer:

The Scrum books, and many CSM courses promote the use of spreadsheets to track the sprint. This is really horrible. Spreadsheets hide information, and they lie. The best way to create transparency is to display everything on Big Visible Charts. The interactive, collaborative nature of taskboards lends itself to the Scrum process, like no electronic tool ever can.

On one project we even do a task board and a spreadsheet. I had to fight a pretty intense battle to keep using the task board, even though the whole project team told me they liked it better than the spreadsheets.

The worst aspect of the spreadsheets is the inherent danger in multiple page printouts at the daily standup. Instead of just answering the basic questions and engaging in a bit of collaboration the process can break down to conversations like the following:

Team Member One: OK, yesterday I finished #42 and (rifle through a few sheets) and I started #102.

Scrum Master: Any impediments?

Team Member One: No.

Team Member Two: I worked on #34 yesterday so take 4 hours off of it.

Scrum Master: Scrum Master, hold on. (rifling back to the front sheet.) But that was only a 2 hour task so you’re all done?

Team Member Two: Oh, I guess I don’t have the newest backlog, can I borrow yours (Team Member One’s spreadsheet is handed over.)

Team Member Two: OK, so I have six hours left on #35 Credit Score Service.

Scrum Master: Anything else?

Team Member Two: Well, I’m doing the prototype for the profile page, but I don’t know where that is on here.

Now the question is keep fighting the good fight for task boards and big visible charts or go for a Agile tool like ScrumWorks, Rally, or VersionOne?

Google Developer Day was a good experience for a free event. It’s always nice to see how software development shops go out of their way to make for happy developers. There were plenty of good snacks, bean bag chairs, reasonable wireless, a foosball table and pool table. I snagged two pretty nice T-shirts and they had enough for the 1500+ developers at the San Jose Convention Center. The lunch was the best I’ve ever had at a conference of any sort. I’m guessing we were getting the Google gourmet chef experience.

The talks ranged in value. Part of the issue is they were only 1 hour and generally not technical or tutorial style talks. There was really limited times for any questions. And note to any conference organizers–when you put a single mike in the room and it fills up it’s really hard for people to pick up their laptop and clamber through the crowd just to ask a question.

It was a Google developer day so the focus was on Google tools. GWT was my focus for the day to see if it’s a reasonable approach for some of our future web apps. As it stands I’m still taking the wait and see approach after attending a few of the talks. It has some weight behind it, but I don’t think it’s really taken off as one of the defacto Java web frameworks yet. I’m pretty sure if we were leaving JSF, I’d probably favor Wicket or Struts 2 over GWT. They did have one really nice feature though. The back button actually works. Living in portlet and JSF land you often find that you don’t own the URL and supporting the back button can be nigh impossible.

Did I get enough out of it to attend next year? I’m still debating this. I’ll probably wait until next year and take a look at the agenda.

Technorati Tags:

GDD07