Posts Tagged ‘philosophy’

Writing, Scholarship, and Software

May 22, 2010

My Google I/O travelling companion was Brian McNely, professor of Rhetoric and Writing in the English Department at Ball State. He told me a bit about his personal daily scholarly regiment: he reads at least 50 pages a day and writes at least 750 words, the latter supported by I respect this endeavor, knowing how, as a professional academic in a university, there are other forces that can drain the time and focus that should be devoted to academic pursuits. Brian clearly enjoys his scholarship, even when he has to make sacrifices to meet his goals.

This made me think about my own scholarship and personal goals. There is a great contrast between my feelings between Fall and Spring of the last academic year. In Fall, I felt productive and I also felt that I was learning. In much of the Spring, I was frustrated. (Interestingly, as I look back at the past semester’s writing to pull out those links, there is more positive ideas there than I remembered there being. That’s encouraging. I suppose I need to spend more time reading my own blog.) One of the major differences between the two semesters was that in the Fall, I was inventing: working on Confluence was a great experience, as I’ve said before. I know that I love the process of inventing software systems, and so I have been actively seeking out opportunities to leverage this as both personal fulfillment and scholarship. This Summer, in fact, my time should be nicely split between some interesting Wave and game projects. I embrace Boyer’s model of scholarship, and pertinent here is the scholarship of application.

When I try to tie these ideas together with Brian’s 50/750 regiment, I hit a contradiction. Clearly, as a professional scholar, I could just adopt 50/750 myself, and this would undoubtedly improve my scholarship. However, I would also like to have time for invention, for creating software. Unfortunately, you cannot measure productivity in software, so how does one set personal goals for invention?

Last semester, I set aside time Friday afternoons for writing on this blog, and I am happy with the results. I feel like I have been able to crystallize several concepts by writing them, and it has given me an outlet to explore and ripen new ideas. There were only a few times in the semester that I was unable to set time aside. However, even in reflecting on this writing, it was done in relatively small spurts of about an hour. That is, it was done in what Paul Graham calls the manager’s schedule. I know, from years of development experience and many semesters of frustration, that if I want to successfully build a system, I need to do it on the maker’s schedule. (Incidentally, adopting inbox zero has significantly improved my ability to occasionally adopt the maker’s schedule during the academic year.)

I don’t have a plan, then, for how to deal with this contradiction of wanting measurable goals for something that brilliant designers call unmeasurable. I have developed some experience using Scrum and MSF in leading teams, and I could always adopt these for myself, except that I am not sure that “maintain development momentum” or “mitigate one high-impact risk” are goals that I can meet. One one hand, these managerial techniques were designed for teams, and on the other, neither really is a measurement of productivity. Of these two, the idea of measuring momentum via Scrum or similar techniques is somewhat appealing, partially because it could hone my capacity for estimating time requirements, and in the end, time may be the only invariant I can use to commit to invention.

No conclusions, but I’m open to ideas.


Ontological argument for the existence of software

April 3, 2010

I gave a talk two weeks ago in a seminar on design thinking and innovation. As I was preparing for the talk—not knowing exactly what to talk about, but knowing that it should relate design thinking and software—I got to thinking about what software is. It is intangible but has behavior. It must exist, then, but it cannot be sensed. We can interact with bits and pieces of representations of it, but I contend that none of these are the software, not in toto.

This led to me to define the ontological argument for the existence of software, with apologies to Anselm of Canterbury:

Software designed is software created.

Put another way, software that has been designed with sufficient specificity so as to be implemented has already been implemented, modulo syntactic transformation. This is intentionally stated as a material conditional, implying that software can exist which has not been designed, but software designed cannot non-exist.

For example, consider the design of a software system. If this design cannot be implemented, then there is an omission, and therefore there exists a design which is more rigorously specified. For any hypothetical software system, then, there exists “a design than which a greater cannot be designed.” In creating the design, one has created the software: the executable model, the mathematics over time.

(What about the defects, you ask? They are baked right in. I never said that we are good at design!)

One of the seminar participants suggested that this makes software similar to an argument, which exists in the mind and can be represented on paper, but the representation is not the argument. This is a keen insight on the nature of intangibles, but it misses the point that software is an executable model. I was presenting primarily to young architects who are comfortable with static models, which clearly exist, even if one argues that the idea of the model is distinct from the physical manifestation of it. I understand that there is a shift in architects towards parametric models, and the relationship of these creations to the software development process is one that merits investigation.

Design Thinking and the Ephemerality of Software

March 16, 2010

I recently read Richard Buchanan’s Wicked Problems in Design Thinking (Design Issues, Vol 8, No 2, 1992, pp5-21) on the recommendation of my esteemed colleague Mahesh Senagala. The article frames design as a liberal art, partially drawing on design as an approach to wicked problems. The arguments for the inclusion of design thinking as an necessary liberal art are compelling, but I was already in that camp before reading the article. What I found more interesting about this paper from 1992 was the omission of software design as a design category.

Buchanan categorizes the areas explored by design into four areas, and the terms and examples are his:

  1. symbolic and visual communications: graphic design, typography, advertising, book and magazine production, scientific illustration, photography, film, television, and computer display
  2. material objects: form and visual appearance of everyday products as well as the “physical, psychological, social, and cultural relationships between products and human beings.”
  3. activities and organized services: logistics, decision making, strategic planning
  4. complex systems or environments for living: systems engineering, architecture, urban planning

The author uses the shortened phrase “signs, things, actions, and thought” to refer to these four areas impacted by design thinking. It is worth noting that the author acknowledges that these are not separate fields of study, and that any significant design exercise will incorporate all four.

In the article, there is no treatment of software design, despite the fact that it had been studied within the Computer Science and Software Engineering disciplines for decades prior to this article’s publication. I scribbled a few notes in the margins, wondering if the author meant to include software design as part of systems engineering, since he does not extrapolate. (It’s also worth noting that Buchanan addresses the inherent problem in the word “design,” that different people use it to mean different things. Here, I am talking about the “internal” design of software—how it works—not interaction or interface design.)

I posit that software design is significantly different from all other manifestations of design because when software has been fully designed, it exists. A significant corollary is that when software exists, it has been designed. Flaws in software implementation are evidence of errors (of commission or of omission) in its design. Recognizing the intangibility of software leads to its ephemerality, characteristic of modern continuous integration systems. An “instance” of software—a build—may only exist for milliseconds. Even if software design then is included in Buchanan’s characterization of system design, it is substantially different from architecture.

(I noticed that my argument echoes in software Anselm’s ontological argument for the existence of God. I don’t know if it’s a coincidence. Also, it reminds me again that “software architecture” is a misleading term, since software design is characteristically different than traditional architecture.)

I would be interested to know if the science of design literature contains subsequent work to Buchanan’s, and whether philosophies of design include “design of the intangible and ephemeral” within their ontologies.