Today I read one of the best blog posts I have read in a while. I could relate to it as a consumer, as a wannabe programmer, but perhaps most importantly as someone who enjoyed product management. Paul Buchheit has lots of experience developing applications that touch a lot of people, from gmail to FriendFeed, but he really drives home some wonderful points in Communicating with Code
The point that comes across strongly, and one I can relate to, is the point that a lot of features seemed like great ideas until they were tried. That was only possible cause they always had live code. In my experience with software development projects, “users” always got to play with the app too late in the dev cycle, at a time when major changes were not really possible, and all you could do, and were trying to do was to fix bugs. That was always frustrating as was the whole process of writing specs. How do you really know how something is supposed to work? This iterative, live code process is not that common in the life science software business, even those that have agile processes in place, and I’d encourage software developers, indie and in companies to take a good look if this works for them. I know many you are afraid to put code out cause they think it’s half baked. Perhaps that’s the best time to do it.
It’s also probably why one does not really see innovation in user interaction paradigms or collaboration tools in life science software, especially a lot of commercial software. Too much development on specs developed from querying a sample of your prospective users. That process can work, and I’ve been part of the process when it has, but it would be good to see what happen.
The second point he makes is about APIs. Anyone who has read this blog for any length of time knows I love the idea of a public API. The following lines sum up why
Public APIs enable everyone to experiment with new ideas and create new ways of using your product. This is incredibly powerful because no matter how brilliant you and your coworkers are, there are always going to be smarter people outside of your company.
This is true at so many levels. It’s fascinating to make an API available and see what people do with it, how they use it. Leads to better community, a better experience and more innovation. That Paul then decides to share some ideas by making code available, built on the FriendFeed API, is just gravy.
I’ve always loved product development. It would be fun to take some of the things that I’ve learnt in recent years, some of which are encapsulated in Paul’s blog post, and go back into that kind of role and try and see if some of those paradigms will work for life science software, both from the innovation and usefulness perspective and from the commercial side.
Living software
Today I read one of the best blog posts I have read in a while. I could relate to it as a consumer, as a wannabe programmer, but perhaps most importantly as someone who enjoyed product management. Paul Buchheit has lots of experience developing applications that touch a lot of people, from gmail to FriendFeed, but he really drives home some wonderful points in Communicating with Code
The point that comes across strongly, and one I can relate to, is the point that a lot of features seemed like great ideas until they were tried. That was only possible cause they always had live code. In my experience with software development projects, “users” always got to play with the app too late in the dev cycle, at a time when major changes were not really possible, and all you could do, and were trying to do was to fix bugs. That was always frustrating as was the whole process of writing specs. How do you really know how something is supposed to work? This iterative, live code process is not that common in the life science software business, even those that have agile processes in place, and I’d encourage software developers, indie and in companies to take a good look if this works for them. I know many you are afraid to put code out cause they think it’s half baked. Perhaps that’s the best time to do it.
It’s also probably why one does not really see innovation in user interaction paradigms or collaboration tools in life science software, especially a lot of commercial software. Too much development on specs developed from querying a sample of your prospective users. That process can work, and I’ve been part of the process when it has, but it would be good to see what happen.
The second point he makes is about APIs. Anyone who has read this blog for any length of time knows I love the idea of a public API. The following lines sum up why
This is true at so many levels. It’s fascinating to make an API available and see what people do with it, how they use it. Leads to better community, a better experience and more innovation. That Paul then decides to share some ideas by making code available, built on the FriendFeed API, is just gravy.
I’ve always loved product development. It would be fun to take some of the things that I’ve learnt in recent years, some of which are encapsulated in Paul’s blog post, and go back into that kind of role and try and see if some of those paradigms will work for life science software, both from the innovation and usefulness perspective and from the commercial side.
Related articles by Zemanta