The Buck Stops At the CIO

CIO Magazine has a great article on Users Who Know Too Much (And the CIOS Who Fear Them). The tone of the article suggests that IT organizations need to embrace new web based technologies from IM and GMail to BaseCamp and WordPress. They’re making your business a better more productive place even if your sysadmins are screaming about those ‘idiotic users.’

Rob Israel, CIO of John C. Lincoln Health Network, has seized on this and come up with a novel solution:

“I’m the only person in IT allowed to say no,” he says. Conversely, his IT employees have only three options: approve a request, research it or pass it up to him. According to Gold and Israel getting a reputation for saying yes will encourage users to come to you with ideas. That gives you the chance to learn what it is that the user is really trying to do and come up with a way to do it that won’t compromise security.

Assume that your internal customers are using a new tool for a good reason and support their attempts to improve productivity. Rob sounds like the sort of progressive CIO we need to see more of.

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:

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

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

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

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

Hard Tabs

instead of

Soft Tabs

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

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:

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:

public class CalculatorApplication extends WebApplication
public Class getHomePage()
public final class LoginPage extends WebPage
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>


</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.