Our industry is more than 50 years old and still trying to understand some fundamental questions. There have been many analogies and practices to describe how software should be built, yet we still do not have definitive answers to questions like "What defines good software?" and "What defines good code?" The answers people give to these questions are wide ranging, aren’t always compatible, and are by no means unanimous. We have trouble deciding what metrics to use to measure our successes and failures. We, as an industry, are lost in the dark and grasping onto anything that seems to light the way.
"What defines good software?"
Customers say, "Good software works and does what I need." Many programmers would add the stipulation that the code that creates the software must be good. Managers would say that development should not cost too much or take too long. Other requirements do not always get specified until problems arise: good software should be fast and responsive, it should not have security vulnerabilities, it should be easy to use, etc. Additionally, the type of relationship between the customer and the developer can cause these answers to change.
However, looking closely at these answers reveals that they are all tightly coupled. High quality code can deliver on most of these requirements. Developers writing high quality code and using good tools and strong practices are able to create working software that does what the customer needs. These same developers will write more code faster, lowering the cost of projects and satisfying management. Some of these savings can also be transferred to the customer.
"What defines good code?"
I’ve heard different answers to this question, too. Bug-free is a straightforward answer, but not necessarily a good one. Clear, concise, and extensible is another. Some say that code that is unnecessarily extensible is also unnecessarily convoluted. "Code that produces working software" is another definition that is similar to "bug-free", but not quite the same. I’m sure there are many more definitions out there, and I will get around to providing my own. All of them have merits, all of them have drawbacks.
While bug-free code seems desirable, it can be terribly written. Some user interface code I was working on recently illustrates this point well. In this particular interface there were two controls that behaved similarly, so they were both accessing the same source for certain properties like "width". I needed to make a change so that in one of these properties the controls would behave slightly differently. I realized that I could write some simple code that would work: since each control would access this value in turn I could return one value for even calls to the value getter and a different value for odd calls. This is terrible code, even though in this case it would work and be bug-free. It does not behave consistently and could be broken very easily. Good code needs to be robust and consistent. Since development almost always continues after "delivery", discoverability and readability are also important to good code. When looking at a new piece of code, someone familiar with the technology should be able to quickly discern how the code should be used, where it gets its data from, and what it does to that data. Someone who is making changes also needs to have a high amount of confidence that the code works and that it will be immediately obvious if the existing code is broken by the changes; keeping code highly tested facilitates this goal. In a perfect world, all code would be highly tested, easy to read, behave consistently over time, and not break unexpectedly when used in a way that was not initially intended.
"What defines a good user experience?"
High quality code is not enough to make good software. We should view unusable user interfaces as a bug in our software; an unusable interface makes the program just as useless as if it crashes consistently. A good user experience is not something that can be easily defined as it relies on emotion. The customer should feel good about the experience he is having while using the software. It should be easy for him to find the features he needs and to do the work he intends to do. If the software does more than one thing, each feature should be easy and obvious to access. Customers should not get confused by the way the program behaves while they are using it. Developers cannot deliver on these requirements while working in a vacuum.
Developers, designers, if you have them, and customers need to work closely together to ensure that the product being produced is highly useable and takes full advantage of the knowledge and experience of everyone involved. Developers cannot create user interfaces alone because the user experience will always make sense to the one who designed it. It does not matter how much sense the user interface makes to the developer, the customer must constantly give input on what works and what doesn’t. By working closely with the customers, the developers and designers know that they are producing an experience that works for the people who will be using the software. This close relationship has other benefits. For example, a close customer relationship will quickly reveal any misunderstanding that the developer has about the requirements for the product.
"What defines good software development?"
Developers have to deliver both a finished product and the tools and methods used to create that product so that it can continue to be altered and built upon. This sets us apart from most other industries. I don’t know of any other product or craft that provides the tools along with the finished product, or that is expected to continue to improve the finished product after it has been sold. These differences make software development unique and powerful. Each piece of the development process is equally important. The code is just as important as the user interface which is just as important as the finished product.
Software developers deliver more than just products, we deliver services before, during, and after product development. A service is provided every time a feature starts development: the problem being solved is framed in terms of software. If the problem has an existing solution without software, a direct implementation of that solution would not take full advantage of all of the benefits gained by using computers. Good developers create a product that provides more than a simple solution: they add efficiency, simplicity, and sometimes even enjoyment.
At the end of the product development cycle we continue to support our software through patches, updates, or even full upgrades. These are provided as customers find additional features that are needed or when new bugs are revealed. This service is provided faster and with fewer errors when the code and user experiences are both high quality. High quality code makes it easier for new code to be added to an existing code base with fewer regression bugs. High quality user experiences are easier to add new features to and these new features are more noticeable.
In my last post about CodeMash I said that I am not sure that the "Craftsman" or "Journeyman" analogy is how we want to describe ourselves. I’ll admit that statement was not fully educated, so I have been doing some reading and I cannot disagree with the core of the movement: the "Software Craftsman Manifesto." However, "software craftsman" as a name seems like just another light in the darkness to grasp onto.
I don’t think we need an analogy to model ourselves after. While there is a lot we can learn from other fields, to be successful we are going to have to define our own space instead of trying to come up with a way to describe what we do based on another profession or trade. By trying to describe ourselves in terms of preexisting ideas and practices we may neglect part of what it takes to make our industry great. Everything that we create is important to what we do and should be given the attention necessary to be great. The higher quality each part is, the higher quality both our products and services will be.

Pingback: Tweets that mention The Software Industry is Lost « Lightbulb -- Topsy.com