Flutterby™! : the future of product 2007-02-09 19:18:50.472756+00

the future of product

2007-02-09 19:18:50.472756+00 by Dan Lyke 1 comments

Got together with a friend this morning. Those of you who can read between the lines will probably figure out details, but I want to talk about this in abstractions for a moment. A lot of the discussion was about software process, and one of the things we talked about was why a particular monolithic and very popular application in his problem space wasn't appropriate to the tasks he had to deal with.

And the problem was that it was monolithic. A project existed in a single file that this application opened. There was no good way to do simultaneous development on that project, because that one app had that resource locked up.

He likened it to building a subdivision where each person goes to an address and builds a house, rather than having the foundation people go from location to location pouring concrete, to be followed by the framers, then the roofers and the interior folks can work simultaneously, meanwhile the foundation folks are on the third or fourth lot working on that problem.

I've also been musing recently about the trade-off between one-size-fits-all product, and custom parts, and how customization reduces value in general even while it increases value to a particular person.

So the room in product development, be that software or hardware, is in modularizing so that interoperability works better. I believe that consumers are finally waking up to the notion that lock-in removes value, and I think that this is one of the reasons that so much interesting software development these days is happening in web browsers, because those are a tremendously flexible environment.

Need to clarify these thoughts a bit, because most likely your response to this entry is "duh", and that it's either a set of obvious or stupid realizations, but I think that the next big layer of opportunity involves finding ways to scale customization, to undo some of the mass sameness that the assembly line and the industrial revolution imposed upon us and rework products into vertical slices that allow more personalization.

In my own programming, I've found that writing tons of functions that all do one thing works well (they're typically small, but not always). Also, the abilty to break out the steps and make them available via an API is good as well (one example: I have a C routine I wrote call HttpOpen() that returns a readable stream for a URL. It in turn, calls HttpConnect(), which does the actual network connection and initial request, but HttpConnect() does not follow redirects, whereas HttpOpen() does).

While I like to denigrate Microsoft (and frankly, who doesn't?) they do do some interesting stuff, like COM, where you can treat an application like IE or Microsoft Word as a library. That's a very cool concept that at times I wish more systems supported (imagine the ability to use grep or find as a library instead of a separate process).

I think the thing is to make such a rich API or library that the main application is nothing more than a thin layer of glue, and that the end user has the ability to rewrite or rework the main application (perhaps through a scripting language).