For most people, outside of the artisans who produce cinema, the experience of going to the movies is an escape. The act of sitting in a cavernous theater, listening to finely tuned audio, engrossing ourselves in a massive screen, the suspension of disbelief — it is all meant to immerse us in an experience that is not our own, to allow us to sit back and merely enjoy.
Whether comedy or drama, action or romance, cartoon or biopic, the movies offer us as much or as little entertainment and fulfillment as we choose. Perhaps it’s just the lights and colors and sounds that are enough. Incredible performances that lead you to forget your favorite thespian’s name as they embody an other. Or maybe it’s a few explosions. Some wonderful CGI, virtually indistinguishable from real life. Maybe it’s a finely woven story, or beautiful cinematography that transports us halfway around the world.
For the creative-minded, though, every frame is an opportunity to contemplate not only the story being told, but the telling of it as well. “How did they get this shot?” “How did they come up with this story angle?” “What a nuanced performance.”
Software is not too dissimilar. After the wonder and confusion of the learning curve subsides (and, it seems, each successive crop of digital natives seems to overcome the curve faster than the last), many of us go straight to autopilot. Users expect an application to “just work,” with little or no consideration of what is happening to make it work. It’s almost like an instinctive suspension of disbelief for what underlies software, a heuristic to help us handle the massive spike in stimuli humans have laden ourselves with this century.
Software artisans, however — like the engineers, product principals, and designers at Giant Machines — dedicate much of their lives to peeling back the layers to understand, and help define, just what it is that makes software “great.”
“Great software isn’t only about performing its intended functionality,” points out Emre Cumali, Senior Software Engineer at Giant Machines. “That’s just table stakes. What happens when software needs to evolve through user feedback and changes in business requirements? Will the application handle traffic spikes? Is the code implemented with flexibility and scalability in mind?”
Emre is tapping into the definition of greatness here. It isn’t just about delivering something great today. It’s about delivering something great with an eye on sustainability. One phenomenal season for a professional athlete typically isn’t enough to make it into their respective sport’s Hall of Fame. It takes surpassing the bar of greatness, and pulling it up with you.
When it comes to software, that means building Version 1 with future versions in mind. Sticking with the athlete analogy, that doesn’t mean hiding in the gym until you’re great. It means getting out there and honing your craft, day in, day out.
“Great software starts with an understanding of the pain points or use cases you’re trying to solve for,” continues Emre. Build a minimum viable product, deploy, get feedback, learn, iterate. “The way you get there isn’t by developing, developing, developing and releasing something you think is perfect. But you surely don’t get there by rushing through the development process and releasing a product that you need to rebuild and refactor just to release one new feature.”
Emre continues: “Over my years of building software and keeping up with recognized experts in the field, I have come to define quality software by the three characteristics it encompasses, framed up in three simple questions. The first layer — the easy one — is, ‘Does it work and behave as intended?’ Any software user can answer this question.”
The next two characteristics — the rest of the metaphorical iceberg, the bulk beneath the surface — define quality code from an engineering perspective. Can developers collaborate easily today? Can we refactor to accommodate functionality changes tomorrow?
“The second question to ask,” Emre shares, “is, ‘How easy is it to understand the code?’ Does it communicate itself to other engineers without having to resort to code comments or documentation?
“This can be achieved by writing clean, clear, self-documenting code. Are packages, classes, functions and variables named clearly and consistently? Can a collaborator hop in and understand your code and contribute quickly?”
// Returns the area of a rectangle with integer sides i1 and i2 passed to this methodpublic String myFunction (int i1, int i2){return i1*i2;}vspublic String calculateRectangeArea (int side1, int side2){int rectangleArea = side1 * side2;return rectangleArea;}
Here is a simple example to illustrate our point. If an engineer were to update the input parameters int i1 and int i2 to floating types, they may skip updating the comments above the method. By using explicit package, class, method, and variable names, they have written more transparent, self-documenting code, thus obviating the need to use comments to explain intent, and making the code easier to understand for a potential collaborator.
“Finally, ask, ‘How open is it to change?’ If I were to extend functionality, say by adding or removing a feature, do I need to modify several unrelated parts of the codebase, and risk breaking the application?”
Code that delivers the expected functionality is simply non-negotiable, but what happens when expectations shift? Users can be fickle. And even outside of this fickleness, requirements and habits can change. Through agile development, your application evolves naturally through feedback received by successive releases.
Perhaps this is where cinema and software diverge irreconcilably. Where a piece of software is a living, evolving thing, a film is a static artifact. We may increase our understanding of the context, and the film in question may or may not age well. But it is not designed to be modified incrementally over time — remade, perhaps, but the work remains a signpost of a point in time. On the other hand, the artisans who craft great code and memorable user experiences have both the ability and the implicit permission to improve their work over time — meeting, and at times helping to redefine, the user’s expectations.
Sounds pretty good to us.
