Matt O’ Rama

Home Tech Heads

Home Tech Heads

Hey look, it’s me! That’s right, it me in this week’s issue of the Alibi. It’s from a great article on the Idea Propulsion Lab, the hardware hacker club I helped found here in Albuquerque.

My Agile2008 Notes on Evernote

mattgrommes’s public notebook: Agile2008Notes.

I’ve published my notes from the Agile2008 conference on Evernote. My handwriting is poor in these notes but the searching of the images that Evernote provides works on some things. If you’re interested in a particular session, try searching for it. Even if you don’t find it, the interface is pretty good for just scrolling through. Hopefully they’re useful!

Exciting news

Exciting if you’re me (and possibly if you know me) anyway. :) I’ve been invited to start writing some articles over at the Agile Software Development group blog / news site! I’m going to be doing weekly posts on our project at work; what we’ve learned, how we’re doing things, etc. I’ve never written for another site before so it’s a great opportunity to get my name out there and to start communicating with other people about Agile. It’s also going to be great to have a deadline and have to keep writing regularly. I’m really looking forward to it.

The other news is that the Idea Propulsion Lab hardware hacker club I founded is going to be featured in the Weekly Alibi paper here in Albuquerque. I think the issue with the club in it is going to be out tomorrow (8/26). A photographer was here yesterday taking pictures of me pretending to solder and of some of the stuff I’ve built. I’m one of the least photogenic humans around so hopefully it’ll turn out okay.

My friends were joking around that I was going to need a PR person to handle my media before too much longer. :)

My First Agile Project: Part 1

Doing 80%

This is the first of a couple of posts on what I’ve learned about how we’re doing (and not doing, as I’ve learned) Scrum on a big project at my work. Going to the Agile2008 conference and reading Mike Cohn’s Agile Estimating and Planning have really helped me understand how we got into the predicament we’re now in, with a late project and diminished team credibility with our upper management. Like most of the posts on this site, I’m probably going to ramble since I’m really just trying to write this down to help myself think it through. I do hope it’s useful and informative though. I’ll probably have more posts about some of these points later to flesh out my thoughts (including the importance of upper management buy-in, Agile on integration/upgrade projects, and others), As always, I’d love to hear any comments you have below.

We were brought Scrum by the vendor of the new billing system we were integrating. They use it internally and taught us about the practices. Immediately, it was a hit. We all liked the iterations, taking on tasks, demos, etc. Except the day-long planning meetings (we were doing 4 week iterations and have ~10 people on the team so that’s a lot of estimating and assigning) we liked the whole process. I had complaints very early about the seeming lack of involvement from upper management but we dismissed it at the time, thinking they would come on board later. I gave a presentation at one of the demos about Scrum, having been told that some of our senior management team would be there but they weren’t. The project seemed like it was going along fine though, so we just kept going.

The first big non-Scrum thing we did was we had an enforced deadline given to us by senior management based on a planning spreadsheet the vendor did. At the beginning, we thought we could meet that deadline so we didn’t think about it. Bad idea. Since the vendor had brought Scrum to us, and had people in our office working with us, we figured we were doing everything right. The other huge non-Scrum thing we didn’t know about, however, was the practice of looking at our velocity and reexamining the end-point of the project. That, of course, is a big deal and now we’re paying the price. We just kept adding stuff into the project and iterating, without knowing that we should be taking much harder looks at the backlog and the amount of work remaining.

If we had known about using velocity to estimate the amount of work remaining, we would have known how in trouble we were. Our velocity was very consistent month to month but we never used that knowledge for anything. The result is that our deadline came and we had to get an extension but it was another arbitrary number, not based on our velocity or the amount of real work remaining. That deadline also came and went, and we’re about to get another extension. The difference with this last extension is that now I know what we should have been doing all along and I’ll make my voice heard.

Now, I can’t blame the slippage of deadlines on any one thing, which makes looking back much harder. We had to deal with literally the worst software vendor I’ve ever heard of, let alone worked with. The less said about them, the better for my blood pressure. But they did contribute to the slips immensely (and still are, so at least they’re consistent). Another thing is that it turns out converting 15 years worth of financial data from an old system to a modern one is really, really, difficult. So that took longer than expected. And we had to implement a large piece of functionality on our own that the vendor should have done most of. That sucked up probably 4 full months of our most experienced programmer’s time when the vendor told us it would be 2 weeks of work.

But taking that into account, almost certainly would have still taken until now to finish if we had known about the full Scrum processes we weren’t doing. The difference is that our management would have known where we were the whole time and we could have taken a different tack in prioritizing features. (One problem I’ve had is finding help on implementing Agile in integration / upgrade projects. Most of the literature is on new development, which I’m planning a post on for later.) Part of the whole point of Agile is making sure people aren’t surprised and we’ve now surprised our management more than once. And I can’t say it’s all their fault for not coming to the demo either since we didn’t have the data we needed to be showing them. We also didn’t start taking things off the backlog for inclusion in the first release until very recently. Partly because in an upgrade of a billing system there doesn’t seem to be much that can be left out until you really start looking. Since we didn’t think we had to, we weren’t as brutal about taking things out as we clearly should have been.

I’m calling this part of what I think will be a couple of posts on this project Doing 80% because I think we were doing 80% of Scrum. We were doing iterations, estimating hours, assigning tasks, and demos so we thought we were doing just fine. If we had been skipping those fundamentals, we would have known something was wrong. The danger is that since we were doing 80% and we were new to Agile, we thought everything was fine. Now I see that if we had been doing that other 20% of planning and estimating and reexamining the backlog it would have helped tremendously. Now for our next projects I know what we need to be doing so hopefully things will go a lot smoother. Now we have our own knowledge and won’t be reliant on the vendor to tell us if we’re doing things correctly.

More on my first agile project later. Thanks for reading.

Thinking about Windows programmers

IT Conversations | StackOverflow | Episode Seventeen.

There’s a website for CSS and HTML called “Don’t meet your heroes“, which has always been one of my favorite website names. This podcast always makes me think of that phrase. I really like Coding Horror, which is Jeff Atwood’s blog about programming. It’s great, even though I don’t always agree with him. But now he’s doing this podcast about a website he’s building called StackOverflow and listening to him, he keeps losing cred with me. He’s a Windows programmer, which earlier in my life I equated with brain damage. I’m a lot less judgmental now, especially since my wife has done a lot of Windows programming, but I’m still biased against Windows if I’m honest. The problem with Jeff on this podcast, especially this particular episode which is the “Developer Episode” where they talk nuts & bolts about StackOverflow, is that the things he’s discovering are really old hat to anyone who has done development on Linux (or anywhere but Windows I imagine). I can’t tell if the Windows development environment is really stunted from basically having one IDE, Visual Studio, and the related tools from MS, or if he and his team don’t pay much attention to programming practice.

They’re really surprised about continuous integration using Cruise Control versus the MS tool which apparently requires you to install Visual Studio on your server (!!!). They all seem to be new to the very idea of MVC (model, view, controller) programming, which has been pretty standard for years, because MS is just now coming out with their approved MVC product/environment. Jeff talks about LINQ like it’s the only option for not putting SQL directly in your code, despite various ORM tools and similar things being around for quite some time. They do use nUnit, which is the .Net port of jUnit, so they do have that going for them.

But don’t even get me started on Jeff’s decision that writing tests somehow makes you less agile. Yeah, not having tests lets you write crappy code much faster. Great!

Now, I have no doubt that all 3 of the guys on the StackOverflow team are much, much better programmers than I am. Even without seeing their code I would venture to say I know they’re better than me. No slight to them personally, at all. At all. But I can’t tell if the lack of knowledge of what I consider basic standards is them or their environment and that’s bad. I guess if I’m a Windows shop and I come up against somebody who has never heard of MVC, that’ll be fine since I won’t have heard of it either. But if I’m used to people who think MVC and continuous integration and unit tests are given parts of good projects and I come up against people who only have experience with Windows stuff, they won’t seem like they’re as experienced. And I’ll have missed out on good programmers, most likely.

On the other hand, Joel Spolsky is a Windows programmer and well, he’s Joel freaking Spolsky. He and many others are probably existence proofs that I have no idea what I’m talking about.

Are Windows programmers missing out on so much good stuff because they don’t pay attention to the tools used by other programmers? Java has a rich environment of tools by many, many different parties. I have 2 different static code analyzers (just for an example of a totally niche product) in Eclipse (1 of 4 really nice IDEs for Java) telling me about bugs in my code. Does Visual Studio have anything like that? I can think of 3 different continuous integration tools. It seems like if they paid attention to other programmers’ tools, MS would have to provide more than they do or the environment of 3rd party tools would be a lot stronger.

I’m not sure what the point is of this post, I’m just trying to figure out how somebody who obviously knows a ton about programming misses out on so much of what I (and others) would consider very basic ideas. I don’t think it’s just that there’s stuff about .Net programming that I’m missing out on. I read a lot about programming in a lot of different languages and it really just seems like the Windows development ecosystem is missing a lot of things because Microsoft hasn’t put whatever-it-is out in a box with Visual Studio. Jeff even talks about using some 3rd party code diff tool, for pete’s sake. How can you use an editor to work on code with other people without a diff tool and source control built in?! I still like Jeff and Coding Horror and I’m sure I’ll love StackOverflow from what I’ve seen of it. I guess I’m just going to have to accept that different environments can produce different kinds of programmers. Smalltalk people are probably laughing their asses off at my I consider my toolset so it’s all relative.

If you’re a Windows programmer, I’d love to hear more about working in that environment in the comments. Thanks in advance.

Pair programming. What researchers say on the costs and benefits of the practice. | Agile Software Development

Pair programming. What researchers say on the costs and benefits of the practice. | Agile Software Development.

Just what I was hoping would come from the post the other day about pair programming, data on its effectiveness.

First Java servlet

As I mentioned on twitter today, I wrote my first Java servlet today. I had written part of a webapp using the Tapestry framework a few months ago but stuck and haven’t gone back to it. This was a basic servlet to take a chunk of XML and send it via JMS to a queue for testing a new JMS integration architecture we’re working on for work. It seems like everything in Java has some weird name that always makes me think it’ll be harder and more complicated than it is. I’m used to Perl where you just drop a file in Apache and use CGI.pm to pull out the parameters. Turns out writing a servlet is almost that easy, although the setup to get all the files and classes deployed in Tomcat is much more complicated. Luckily I’ve done enough with Ant to hack a deployment script together and we have an Ant expert I can ask for anything hard. As usual, what I did was find a couple of examples and hack the heck out of them until I understood them and they did what I wanted. I did go through part of the first chapter on servlets from my Head First Servlets & JSP book that I had barely cracked the cover of before, so that’s more research than I usually do ahead of time. Overall this basic servlet was pretty easy, although I know I just scratched the surface of the power and complexity available. Tomorrow I start working on figuring out how to send JMS messages. Luckily my team is incredibly good and I have good examples to hack on.

Funny Processing update

16 Aug 2008
Processing version 146 released. It's one better than 145. Download here

hehe. And what do you know? It is one better.

Mik Kersten presents Mylyn 3.0 (Webcast)

Mik Kersten presents Mylyn 3.0.

I haven’t watched this yet but I love Mylyn and I just upgraded to Eclipse 3.4 (Ganymede) so I want to start learning about the new features.

Five risks of solo programming

Five risks of solo programming | Agile Software Development.

• High defect rate
• Distractions that force you out of the zone
• Low focus and discipline
• Low incentive to adhere to common practices
• Slow learning

Pair programming is one of the practices I’ve always had a hard time wrapping my mind around. I’ve been told a bunch of times how great it is, and I’ve even been party to the benefits in small amounts as debug sessions and the like, but I can’t get to the point of accepting that I should be doing it all the time. One of the commentors on the post basically gives all the standard complaints and I hope the author or somebody gives a rebuttal. At the conference a lot of people stated pair programming as a given good, “proven” to work. I haven’t seen that proof but I’d like to find it.