Matt O’ Rama

Unrealized projects

Every year, [Tim Burton] spent an enormous amount of time on failed projects.

A few: Catwoman, Conversations With Vincent, Dinosaurs Attack!, The Fall of the House of Usher, Geek Love, Go Baby Go, Hawkline Monster, Lost in Oz, Mai the Psychic Girl, Mary Reilly, Superman Lives, X: The Man With X-Ray Eyes.

One key element of a successful artist: ship. Get it out the door. Make things happen.

Seth’s Blog: Unrealized projects.

I love that Tim Burton is even willing to put this kind of info in his career retrospective instead of focusing on just his successes.

I do like my profession, I don’t like my job

To only a fraction of the human race does God give the privilege of earning one’s bread doing what one would have gladly pursued free, for passion. I am very thankful.

The Mythical Man Month, p. 291

via CLOSED-LOOP: The passionate developer: I do like my profession, I don’t like my job.

This is great stuff. I’ve always felt the way Fred Brooks talks about in that quote and this post captures a lot of how I feel about my job as well. Well worth reading.

Netflix’s Culture

Great, I’ve known Netflix was an awesome place to work for awhile and I’ve been trying to get in there. Now everybody’s going to be applying and I’ll never get in! :)

The Psychology of Incompetence

YouTube – The Psychology of Incompetence – Ron Burk.

Very cool Ignite talk (5 minutes long) about incompetence in programmers and authority. I guess I’m okay because I have no illusions about my competence. :)

(via Ben Northrop)

Good old ignorance

I’m a big fan of ignorance. One of my favorite quotes goes something like “The one saying something is impossible shouldn’t interrupt the one doing it.” There have been a lot of times in my life where I was glad I didn’t know anything about the project I was doing beforehand because I wouldn’t have done it if I had. This is a very valuable way of looking at things, even though it can be hard to figure out when you actually do need to know something ahead of time so you don’t waste time or reinvent too many wheels. Every time I start a project I think about this balance but I haven’t figured out how to figure it out, if you get my meaning. In this post I want to talk about another benefit of ignorance, being willing to admit your own and how that can be a big help.

The other day at work we had our first design / planning meeting on a new piece of infrastructure. We’ve got enough different pieces needing to communicate that we’ve wanted to put a middle-layer in place for awhile now. Since we’re going to be starting our next big project soon, we all wanted to get this piece done before starting. In the meeting, my old friend ignorance played a big part. Specifically my personal ignorance.

The other 2 main Java programmers on the team and I were meeting with a programmer from our big vendor who also knows waaay more than I do about this middle-layer piece. It might have been annoying to my teammates but since I knew very little about how we were going to build this solution I kept questioning everything and having to have it explained to me. The reason I think this is a useful thing to do is twofold. One, we need to be able to explain this and justify it to everybody so having all of us understand is very valuable. I’m a pretty smart person overall so if I can’t catch onto something or see why we we would do something it’s a good bet others won’t either. The other reason is more important: explaining something to somebody who doesn’t get it forces you to think it through. If you take the first thing that comes to mind and just do it, you might end up with something more complicated than you really need or you most likely will have to redo parts of it later when you hit walls or are otherwise forced to think it through then. I don’t mind being the dumbest one in the room at all because of this. My personal preference goes along with the Agile/XP teaching of “Do the simplest thing that can possibly work” so I bring that along as well. After our meeting we came up with a really good design that builds on things we already have (reducing the amount of work needed), is easy to understand and justify, and will add real value to our system. It’s a testament to how well our team works together that we all contributed bits of work and knowledge and didn’t just rubber-stamp some design we all weren’t happy with.

Not being afraid to question things is a very helpful trait, even though some people might not like it. If you have questions about a design your capital-A “Architect” is proposing, do yourself and your team a favor and ask the question. Make people explain it. You have to be comfortable with the design of the things you build so if somebody else designs it, they need to make you comfortable. At the very least, that’s a courtesy to the team. At best, the design will get better as the designer has to think through answers to questions they might not have considered.

Thanks to the Dilbert Strip finder for helping me find this old favorite.

Responsibility

Since I think the word “architect” in a software context has taken on all sorts of horrible connotations (it conjures up images of people who draw boxes and arrows but don’t actually write any code themselves), I tend not to use it personally. Instead, I tend to think of my role on the team as being the guy who should be blamed when things don’t work. Not the guy who should be blamed when something he did doesn’t work, but just the guy to blame, period.

from Taking Responsibility by Alan Keefer on the Guidewire DevBlog

I was glad to see this article get some links from people like Kent Beck on twitter. I read it because Guidewire is a company I’ve worked with very closely (as one of our vendors at my job) for the past 2 years but I’m happy to see it getting read outside the circle of Guidewire customers. I’ve really admired what I know of the technical group at Guidewire and have angled numerous times for a job there. I’ve never met Alan and we don’t use the product he’s the architect on, but I liked this post a lot.

I’ve always thought the job of a manager is to take responsibility for their team, whatever that means. If somebody needs help, the manager needs to help. If there’s political corporatey nonsense going on, the manager is responsible for protecting their people from that. If something doesn’t get done, the manager should be the one taking responsibility for it with the higher-ups. Then if somebody on the team screwed up, it’s the manager’s responsibility to take care of it with that person. Managers that don’t take responsibility are not only not doing their job, they’re actively harmful to their team.

Of course, non-managers should be responsible to themselves and their team as well. I take care of my own stuff at work, but I also try to take care of things the team needs if they aren’t getting done. I’m not a manager but sometimes people just need to take over and get things done. We’re about to start a new project and we have some infrastructure projects that need to do. I could just wait for somebody else to do them or complain that we weren’t given time for them, but I got a whiteboard and started making a list, as well as scheduling a meeting with the parties involved to get a plan for putting these things together. I take that responsibility for my team because I know they would (and have) taken on things for me when I couldn’t. We’re all in this together and if any of us can take on things for the good of the team, we do.

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.

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.

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.

Bringing people around to Agile

This is an email I wrote my department yesterday, talking about keeping on with Agile. The team has decided we want to keep going with the successes we’ve had with Agile but we obviously have to convince the people above us. Since I’m not a manager I have to put out my ideas and work more behind the scenes to make changes. I don’t know how useful this might be to anybody but if you’re looking at introducing Agile to your work, just think about putting your ideas out there to stew around in people’s heads.

Since the email is pretty long, click Read More to read it if you’re interested.
More »