A great (and short) video from a great coder about selling software to women. While the talk is about women, really the larger ideas are about anyone.

I’ve been thinking about these sorts of ideas for awhile and I’ll have a post on it soon.

Merlin Mann – Scared Shitless – Webstock 2011

Sheesh, pretty much everything Merlin does blows me away in some way or another. Even without hearing the talk that goes along with these slides he succeeds in moving me in a very real way that few other writers do. You should listen to his podcast, follow his blog, and keep up with his tweets (which are more of an acquired taste but once you get on his wavelength frequently inspire me and/or make me laugh out loud (for real, not in a LOL sense)).

At the 2010 Roundup, I was once again faced with seeing people doing things with their career that I want to do. I want to be learning and growing as a programmer the way a lot of Roundup attendees are. I decided that once again I would reevaluate my job and try to figure out what the best thing would be. The difference is, this time I want to figure out what to do not to escape a bad situation but to go towards something good. I haven’t decided what to do yet but I have refocused my efforts toward learning and getting better rather than just sitting comfortably.

I’ve always learned on the job and I’ve found I’m very good at that. The problem with that kind of learning is it tends to leave gaps in your knowledge since you don’t learn as much that you don’t need right then. I’m rectifying that with a renewed course of study in the areas I feel I’m missing. I’m also focusing on the quality of the work I do and the code I write even more. I don’t work for a software company so I’m a little limited in the efforts I can put forth here but now that our boss has decided we’re to run our own projects I’m definitely pushing more quality into my work and I’m prouder than I’ve ever been with my code.

Like I say, I haven’t decided exactly what to do so this blog post doesn’t have some big conclusion. My new focus is a big deal to me though so I wanted to write it here and not forget. More to come!

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.

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.

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! :)

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)

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.

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.

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.