Don’t be a Software Engineer, be a Software Artist

Occasionally, new software engineers are confused by me saying their design or code are “not good enough”, and their question/response is usually one of the these:

1. this code works, why should I keep changing it?
2. this design is feasible, why do you want it to be simpler?
3. let me explain this code to you, and you will undestand.

“Not good enough” is a very vague term here. Usually I would use some less-vague-but-still-very-vague-terms such as “not simple enough”, “not easy to understand”, “not user friendly”, “not self-explainable”, etc. Usually I would have a chat with this engineer about why we need to design a simple architecture, why you should write simple, easy-to-understand code, why you should format your code, why you should put an extra space between these two symbols…

If you have been in software industry for couple of years, or care enough to read some books about how to write good code and how to design good architectures, you probably will feel the same way. Those are basic concepts that should be grasped by every new software engineer, but unfortunately not everyone understands the necessity of those concepts.

Not only do some new engineers don’t insist on highest standards on the quality of the design and code, some engineers who have been in the software industry for a while also have this problem. You can ask them to read Code Complete 2, Clean Code, Art of Unix Programming, and other 10 different programming books (you name them), some of them will improve their engineering quality, some still won’t.

Software Engineer vs. Software Artist

Why not every software engineer producing high quality code and high quality design? Maybe some of them are inexperienced; maybe some of them don’t know how to generalize what they have already learned from those books and past experience; maybe some of them just want to finish their work and to them, being a software engineer is just a job. But fundamentally, it’s because they think they are software engineers, not software artists.

The requirements of being a software engineer are:

• knowing how to write code and test code;
• knowing how to identify business problems, collect user requirements, design a project and release it;
• and anything in software engineer’s job description.

Usually, there is no requirement of writing easy-to-understand code, or desinging a project that is easy-to-use.

So what’s the requirements of being a software artist? To answer this question, we should look at what a design done by software artist look like; or more general, what a design done by an artist look like.

When I first looked at Charles and Ray Eames’ plastic side chair years ago, I was amazed by its simplicity and its unreasonably comfort brought by this simple design. This chair was designed 1950 and has been very famous since then. As a software developer, I naturally thought was: how can we build a software like this chair?

I have been using this chair daily for more than three years, here are what I like about this chair:

• It’s very pleasant to look at it.
• Everyone can immediately recognize this is a chair and its functionality. This is probably a silly example, but think about something you see but you have no idea what it is or what it does.
• The seat and back are molded into one plastic piece; the base adds its own complexity because it’s less boring to look at than the traditional chair.
• Because of this plastic piece, when you sit on it, it will slightly adjust the support based on your sitting position. I personally think this is very ingenious. Many chairs use complex structure to provide good support, but this chair leverages the material to do the same thing without adding extra components.
• It fits everywhere: bedroom, office, living room, dining room, etc.
• It’s environmental friendly. It’s made of 100 percent recyclable polypropylene. Historically, this chair was also be made of fiber glass but the production was paused until an environmental friendly way of producing fiber glass was discovered.

So what’s the project/product would look like if we ought to build a “Eames Plastic Chair” in software industry?

• The code, the design, the architecture should be very pleasant to look at.
• Whoever read the code snippet, method, class, design doc, architecture doc, they should be able to immediately recognize the purpose of this entity and know how to use it.
• The code/component/design/architecture should be as simple as possible. But not simpler than necessary.
• The project leverages existing products, libraries, code, etc. to simplify the design.
• The design should be flexible so it can cope with future policy changes. This is a separation between mechanism and policy.
• The project should be environmentally friendly. It should not cost more hardware resources than necessary; it should not cost more peopleware resources than necessary either.

Whoever can design such project/product should be recognized as software artist rather than software engineer. They really insist on the highest standards for designing, architecting, and implementing a project.

How to Quantify

Readers may argue that it’s extremely difficult to quantify those requirements. For example, how to define “as simple as possible”? Some people attempt to classify a “long method” by checking if this method can be fit into a computer screen. Some people suggests to count how many states an object can be in the life cycle of the system.

I think the real value of being a software artist is that you don’t quantify, you constantly improve. When you design a project, constantly ask yourself: can this project be designed better? When you write a code, after testing all the functionality, sit back, look at it, and ask yourself: is this code structured beautifully as a finest artwork you have ever seen?

Software engineers will stop improving their projects once they checked all the checkboxes, software artists do not have those checkboxes because their work are already above the standards. As a software artist, once you settle down on measuring your project against some baselines, your project is no longer an artwork because you would not challenge yourself any more.

Of course, you will release the current project, but you will always go back and improve it because you’re a software artist.

More Than a Software Builder

Software artists can surely build software with highest standards. But being a software artist is more than just being an excellent software engineer who can write good code and design good architectures. Being an artist in software industry requires you to:

1. understand your customers
2. be a teacher and an influencer

Understanding Your Customers

When I just came to software industry, I only thought about how to write good code to solve customers’ problems in a given business domain. As I started to talk to our customers, I realized that customers know what they don’t like or sometimes, what they want. But they rarely know the specific requirements.

I always believe that “what customers want are not what they actually want”. Most customers are really good at proposing solutions based on what they see and know by looking at your competitors. But if you accept their proposers, you will realize that your customers are transforming you to your competitors.

Working with your customers to understand what they actually want to is much more difficult than optimizing a slow algorithm to make it run faster. If they want to sell their artworks, artists need to understand their customers. This is a really difficult because their customers want beautiful paintings that can be hang in the living room, for example. Painter need to figure out the specific requirements for this painting.

Our customers sometimes complain that the search results in our website only contain the top 200 entities. New software engineers usually will go ahead to increase number of the search results displayed by changing the configuration, and if the search is slow, adding more machines, etc. A software artist tries to understand the customers’ problems and figure out what they actually want. The questions for our customers could be:

• why do you need more results? (200 entities is really a lot in our problem domain.)
• how do you use those results if we could give you 2000 entities?
• how about we categorize all the entities and each category could have 200 entities?

Long-term Influence

Artists usually influence other people by what they do and/or what they produce. Furnitures designed by Charles and Ray Eames influenced the whole furniture design industry after WWII. Claude Debussy’s impressionism music made people rethink how to use music to convey the moods and emotions in a more abstract way.

When architecting a design, think about if this design can stand the test of time or this project is just a fashion. A design can stand the test of time when:

• other people, other teams in the similar business domain can reuse your design.
• your design can cope with some policy changes. (Rule of Separation)

Being a software artist is also about being a teacher. You need to teach other software engineers to be software artists. There are some typical ways to influence other people:

• Document everything you did. If you did something great, other people should be able to use your document to repeat the success.
• Mentor other engineers.
• Occasionally, give a talk in your team, organization, or even in your company.
• Publish your work.

Acknowledgment

• Kazuki Yokoyama who inspired me to write More Than a Software Builder section.