Mostrando entradas con la etiqueta architecture. Mostrar todas las entradas
Mostrando entradas con la etiqueta architecture. Mostrar todas las entradas

miércoles, 23 de julio de 2008

The physics of software.

Rosenberg brings up yet another interesting point when it comes to software development:
" 'Software engineering' is something of an oxymoron," L. Peter Deutsch, a software veteran who worked at the fabled Xerox Palo Alto Research Center in the seventies and eighties, has said. "It's very difficult to have real engineering before you have physics, and there isn't anything even close to a physics for software."

(Rosenberg: p. 276)

However, is it even possible to find out the "physics of software"? Is there one? The natural answer to that question is that, obviously, there is none. Software doesn't have a physical existence of any type whatsoever. It only exists in the form of bits and code and, prior to that, in a programmer's mind or, at the very best, some well documented specs. In that case, we could assume that Deutsch is right on the money: there is (and there will never be) any true software engineering discipline. And yet, is Deutsch's premise correct? Is it true that only physical things can be "engineered"? I suppose it all depends on the approach one takes to the issue. If we start from a mechanistic point of view, the assumption that only something physical can be engineered appears to be true. However, if we take a more systemic approach, it would appear as if everything is information, bits that flow around and can be channeled in one form or another. If his latter vision were true, then the problem is not so much that software engineering would be impossible but rather that we'd have to modify our own concept of what engineering means.

viernes, 18 de julio de 2008

Vitruvius applied to software design.

Inspiration can truly come from anywhere, but when it comes to software design it is clear that there is a connection between it and architecture, as Kapor noted:
Software design, Kapor argued, was not simply a matter of hanging attractive graphics atop the programmer's code. It was the fundamental creative act of imagining the user's needs and devising structures in software to fulfill those needs. As the architect draws up blueprints for the construction team, so the software designer should create the floor plans and elevation views from which software engineers would work. Reaching back to ancient Rome, Kapor proposed applying to software the architecture theorist Vitruvius' principles of good design: firmness —sound structure, no bugs; commodity —"A program should be suitable for the purposes for which it was intended"; delight —"The experience of using the program should be a pleasurable one".

(Rosenberg: p. 149)

The terms may sound outdated, but the idea truly still applies: a well designed software should be solid and consistent, able to meet the requirements and a joy to use. Apple's designers have always put this advice to good use.