Rands Says Managers Should Develop

Twenty-three hours later the nasty bug is squashed.

Turns out I descended into completing project tasks last week. Generally I get massive pangs of guilt. I know some other management tasks fall by the wayside from that PO I was supposed to fill out for Acrobat to following up with a business manager on a potential new project. On top of that I get emotionally attached to squashing a bug and I typically can’t let it go. The 23 hour bug spanned out over a couple of days of work and some really late nights.

Rands of Rands in Repose explains that despite all the enlightened ideas of moving away from the technical work that you just have to stay in the code:

I’m not wishing confusion and chaos on your team. I’m actually wishing better communication on it. My belief is that if you are building the product and touching the features that you’ll be closer to your team. But, more importantly you’ll be closer to how software development is constantly changing in your organization.

So I’m in good company, as based on his blog alone Rands appears to be a hell of a development manager. He makes four points about what you need to do:

  • Use the development environment to build the product.
  • Be able to draw a detailed architectural diagram describing your product on any white board at any time.
  • Own a feature.
  • Write a test script.

I managed to do all of these suggested items in some form already, I’m a genius!

I run two IDEs currently on my work laptop. One by choice and for productivity (IntelliJ IDEA) and one because all of my developers use it (RAD).

I can whiteboard any of my three big projects right now to some level of detail if asked. The one that I get the architecture least is a 3rd party vendor product and I just need to sit down and actually do some code reading to understand it better. And not knowing it’s architecture in more detail bothers me.

Owning features, that’s just crazy. There’s danger of going overboard here on Rands account, but since my developers are on at least three projects at a time I think owning a feature on each would be pretty much management suicide. The PMs/Scrum Masters on the projects would love it because I’m a ‘free resource’ who isn’t going to bill time against their project. I do my part though with helping out on the occasional bug, keeping the build box running, participating in a code review and on rare moments owning a bug or feature.

Finally, writing a test script on the build is a specialty. I tend to write the actual ant scripts that run our builds, and I maintain the build box running a copy of Hudson. I also manage our code review tool, and hook in Clover and Checkstyle into our builds. I know the code that’s getting checked into source control.

I’m rethinking my little voice that keeps saying, ‘don’t even think about firing up your IDE today, you have 6 meetings to go to.’ Maybe I should finally get around to pairing up with individual developers to go through a TDD exercise for a few hours each, couldn’t hurt.

MBA: Now, Later, Or Never

Dina, one of the creators of the project management podcast Controlling Chaos, is heading back to MBA school at age 42. Better yet, she’s planning on attending UC Davis MBA School which is currently the best available option in the Sacramento region. And best yet, she’s blogging the experience.

Her decision to go for it came down to:

I really like being a project manager and the company I work for is a super place to work. But I’m at the top of the pay scale and top position for a project manager. There is no where else for me to go unless I want to move into a functional manager role. Upward mobility and taking on more responsibilities, decision making authority, being a part of driving the strategic direction of a company, and yes, more salary is very important to me. Not going to happen in my current position.

I’m rooting for her to get a good GMAT score for selfish reasons, to see what MBA school at UC Davis is like.

My wait and see thinking from a year ago still holds:

  • Fully engaged as a development manager.
  • We’re still paying off my wife’s law school loans.
  • I need time to spend with my two daughters.

Good to know I’m not crazy for still considering an MBA at 37.

Haskell and Tabs

Today, I learned Haskell doesn’t like tabs. Haskell apparently uses some syntax conventions to connote things like blocks. I was working my way through a Haskell tutorial when I found the following snippet of code kept getting compiler errors:

fails
main = do putStr "You are? "
          name <- getLine
          greet name

Turns out you can also enclose a block in angle brackets so this code worked

compiles
main = do { putStr "You are? ";
name <- getLine;
greet name }

Then it dawned on me. My TextMate Haskell setting were showing

1
Hard Tabs

instead of

1
Soft Tabs

with spaces. Flipping it to use spaces made the same code pass compilation.

compiles
main = do putStr "You are? "
          name <- getLine
          greet name

Experimenting with lining up the arguments after the do showed that all of the statements had to line up vertically. Thus this reasonable looking syntax would fail:

fails
main = do putStr  "You are? "
                  name <- getLine
                  greet name 

I’m still very much at the beginnings of digging into Haskell, but it’s nice to play around with a language purely for intellectual curiosity.

Wicket at SacJUG

We had a sort of ad-hoc demonstration of Wicket at the local Sacramento Java Users group (SACJUG) this week. Out of about 25 people there two people are actually using Wicket. Since there are a ton of web frameworks and we ended up in the JSF camp I just don’t spend a lot of time looking at new options, but spending an hour or so watching a demo wasn’t going to kill me.

Wicket is very component centric and I like the syntax:

1
public class CalculatorApplication extends WebApplication
1
public Class getHomePage()
1
public final class LoginPage extends WebPage
1
public final class LoginForm extends Form

And it has some nice features:

  • Stateful by default.
  • No JSP pages.
  • You can use the back button.
  • Minimum reliance on special tools.

Of course my favorite is the POJO centric nature and the fact that they just build their unit testing support package,</p>

1
wicket.util.tester

</a>, into the main API. Almost makes me want to spend some time playing around with it, but I think I’ll wait until I see some more uptake, since there are far too many web frameworks and no winner or limited pool of winners currently.

Crucible 0.9

Over the weekend I upgraded Crucible, our code review tool, to the 0.9 release. Looks like it’s nearing 1.0 readiness. When I upgraded it on Saturday night I noticed they fixed an annoying bug where you couldn’t just delete a review. We had a few test reviews in the system that we wanted to delete since we were just showing people how it worked.

Deleting away I realized we’ve been doing less reviews over the past two months or so. Code reviews are not exactly your stickiest developer practice without some coaxing. It also makes a good point why pair programming especially with rotating pairs can be a really effective way to actually have a high level of code review. Since pairing is still very optional in our shop we’ll be using Crucible for a long time to come.