Software Engineering

A very interesting article about software that may be able to compensate for processor hardware errors caught my attention a couple of days ago. The Tortola Project at the University of Virginia reinforces the logical similarity of hardware and software, but the project team's focus is not on a single logical layer or virtual machine; rather, the team emphasizes the symbiotic relationship between layers (in this case, virtual machine and hardware architecture).

The goal (my highly condensed assessment of the project based on the project's main Web page) is to provide a means for solving future problems, including correcting hardware errors like the early Pentium processor floating point error.

The Professor's blog today caught my attention, especially the statement about the lack of requirements: "There is constant change, constant failure, and no requirements. Nevertheless, it all works."

I must confess that I had a very traditional software upbringing--my first exposure to upper-level computer science courses included topics such as formal methods, Clear Case Software Engineering (almost pure, requirements-driven software engineering--a perfect dream), Program Verification and Validation (requirements tracing and testing), and an entire book on Software Requirements (specification, documentation, analysis). A part of me is infatuated with the thought of XP, but another, more influential part of me feels the need to have requirements--good requirements--documented before starting work on a solution for any software project.

I'll lose some sleep over this, but I'm sure that even with ULS Systems, some driving forces exist that we can interpret as requirements. I'll have to return to this topic, but it is very interesting.

I built a house yesterday (well, I helped put the roof on), and when I had a few moments to rest, I took in the details in each roof component that supported the architecture for this house. Trusses are typically spaced at a standard distance, 4' x 8' sheets of plywood (fiber board) come pre-marked on one side to match up with the standard spacing of trusses (and wall studs--same standard spacing) so you can nail through the plywood and actually hit the 2x4 on the other side, roofing "felt" comes pre-marked to provide overlap guide marks as well as shingle guide marks, and shingles come in standard sizes to work with the marked "felt".

There are a couple of significant differences between the components used for building a house and the components used for building software: 1) the house builders aren't buiding the components--the shingles exist, the wood comes pre-cut and marked in standard sizes, windows and doors come in standard sizes, etc.; and 2) houses aren't used to control external systems or to input information and output converted information. I should add that the walls for this house were pre-built to specifications by someone else (correction facility workshop, I think), so in that sense, the architecture of the house was important in building larger components (pre-fab walls) out of smaller components, but still, the standards for stud spacing, window height and wall height existed.

It may be quite a bit more difficult to find standardized construction components for software, as the number of components used to support software system architectures is significantly greater than the number of components used to support building architectures.