How would you classify writing software? Is it science (as in computer science), a form of art (as in code is poetry or prose) or an engineering discipline? Terence Parr, a professor of computer science at the University of San Francisco, recently wrote about why writing software is not like engineering. Terence concludes that writing software is more an art than an engineering discipline:
Writing software is most similar to writing fiction novels. Writing novels is also an act of creation in an unconstrained and ethereal medium with few well-established construction rules.
I find this notion to be a fallacy, because writing software can be looked as a form of art, but it is largely driven by engineering. Programming can be called a craft or an art-form, but the software itself is not. My biggest argument in this context is regarding automation. Engineering primarily promotes automation of tasks. Most software is written to automate manual or semi-manual processes and enforce computational validations. However, we cannot automate art. A painting won’t automatically self-render itself into a 3D landscape. Nor would the premise of a fiction novel evolve or extend on its own, like refactored source code or OOP libraries can allow for in software.
It has become quite clear in the software world that a big design up-front doesn’t work. Engineering can solve this problem through iterative design and development. Art, on the other hand, cannot be progressive by its very nature. The final result of art is static, albeit beautiful or enjoyable.
Recently I heard Neal Ford talk about Emergent Design during a brown bag session at work. Neal is an author, a speaker and a Software Architect at ThoughtWorks. In his talk, Neal questioned the nature of code? What is software code? I think it’s a subtle yet very important construct in the understanding of software engineering.
A conventional engineer’s output, be it mechanical, aeronautical or any other branch, is the design or the blueprint. The engineer provides the very basis of objects architecture and its inner-workings. But what is the output of a software engineer? Yes, our lot designs architectures too and we also document the inner-workings (as much as some of us hate to). But the primary output of a software engineer is — the code. Hence, software code is the core output of a type of engineering, not a type of art.
To further draw the “art of engineering”, I’ll leave you with an interesting anecdote to ponder on:
Warning! If you still enjoy playing PacMan, don’t read the next paragraphs—they will ruin it forever for you. Sometimes knowledge comes with a price.
Consider the PacMan console game. When it came out in the 1970s, it had less computational ability than a cheap cell phone of today. Yet, it had to solve a really difficult math problem: how do you get the ghosts to chase PacMan through the maze? That is to say: what is the shortest distance to a moving target through a maze? That’s a big problem, especially if you have very little memory or processor power to work with. So the developers of PacMan didn’t solve that problem, they used the anti-object approach and built the intelligence into the maze itself.
The maze in PacMan acts like an automata (like in Conway’s Game of Life). Each cell has simple rules associated with it, and the cells executed one at a time, starting at the upper left and proceeding to the lower right. Each cell remembers a value of “PacMan smell.” When PacMan sits on a cell, it has maximum PacMan smell. If he had just vacated the cell, it has maximum PacMan smell –1. The smell degrades for a few more turns, then disappears. The ghosts can then be dumb: they just sniff for PacMan smell, and any time they encounter it, they go to the cell that has a stronger smell.
The “obvious” solution to the problem builds intelligence into the ghosts. Yet, the much simpler solution builds the intelligence into the maze. That is the anti-object approach: flip the computational foreground and background. Don’t fall into the trap of thinking that “traditional” modeling is always the correct solution. Perhaps a particular problem is more easily solved in another language entirely.
I’ve been reading a lot about “Augmented Reality” lately. Just the other day, I saw this beautiful short film titled ‘World Builder‘, that also depicts this powerful holographic technology to express the fusion of the physical and virtual worlds.
Augmented Reality (AR) is basically the combination of real-world video imagery and computer-generated data (virtual reality), where computer graphics objects are blended into real footage in real time. The GE Smart Grid demo uses AR (must watch the video). It’s a fascinating technology, and I think it has a lot of potential in the consumer space as well.
Some startups (like Layar and Wikitude) are already developing AR geo-interfaces (GPS based) for mobile phones, which would allow anyone to simply point their phone camera in open space (say a market-place in a new city you are in), and get a location-based interactive perspective (say the landmarks, ATM’s, or pubs near you) through dynamic recognition.
Zugara’s Augmented Reality & Motion Capture Shopping Application (demo video) is also a neat example of things to come.
Nokia has also been building this technology on more than a decade of academic research into mobile AR. Nokia researchers have been working on real-time image-recognition algorithms as well; they hope the algorithms will eliminate the need for location sensors and improve their system’s accuracy and reliability.
One day, in the genuinely not so distant future we will live in two worlds; reality and augmented, neatly combined into one.
At PDC 2008, Microsoft gave the first public demonstration of Windows 7, its next generation operating system.
I’ve been following the state of engineering behind Windows 7 for a while, both architecturally and UI, and after looking at the simplistic look, I hope it delivers a more secure, more stable, and less fussy OS.
Today, most of what we use the Web for on a daily basis aren’t just web pages, they are “applications”. These applications, which run inside our Web browsers, are increasingly becoming more advanced in their functionality and more interactive in their usability.
The Web browser acts as the core container for these applications, and it is critical to any Web application in terms of security, stability, speed, and operability. In the Web browsers space, the much speculated launch of a new browser from Google, called Chrome, marks a very important step in “remaking” the Web. I’m overwhelmed with what Google Chrome offers as a product, and excited too, because this will open up doors to even more advancements in the Web application space.
So, what’s so special about Google Chrome, that’s not already there in existing (and time-tested) Web browsers like Firefox, IE, Opera, Safari etc. I downloaded Chrome (it is open source) and played around with it for a bit, and let me put it this way – Google Chrome is not about what’s there, but about what’s not there. For the Google team, the mantra became “Content, not chrome,” which is sort of weird given the name of the browser. It’s incredible that something as potentially game-changing as a Google browser has stayed under wraps for two years.
With Chrome, the Google team has really worked on two most crucial aspects in any piece of computing software: simplicity, and speed. The interface is darn simple, a true minimal design, and streamlined for power usage as well. In terms of speed, Chrome outperforms any modern Web browser. See, today’s Web applications are powered by client-side scripting and asynchronous client-server operations, all utilizing the JavaScript engine (pretty much). Scripting engine performance benchmarks have indicated that Chrome is at least 10 times faster than Firefox and Safari, and a staggering 50+ times faster than Internet Explorer. Chrome’s V8 scripting engine (written by a small team in Denmark) actually complies the JavaScript code to machine code for faster execution. Moreover, every tab or window in Chrome runs isolated (sandboxed) in its own process (not thread), which means that even if a web page crashes, the rest of the web pages in view are not affected. Chrome is secure too. It is based on the Webkit rendering engine, which powers Apple’s Safari browser.
Google amazes me. I sit here and wonder, isn’t this how it all should have been in the first place. Having looked at Chrome for just a few hours, I can easily say that even in its infancy, it is the most promising Web browser aimed towards the future of Web applications.
Automated email-based password reestablishment (EBPR) is an efficient, cost-effective means to deal with forgotten passwords. Simple Authentication for the Web (SAW) [pdf] improves upon this basic approach to user authentication to create an alternative to password-based logins.
Consider the PacMan console game. When it came out in the 1970s, it had less computational ability than a cheap cell phone of today. Yet, it had to solve a really difficult math problem: how do you get the ghosts to chase PacMan through the maze? That is to say: what is the shortest distance to a moving target through a maze? That’s a big problem, especially if you have very little memory or processor power to work with. So the developers of PacMan didn’t solve that problem, they used the anti-object approach and built the intelligence into the maze itself.
