TVShows
Great idea - how to get TV shows, not how to see a bunch of randomly named bittorrent files. Another “so obvious after I saw it” moment. http://tvshows.sourceforge.net/ (thanks to The Unofficial Apple Weblog www.tuaw.com/2007/04/1…)
Great idea - how to get TV shows, not how to see a bunch of randomly named bittorrent files. Another “so obvious after I saw it” moment. http://tvshows.sourceforge.net/ (thanks to The Unofficial Apple Weblog www.tuaw.com/2007/04/1…)
Nice tool, nice example of using Firefox as a platform, and nice example of how small ideas are proliferating:Firedoodle … is a Firefox Add-On that allows you to mark up any page as if it was projected onto a white board. You can download the plugin at Firedoodle.com and if you register an account, any highlights you created can be saved (and later shared). (kudos to Julie for this)
I love the start-up environment - in part because of what happens when we ‘drink the kool-aid’, but at the same time I also value ‘fail-it-fast’ pragmatism. I haven’t found an eloquent way to think about or express this conflict - until I randomly came across an interview with Scott Brave from Baynote Inc. on folksonomy.org (quoted below without permission): On the topic of discussion we had last week Scott regarding how do entrepreneurs draw the line between the “never give up†philosophy and “cut your losses short†philosophy, can you share your insights?
A great audio program on experiential computing (IT Conversations: Ramesh Jain - Experimental Computing) and Ramesh’s related blog (Ramesh Jain’s Blog » Blog Archive » Events and paradigms) gives me some inspiration to on two important points: Patterns in Oggidigaw - using the notion of events with their attributes of who, what, where (spatial), when (temporal) and how (causal) - as a type of data model for representing patterns. What’s beyond objects: the notion of object-orientation has some strong limitations, one of which is the representation of time.
Two beautiful interfaces: a time machine Etsy Time Machine and a shop by color as novel ways to navigate.
Some of the assumptions that drive shared information and the shared concepts that underly them: There exists cognitive patterns (also called processes, structures, templates, metaphorical structures, relationships, frames, cognitive models, etc.) that are repeatedly used across across a variety of contexts, i.e. disciplines, domains or fields. That there is no single body of knowledge that explicitly captures and specifies these patterns and their related contexts, and by implication there is no discipline which owns them.
Some ramblings on software development A useful perspective on software devleopment is as an ‘integrated discipline’, i.e. a perspective that recognizes that software development is actually composed of three domains: Business - this is the domain of the problem Technology People - all the people involved, e.g. development team, customers, users, support staff, marketing, product management, etc. Nothing here is new, e.g. Weinberg, Catalysis, Scrum, etc. all include some notion of these domains in their models.
With experience, I have come to realize that is not sufficient to gather a diverse group of people to solve problems, no more so than a pile of sticks is sufficient for a fire. In part, I think there is a “common language” missing that represents the shared patterns, processes, structures, templates, metaphorical structures, relationships, etc. across a variety of disciplines and domains. As with any language, agents are required to bring the language alive.
I think it’s pretty easy to convince ourselves that in many contexts, especially work, we are becoming more specialized, moving away from being generalists. As an evolutionary process, it allows us to better fill more niches. However, with this specialization, the complexity of communicating across contexts is increased. With a decrease in communication, the opportunities for leverage are similarly decreased. For as long as I remember, I’ve been convinced that the only way to solve the “really big problems” is with multi-disciplinary teams.
As I interpret it, the agile versus formal debate is generally treated as an either or question. For instance, in any given software development situation there may be an assessment that it would have worked better if only an agile approach was used or for a project like this, you must use a formal approach. Only rarely does there seem to be an advocate that suggests integrating aspects of both approaches.