Matt O’ Rama

Clean Code Review

As developers, system admins, and a variety of other roles in IT, we have to deal with code on a daily basis. Sometimes it's just one-off scripts we never have to see again. Sometimes we stare at something that, for the life of us, we can't understand how it came out of a human mind (or, as the book puts it, has a high WTF/minute count). But there is a time when you find code that is a joy to use, to read and to understand. Clean Code sets out to help developers write that third kind of code through a series of essay-type chapters on a variety of topics. But does it really help?

Slashdot | Clean Code.

Good review of a book I’m hoping to get to reading very soon.

Creating Scrum the Product Backlog: Start with the Users!

Creating Scrum the Product Backlog: Start with the Users! | Agile Software Development.

I like this approach. One thing we haven’t done as much as we should have is focus on the users of the product. We tend to focus on replicating the existing functionality and if we come across some way to improve things, we do it. We should be trying to find better ways first.

Joshua Bloch on Bumper-Sticker API Design

It is my hope that these maxims provide a concise summary of the key points of API design, in easily digestible form:

All programmers are API designers. Good programs are modular, and intermodular boundaries define APIs. Good modules get reused.

APIs can be among your greatest assets or liabilities. Good APIs create long-term customers; bad ones create long-term support nightmares.

InfoQ: Joshua Bloch: Bumper-Sticker API Design.

We’ve been working on building web services for our big project here at work and the API of the services has been a concern of mine for awhile. We’ve mostly been throwing these things together for one-off needs but I’d like to start formalizing a bit of what we’ve done to make it more manageable and maintainable. I think I’m going to print this list out and keep it handy.

My First Agile Project Part 3: Viral Videos and Bad Jokes in Scrum Demos

Originally published on AgileSoftwareDevelopment.com

Welcome to the 3rd part of my series on my first agile project. This time, I’ll be talking about every introverted programmer’s favorite part of Scrum, the end-of-sprint Demo. More specifically I’ll talk about how we cracked wise, showed internet videos, heckled each other, annoyed our management, and occasionally showed off the work we had completed during the previous sprint.

Even though we usually dreaded them, our demos almost always went off okay and we all came out alive. If you’re not familiar with them, the demo is where the team shows off the work they’ve done during the previous sprint. We were doing 4 week sprints so we usually had quite a few things done by the demo. It’s sometimes the first chance your teammates have to actually see what you’ve been doing and to to catch up the rest of the team in a more concrete way than the daily stand-up meeting. It’s also where you’re supposed to get the feedback of the stakeholders and customers involved in the project. With our billing application project, we were interacting with a bunch of different departments in the company so we had a lot of stakeholders. In theory, all of these people will see the product and give feedback. In reality, this doesn’t always end up working like you’d hope. Getting your demo right is much more important than we initially thought.
—
Integration Project Demoing Challenges

Demoing an integration project isn’t a topic I see discussed very much. A lot of the writing about Agile in general is geared toward new product development, not configuration or integration of existing products. Demoing an integration project is a lot harder than the literature on demos would suggest. With a new product, you can show off a new piece of functionality or screen, something like that. On a project like ours, we had a product that was mostly complete looking. And since you’re showing your work off to business people, how it looks is most of what they’re getting out of your presentation. Even interface configuration changes can be subtle and uninteresting, which is extra important if the change is very valuable since you want people to pay attention.

We had a lot of “behind the scenes” processes and integrations with other systems to build as well, which presents a whole different set of demoing challenges. In a billing system, the interface consists of lots of numbers. For a lot of our integrations, you literally work for a month on something and your demo ends up being “I’m going to simulate Event X in this other program by pushing this button and Voila! this number appears in the billing system.” Our team was split roughly into integration programmers, configuration specialists, and database specialists. For the programmers, most of what we did was this kind of thing. “Once a month, this process will run and generate this not-human-readable file to send to the bank.” This isn’t as much of a problem showing off to your team but to the stakeholders, this is nap-time. Part 4 in this series will go into the issues we ran into with disinterested management. It’s a big topic and one that deserves more space than I can give it here.

We had 10 to 12 people demoing and another 10+ in the audience so we did our demos in a conference room on a large projection screen, not at the developer’s workstation as a lot of people do. Doing a demo on a big screen lets more people see it but a lot of what people think of something is based on actually using it. We’ve put in tons of fixes nobody suggested at the demo but came up immediately when the same people sat down and actively used the product. I really recommend getting people to sit down and use your product as early as possible, it’s extremely helpful.

Coping Mechanisms

Getting up in front of a bunch of people and showing off your work doesn’t tend to land high on most programmers’ list of favorite activities. For some people, this means getting stage fright of varying seriousness. We decided early on not to take too much time from doing our real work to try to work on our presentation skills. We just did our best and every demo we got better. Of course we had some people who aren’t good at presenting but since we knew what they were talking about we tried to help each other as best as we could. I’m a shy person by nature so I don’t enjoy presenting but I compensate by making jokes and basically entertaining myself while up at the podium. As long as you’re not taking up too much time with non-work stuff, people don’t mind the joking around. Since we had 10 to 12 people on the team and a month of work to show, our demos lasted a few hours usually and the audience was as ready to break up the flow as I was. One of our team members is very funny and always did the best presentations. Once during his presentation he told everybody “that buzzing you’re feeling in your head is your mind being blown”, which cracked everybody up. One month I used the Dramatic Chipmunk video in my demo before an important thing happened. Then after that I introduced our champion presenter using the Dramatic Lemur video, which uses the THX sound you hear before movies. This definitely helps to break up the demo for everybody so I would encourage letting people “off the leash” a bit and try to make their demo a little more entertaining.

We’re trying to figure out the best way of doing our demos so please share your demo stories below. I guarantee my team won’t be the only ones interested in your experiences and ideas. As always, thanks for reading.

“it’s your job to defend the code”

As I read “Clean Code” by Robert C Martin, I was particular drawn to the passage about why unrealistic commitments should not be an excuse for writing bad code. He points out that while it is a manager’s job to “defend the schedule and requirements”, it is a developer’s “job to defend the code with equal passion.”

“it’s your job to defend the code” | Down Home Country Coding With Scott Selikoff.

Kim bought Clean Code recently and I’m looking forward to reading it. I really enjoyed Bob Martin’s talk at Agile2008 and it looks like the book focuses on the same ideas.

History Hacker TV Show

Bre Pettis | History Hacker on History Channel.

Watch Bre Pettis’s TV show pilot this Friday at 8pm and Midnight on the History Channel. Bre is awesome and the first episode is on Tesla, one of my heroes.

On Scala

I’ve been using Groovy quite a bit and I really like it. It’s a JVM language so I can use Java stuff but it’s Perly enough to warm the Perl hacker bits of my heart. The other day I heard an interview with Martin Odersky, the inventor of Scala, on Software Engineering Radio and it’s made me very excited to learn it. I’d heard of it but was into Groovy so I didn’t get too far beyond having heard of it. It’s looks extremely powerful and exciting though. This is a small presentation but it’ll give you a bit of the flavor. For more info, I really encourage you to listen to the Odersky interview. It’s technical but still a good overview, with good explanations of the features and functional-programming things it uses.

My First Agile Project Part 2: Inception & Planning

Originally published on AgileSoftwareDevelopment.com

Picture courtesy of ghindo@flickr

In the first part of this series about my team’s first Agile project, you read about some of the mistakes we made in only doing 80% of Scrum. In this part, I’ll talk about the initial Inception Phase of the project and about our Sprint Planning meetings. As usual, we did some things right and did some things we hopefully won’t do again. I’d love to hear in the comments how our experience compares to yours.

Inception Phase

The first part of our project was what we called the Inception phase, a sprint or so of basic requirement gathering. Some people call this phase Iteration Zero, a name that I like a lot for nerdy comic-book fan reasons. This phase was good and bad. For me it was good because I was fairly new to the company and I learned a lot about how the business works. For some background, I work at an insurance company and the project is to integrate a new billing system to replace our decade-old custom Oracle form app. Billing in insurance is fairly complicated; both insurance agents and insured companies are involved, there are deductibles, claims, premium charges, etc.

For a month, the senior programmer and I did almost constant meetings with various parties around the company, taking notes and trying to figure out where and how the billing system needed to integrate. This gave us a good list of what integrations we would be writing (talking to the claims system, printing checks, probably a dozen primary integration points overall) and what some of the customizations we would need to do were. What I didn’t like about this process was that we were directed to write integration documents for each integration point, including descriptions of what they did but also flow charts of program flow and a lot of detail we didn’t need. Being new, I did learn from these documents but nothing I wouldn’t learn again, or in some cases have to un-learn, later when we started doing more in-depth requirements gathering. Next time, we’ll do the meetings to get a handle on what integrations we have to do but we’re not going to do all the documentation again.

Since we were doing Scrum, we weren’t supposed to get too much detail in these meetings. “Snorkel”, not “Dive” was the direction given. Eventually though, you do need to dive deep to get enough to work with. A problem we had a lot was that our Subject Matter Expert / Product Owner had a lot to be expert on so she was incredibly busy all the time. We would assign tasks in the sprint planning meeting, then go get deeper on requirements gathering. This meant a lot of the time we were waiting on her and the people she needed to meet with to get enough detail to work with. If you’ve ever had to wrangle the schedules of more than 2 managers/directors in a company, you know how the days can fly by trying to get everybody in the same room.

I’ve since learned that the recommended practice is to make sure your SME starts gathering requirements for the next sprint’s tasks. This would have made things run a lot smoother. Since your backlog should be prioritized ahead of time, the SME should have a good idea of what’s going to get worked on next time even thought it’s the team that decides. With a good base of details in place, work can usually start and intelligent questions asked once the clock is ticking on the sprint.

Sprint Planning

We did 4 week sprints on our project and we had around 10 developers, including 2 database experts for converting our old data. This meant that our sprint planning meetings ended up being all-day affairs. We tried a lot of things to shorten them but never really succeeded. As I mentioned in Part 1, we didn’t estimate difficulty on our backlog items ahead of time (a mistake, in case you missed Part 1). We had our list of integrations and known configuration changes, and it was somewhat prioritized. So in the planning meetings, the first thing we would do is take the top bunch of items and move them one at a time into the Sprint Backlog. As we did that, we would take our best guesses at who would do the work and how long that person thought it would take.

I know some people say you shouldn’t assign work directly to people in your sprint planning, instead assigning it to the team and letting people pick work off the team list. We didn’t feel like this would be the best plan. Even if we hadn’t done specific assignments, tasks would have mostly fallen on the same people anyway due to experience levels, specialties, etc. And when you assign to people, you have a better idea of how full everybody’s plates are. Of course it’s still a team and we all did our best to help out with everybody’s tasks so even though someone’s name was on something we all knew we should take or give tasks as needed. If you have people who don’t take tasks or appreciate the help, that’s probably Job 1 to take care of. Agile is largely about the team and if your team doesn’t work together, it’s a lot harder.

At first we didn’t do very much breaking down of stories into tasks since we were so new to the product and really didn’t know what each tasks would entail. Without a lot of good information about the tasks to go on, our estimates were hit or miss, honestly. Sometimes things that looked easy would run into some snag in the product and take 2 days. Sometimes things we thought might be impossible took 2 hours. (Being able to say “We thought this might be really hard but I got it done in 2 hours” is impressive during a demo, believe me.) Doing estimating on an integration project with an off the shelf product with an architecture of its own that you need to get familiar with is a different beast than green field development. You can know how to do something from scratch and have no idea how to do it so it integrates with somebody else’s product or APIs. It’s worth doing your best to figure it out though. If you start a sprint without a good idea of how much work something might be, you could spend all sprint just getting requirements nailed down.

Next Time

Once you’ve planned and done your tasks for the sprint, you need to show off what you’ve done and get feedback from the people involved. The next couple of posts in this series are going to be about our demos and issues of management buy-in and stakeholder involvement. What we did, the successes and failures we had at demos, and more coming soon. Thanks for reading and I’d love to hear your comments and experiences below.

My second agile story is up

My second post about our team’s experience with agile has gone live on agilesoftwaredevelopment.com. I’m really proud to be able to post on that site, the other writers are posting great stuff all the time. I’m still getting used to having to write a good-sized article every week so we’ll see how it goes. The problem isn’t the writing so much as the editing, trying to get the posts to not be so rambly like just about everything I write on here.

Starting back on Scrum

Right around the time of our first deadline, we decided to stop doing iterations and start just banging on whatever bugs we found. After we didn’t go live we never went back on the iterations, which was a mistake. Today we had our first sprint planning in a few months. Unfortunately it’ll only be a week sprint since most of the team is going out to San Francisco next week for a vendor conference. Of course it’s hard to feel too bad since we’ll be in San Francisco, my favorite city, but it did make for a somewhat half-hearted planning meeting. We used to use Scrumworks but our licenses are gone and we never really liked it anyway so this sprint is going to be tracked using a spreadsheet and a whiteboard. After we get back I’m planning on using VersionOne to track things. I’ve been using it on a trial basis and I like it a lot, I just need to get the team using it to see what they think.

For this half sprint we decided to take a couple of core areas we’re still struggling with bugs in and hit those as hard as we can. Another teammate and I will be hitting the invoice bugs that somehow are still popping up with alarming regularity. The others will be hitting one of the other statements and a few of the high-priority financial issues. I’d like to see a good number of these things knocked out before we leave so the testing team doesn’t have to deal with them. Testing a billing application is ridiculously time consuming and any one bug can cause hours and hours of testing to be wasted if it affects a balance somewhere unanticipated.

Before the planning meeting we got together and did a short session of planning poker as well, our first. It went pretty well. Once I explained how it was supposed to go, we moved through a bunch of issues really quickly. One problem we had was that the stuff we’re working on mostly now are bugs so it’s hard for everybody to have an idea of how hard something will be to fix. I think we’ll try again but the planning poker will really be helpful once we’re doing new development work again.