What does software look like?on Oct 20, 2010 in Coding by Jonathan Paul
As software engineers we work with substance which can neither be seen, smelt, touched, heard nor tasted. One might argue that we “see” the code, but in reality, our source code is no more than the instructions that we give for something to be built; we see the blueprints, but not the house.
A Google Tech Talk by James Whitaker on The Future of Testing brought up the topic of adding visualisations to software, saying that we need code to become visual for us to be able us it effectively and some people here at Caplin were somewhat unimpressed with his assertion.
Now there are definitely some people who agree with Whitaker. Hollywood understands that people love visuals. When the elite hacker is breaking into the CIA mainframe, a fantastical scene unfolds before your eyes, perhaps with lasers and gigantic “Access Denied” messages. It’s a great plot device, the layman can understand the tension of what the black hat is doing and the computer programmers can make fun about how ridiculous it all is.
While I agree that most movies prefer the fiction part of science-fiction, I don’t believe this means that they don’t have the right idea. Humans, software engineers included, are visual creatures. We prefer graphs, not tables. We like green/red lights, not reading test logs. We draw class diagrams, not print out class definitions.
Yet when it comes to try and push a visual interface onto our code more directly, there appears to be an immediate reaction that “it would never work in real life”.
But why is this so ridiculous? After all, if a console application can have a GUI interface, why can’t our source code have a visual augmentations? Architects started to manipulate their designs through renderings as soon as the technology became available and yet we still insist on writing things at the most basic levels.
Is it so ridiculous to have a 3D rendering of how our classes interact with each other? Perhaps a line diagram showing how data flows through our application? How about a color coded background to indicate the complexity of certain methods and classes? What about a heat map showing which classes and methods have had the most bug fixes?
As code grows ever more complex it is going to become more and more important for our code to become as visual as our daily lives. While we will never be able to get away from writing our code in files, it is ridiculous that in 2010, after all the advancements in our technology and profession, we are writing our code in much the same way that we did in the 1980′s.