Product releases are evil. They kill innovation with a release schedule. If we could only keep writing code and never have to worry about releases… wait, that’s the Agile promise, isn’t it? Adding Agile disciplines helps, but there are still features that need a good chunk of development time along with product review, refinements and quality assurance. And even in an Agile environment, creating unplanned features is frowned on and is even case for dismissal at times, and reasonably so! Yet its these features that are sometimes ultimately the best features of the product– or some of the best products of a company. So what’s a developer to do? Here’s a little recipe for innovation that I’ve found works quite well.
1. Use the product you’re working on. Religiuosly. Make it a part of your life. If not, then maybe you should find something else to work on. This might not aply to everyone, especialy consultants, but if you’re not using it find someone who does who can give you feedback through the process. I first heard this at Microsoft where we set up a dogfood server for the intranet product I was working on in the early stages, well before beta timeframes (and even before the project was a product). (The term "dogfood server" comes from the phrase "eating your own dog food". Hopefully your applications are a bit more pleasant than eating dogfood… and this will ensure they are.) Set up a dogfood server and use it religiously, and make sure it has the latest installable version running on it– don’t wait for the stable production release. If this isn’t practical, or you don’t have the resources– use your development environment’s build as a dogfod server. (How do I read feeds? I use my dev envioronment of NewsGator Enterprise Server, which means that at my volume of feed consumption I very quickly started adding features to make this experience optimal.
2. Publish an API. Particularly, a Web Service API. And document the heck out of it– in the product. Microsoft SharePoint technologies is a great example of this. Then write your own user interface for the product that’s off the grid. There are plenty of additional interfaces you can write for your typical business application– SharePoint Web Parts, a rich client, a Yahoo or Windows Live Widget, Windows desktop components, alternate web user interfaces… there’s plenty of places for your application to be pervasive. Should a user have to go to the published web application to use your product– or should your product be part of their experience everywhere on the intranet? (For a great example of this, see my post on NewsGator in the intranet). Atlas technology really makes this easy– I’m doing a session at the Denver .NET User Group on Atlas technology, and I’ll be programming against published APIs of NewsGator Enterprise. (If you’re in town, here’s a link to add it to Outlook.)
3. Keep your day job. If you get off target with your required product features there’s no way your innovations will have any audience with your product managers. And don’t be a rogue developer– innovation doesn’t mean that you forget about your team and do your own thing.
There are just a few things– of course, the right environment is crucial– so find that environment where you can make a difference. Maybe it’s consulting. Maybe it’s on a product team. Or maybe it’s your own company. Find that place and you’ll have a great career.
What are your experiences as a developer? Do you only write code for your customers, or are you one of your own customers?
Advertisement
