RPI has had over the years several chat systems, culminating in the latest - a thing called lily. It’s in many ways superior to various other systems like IRC since it has mechanisms for persistence built into it, as well as a certain small amount of accountability. Lately, I’ve been working on a lily client of my own - waterlily. It’s highlighting a difference in my “hobbyist” programming from my “professional” programming.
At work, I’m in a frameworks group. We make all the stuff that people use to build applications on. This includes all the UI elements as well as collections and networking things. What we concentrate on there is correctness and performance. The attention to detail tends toward constant examination of code for memory leaks, algorithm efficiency, and expandability of the API. It’s programming, but at a much smaller-grained level. Each of us is (or becomes) an expert in our assigned components, and we frequently get experience in other components when someone takes sick, or is on vacation, or assigned to other work.
An application like waterlily, on the other hand, is more “macroscopic” - modulo serious performance issues what the application does is more important than how it does it. So the fact that it might take a few extra cycles to log in to the chat system is far less important than the experience of doing so - and features start to turn into the driving force.
Features at the framework level tend to be things like “provide API for some underlying system service.” The API should be easy to use and scalable so when application developers start abusing, er, using it, the whole thing doesn’t fall over under its own weight. Features in a framework generally aren’t visible to mom and dad when they sit down at the computer for a quick session with eBay or writing email to ask you why their computer won’t print. They’re combined by application authors to make things like auction-watching systems or RSS news readers.
Features for an application tend to be comparatively large things: for a web browser, automatically filling out forms is a feature. Depending on the implementation, it probably relies on a number of things in the frameworks. The key thing though is that for an application, features are extremely user visible things. When the user discovers that the application doesn’t do something, that will turn into a feature request. For an application, a feature is something the user is going to interact with on a regular basis. It’s a reason for the user to use your application rather than someone else’s.
Looking at this difference has me appreciating the applications developers more. I wonder, though, how many applications developers seriously think about framework development. Many of the people I work with in frameworks write their own applications, and are informed in their out-of-band application development about how their frameworks should work. I’m not sure how many applications developers work on their own frameworks. The first group that springs to mind is the subversion team, since they’re working on both clients and servers as well as the underlying libraries for them. I know that on the subversion development mailing list many times API is considered and one of the frequent questions is “Where should this function go?” as well as “Is this something everyone’s going to want to do, because if it is, it should be part of the library.”
Comments? Anyone? Bueller? Bueller?