Zax Bambala: Understanding Quality Attributes

What makes software good?  Is there any simple metric by which Rational ClearCase is technically atrocious, or is the concept more amorphous than that?  Are timeless indicators of quality, or is quality simply determined by the technological background of a specific era?

To probe deeper into these questions, I interview Zax Bambala, co-founder and Chief Designer of the wildly successful webware firm Locatorium.  Over the course of 5 years from 2024 to 2029 they emerged nowhere with promises of "never lose an object again", becoming the foremost leaders in the (inaccurately titled) atom-tagging business.  Customers simply installed an air freshener in their home, which slowly released dust-like micro-bio-RFID chips, eventually coating all their belongings in uniquely-identifiable electric chips, enabling them to be found by computer.

Kurt: Mr. Bambala, it's a pleasure to have you here.  I'm sure many of our readers are extremely curious as to the background of Locatorium.
Bambala: Always a pleasure to talk to the past, do some good.  Locatorium has humble beginnings.  One week, I lost my key-tags on three separate occasions, costing me hours, and I just thought "there has to be a better way".  So I talked to some friends working in nanotech, we figured a way to identify it all, they built some air fresheners, I wrote some software, people liked it, IPO, and now I'm here.
Kurt: Very inspirational.  So such a system as yours must incur strenuous demands: heavy security concerns, high information bandwidth to process.
Bambala: Oh, most certainly.
Kurt: So, how did you design a system capable of handling all those requirements?
Bambala: What do you mean?
Kurt: I mean, how did you make your software secure and flexible and always available?  How did you cope with the computational demands of ever-expanding user-base?
Bambala: Well, we rented out more virtual servers... I'm not totally sure what you're asking.
Kurt: Well... when you started this project, what was the first thing you did on the software side?
Bambala: Oh, well we sketched up the user interface, and defined the data the system would need.  Compiled, tested, solicited feedback, redesigned, compiled, tested, and so on, just like any software project.
Kurt: There seems a rather large step missing there... I mean what is the central architecture of your system?
Bambala: The framework?  Oh, we just used Q# Rails.
Kurt: And the performance and--
Bambala: Look.  I learned a little about security and performance and all these words you keep throwing around in college, but honestly, I never touch any of that stuff.  That's defined by the framework.  I'm not really a software engineer, I'm a software designer.  Userware, you know.
Kurt: So, you didn't write any communication code at all?  You didn't designate modules and diagram out interactions at all?
Bambala: I told you already: I defined the data and UI and compiled.
Kurt: Surely you at least picked the operating system it was all running on?
Bambala: Again, another one of those college words.  We should have done this interview 12 years ago.  [He laughs].
Kurt: So, if these quality metrics don't define the quality of your software... what does?
Bambala: A good idea, a good user interface, good service, effective communication with users.  You want to know all that low-level architecture stuff, talk to a company like Microsoft.  I'm here to create a vision, not to fiddle with electrons.
Kurt: Very insightful, Mr. Bambala.  Thanks again for your time.  Are there any parting words you have to offer the people of the past?
Bambala: I suppose one thing: If you register Locatorium.com before me, it wouldn't be hard for me to find you.  I'm here to encourage the field, not to sell myself out.

I was initially taken aback by his responses.  What self-respecting programmer ignores topics so large?  I spend so much time complaining about poorly-designed systems that I've come to regard negligence in these manners as unexcusable.

But then I realized: when was the last time I worried about the compiler I was using?  When was the last time I doubted the stability of my kernel, or had to tune the performance of my DBMS?  When was the last time I wrote my own networking code instead of using a library?

These tasks are relegated to a different kind of programmer now.  They are stable and effective.  Is it possible that most of the work I currently regard as the tasks and concerns of a programmer are solvable, packagable problems?

Security concerns are mostly the same on all systems.  Performance concerns are often addressed in the same ways.  Even the basic modular structure of a system is highly consistent across a variety of programs.  One need only look at the Ruby on Rails project to see the level of uniformity across widely ranging systems.

Business software can often suffer from quality problems, perhaps because quality is not their concern.  Just as most businesses have no interest in writing programming languages or IDEs, and thusly consider it a solved problem-- perhaps most businesses have no interest in writing quality software because they don't want it to be a concern.  It's hard to distinguish yourself by quality; it's something that should be given.

20 years from now, people are still modifying g++ (I've checked).  Some minority of "low-level" coders will be programming frameworks in "low-level" languages like Java and C#.  The majority of work programmers want to do is in the realm of functionality, and due to the reusable nature of software, it seems reasonable to assume that the majority of work programmers will do is in the realm of functionality.

Better start learning to diagram now.  Today's design patterns are tomorrow's assembly language.