Code Freeze '08

Last Thursday I went to Code Freeze '08, put on by the University of Minnesota Software Engineering Center. I bumped into Luke Francl. It was good to put a handshake and face to someone I've chatted with on blog and in email now and then.

The conference was very good, focusing on innovation and software development. A much stronger offering than the presentations on off shoring last year. Does anyone really like to talk about off shoring who isn't making their living managing some part of it, or making a living talking about off shoring? The question I put forward to the panel this year addressed both conferences. I was interested in how this panel of experts perceived the intersection of innovation and off shoring, about which Joel Spolsky has offered a word or two. If I could have clarified, I would have explained that I was primarily interested in the separation of innovation from development - whether there are consequences to off shoring that might include accidentally off shoring your innovation.

As an example - there is a group at work that has a project that isn't a revenue generator. So all coding for that project was off shored, leaving just a PM-style individual onshore to oversee details and, presumably, innovation. In the past, the project self-innovated. New ideas came from both customers and from developers, and met in the middle, finding creative technological solutions for customer needs. The requests for innovation since off shoring have moved outward on the onshore side, diffusing onto the customers and several internal groups, and away from the application. The application seems to be suffering an innovation drought as a result.

So, obviously I have my own opinion, and I was interested in this aspect of innovation, not information about co-location of company employees as an innovation hurdle. Thinglestad (I think it was him) might have almost answered what I was after, he was on the edge as he began to address offshore firms that are involved in agile, end-to-end, solutions and how these firms are arising where before there were only code shops to service big companies, but I don't think he went far enough. Offshore for maintenance is dangerous only insofar as a big company employs fewer innovators. Off shoring of the latter sort (to agile teams) means your company is paying others to innovate for you, and they may decide to keep the more nebulous and ethereal innovations and practices they create to themselves. I was hoping someone could speak to the reality of that concern.

Some other ideas I think were interesting I gleaned from the conference:

Where is my company's version of the Fellow? The researcher who goes around to conferences speaking, evangelizing, and disseminating best practices so they can be improved upon and come back in new patterns from local developers. Where are the lifelong learners who move from group to group, generate relationships with other corporations, and generate buzz in the community that makes developers want to work on our teams? It's not the architects in my company. They're primarily focused on individual projects, although they often bring new technologies to the table, and those projects can be targeted at general infrastructure. But our architects don't turn around and evangelize our use of products and practices to the world. At least not in any venue to which I've been witness. I've only heard of two people from our company speaking at local technical conferences and, in one case, the individual had some serious restrictions placed on their ability to show off practice and code. In the other case, I knew about it because the SAS presentation happened to be in front of my brother. Our combination of (Chief/Principal) Architect/VP might come closest to a Fellow, but even in that case, I've never seen one speak at a local conference, or seen one quoted in the news, about ways our company is innovating.

I think Thinglestad's statement that process is an innovation killer and, as a result, you should audit yourself (as a project and company) was accurate and concise. In my company there are areas where you can see the scale of process and innovation tipping this way or that as they're separated from each other, process being driven as something in and of itself, without relation to real practices.

The Google policy of giving developers 20% of their time for innovation came up many times, and there were numerous comments about how nice that must be. I've always thought we had some of that where I work - it's just not acknowledged. You have to claim it. I'd say "hide it", but that's not exactly true. If you come right out and tell our company, "I need a certain amount of time to innovate. Call it administrative time, call it overhead, call it whatever," you'll probably get it. It's easier not to mention you're doing it and bury the time, but if you're a Boy Scout, I think they'd oblige. Maybe I'm wearing rose-tinted glasses. Maybe it only seems that way if you're a Lead Software Developer. Maybe it's only not-scary if you're comfortable that what you develop, and your use of live/production resources, is not accusation and risk free (like it is at Google). But if you can wrap yourself around those risks, you can find the time to create.

One of the attendees at the conference from my company noted over lunch that they really wanted to work on "something more interesting." This was a bright, working-on-a-Master's-in-Comp-Sci at the University of Minnesota, programmer. I've heard that before at our company, and it always surprises me. Erik and I were talking about it and I said that when I was a lead, I always had a list, and I'd just say, "Here, pick something. Anything. Work it into a new feature. Work it into an old feature. Work on a reporting system and put it in there. I'll find you a few hours a week to do it. Keep busy, keep engaged, keep happy. When you have something, we're going to look at how we can weave it into the whole system and give it to other interested groups." I think what this programmer at lunch was saying is really that she wants to work on something interesting that matters to the company. It all matters. But it doesn't all matter equally, otherwise there wouldn't be all that talk about line of sight. You get line of sight tossed at you enough times, and you know someone's drawing a line between what matters (at least this year) and what doesn't. And it's natural that now and then people want a nudge in a direction that gives them the confidence to know that what they're doing, even if it's incredibly exciting, is also useful in a way that will be appreciated for something other than mere aesthetics.

I think that's one of the reasons Google's 20% really matters. Innovation as a pure value matters at Google. Innovation is intrinsic. You don't have to work at imbuing it with an extra layer of meaning, and then work at verifying and validating that meaning with the corporate hierarchy to get personal value of your work. I'm jealous of that part of their culture. I really think everyone needs a few hours a week to innovate if they want them. 10-20% across the board - developers, architects, content, help desk. Real time to generate new ideas and do initial work on them rather than hoping that employees will come up with an epiphany on the job and dump it in some ideation system that draws a line between the initiator and the product. Static ideation systems are good for capturing the odd snippet. So are Notepad and Outlook. But they're for shit when you want to create a living, breathing, recursive innovation system. That system has to extend beyond the software.