Archive for June, 2010

Architecture and Systems

June 28, 2010

Friday’s TechNews highlighted some work being done at the University of Leicester by saying:

The University of Leicester’s Farah Lakhani is studying how techniques from architecture could be used in the development of software for embedded processors, which have grown in complexity. Lakhani says the designs of buildings and control systems share commonalities. “Architects must couple knowledge of engineering–for example what type of steel girder is required to support a floor–with human-centered design, i.e. what makes a building a good place to live or work,” she says. Lakhani says that similar concerns should be a focus of developers of embedded systems, and her current research focuses on “how techniques called ‘design patterns’ from the field of architecture can be used by developers of reliable embedded systems.”

It is quite obvious that we can learn from architects — and not just for embedded systems. In fact, the object oriented movement has highlighted the work of Alexander. His views of “a property without a name” drive my doctoral students crazy until they “get it.” While the field has gone on to document many patterns for design, they have been less likely to document the patterns for analysis. In fact, my reading of Alexander is that he believes patterns for analysis are more important than those for design. Specifically, knowing what kinds of issues need documentation for specific kinds of problems, what kinds of stakeholders probably exist in what kinds of situations, and where problems tend to appear for certain kinds of problems would be most helpful for novices in analysis. Accounting systems differ from personnel systems — there should be help for the novices to know how to approach them. Further, many of the failures of systems can be tracked back to bad analysis (not understanding the problem, not communicating, etc.) than to design. Thus, patterns in analysis would be more critical. Of course, the reason they don’t exist is that it is much harder to define analysis patterns than design patterns. I wonder how we would start?

Advertisements

Kindergarten Engineering

June 16, 2010

An article in the NY Times today discussed a new movement to teach engineering to primary students. According to the article,

Supporters say that engineering reinforces math and science skills, promotes critical thinking and creativity, and teaches students not to be afraid of taking intellectual risks.

Clearly, my next step was to check out the available modules; I was disappointed to find there were no modules addressing information technology. It was an interesting set of topics, though, set in different contexts and different countries. I looked at the industrial engineering module (I do, after all, have a BSIE). The module introduced the topic of how machines make work easier, a traditional topic in IE. The materials include a children’s book (which chronicles two young girls’ trip to the potato chip factory where they learn how machines make work safer), a teacher’s manual, a DVD with vignettes about machines and a set of materials. Not a bad collection.

So, on and off today I have been thinking about what activity could be developed to help young children appreciate programming or other aspects of technology. I thought about creating a “human computer” where only some children could compute and others could write on the board and others carried messages, etc. Would that help them understand it? What kind of book would go along with that topic?

Then I thought about having them explain precise instructions of how to do something. The tasks in the program, according to the teachers interviewed, were to teach the children to “take students step by step through the engineering process: design, build, test, evaluate.” Well, those are good things to learn. But, how to apply them to information technology?

I still don’t have an answer, but I do have a question. Does anyone else have an answer?