Seeing Code as Art

Art” is a diverse range of human activities in creating visual, auditory or performing artifacts, expressing the author’s imaginative or technical skill, intended to be appreciated for their beauty or emotional power. – Wikipedia.

Programming is an activity which results in visual and/or performing artifacts. The quality of the artifacts is based on the programmer’s creativity and technical skills. The intention for the result is usually to help different parties (or oneself) to gain values in which otherwise could not be obtained. The aggregate total amount of the values obtained by all parties is the measure on how the program is appreciated. From this, the following statement could be derived:

Programming is an activity to create an art. The code is the art. The programmer is the artist. The program is the art form.”

The Art of Coding

We constantly require to balance tensions between cost, quality, time and flexibility of our program with the business requirement. When the program and the business requirement is not in sync, the program becomes unusable, or mediocre at best. This, in turn, hindered the business progress, and the program loses it values and becomes meaningless over time.

“Art calls for complete mastery of techniques, developed by reflection within the soul”
– Bruce Lee

Mastering programming techniques require time, patience, application and experience of the particular subject. The most important aspect is for an individual to realize and seek for it. This is done by an active continuous learning from mistakes and seeking the solution to be better.

One of the best reflection methods taught by Eric Evans, author of Domain-Driven Design was done by asking oneself “How useful is this?”. The question itself is very broad and should be put into context. A particular object or model could be re-factor if found not being useful in a specific context when compared to other solution that achieved the same results. Techniques of refactoring were dealt extensively within Martin Fowler’s book of Refactoring.

Let’s consider the following object:

public class Customer {
    public string FirstName;
    public string LastName;
    public DateTime Dob;
    public string Email;
}

Looks simple isn’t it? Let’s look at how we would use this object.

var customer = new Customer();
customer.firstName = “Andy”;
customer.lastName = “Smith”;
customer.email = “Andy_Smith@email.com.au”;
customerRepository.Add(customer);
...

The object would also allow the following:

var customer = new Customer();
customerRepository.Add(customer);
…

The object currently is not very useful other than just being a bag of properties that magically appears, most probably from the database table. From the developer point of view, the customer object did not explain anything about the customer in the business context either.

Let’s modify the customer object to be more useful.

public class Customer {
    public string FirstName { get; private set; }
    public string LastName { get; private set; }
    public DateTime Dob { get; private set; }
    public string Email { get; private set; }

    public Customer(string firstName, string lastName, DateTime dob) {
        if (string.isEmptyOrNull(firstName)) // poor man validation
            throw new Exception(“First name cannot be empty”);
        if (string.isEmptyOrNull(lastName)) // poor man validation
            throw new Exception(“Last name cannot be empty”);
        FirstName  = firstName;
        LastName = lastName;
        Dob = dob;
    }
    public void SetEmail(string email) { 
        if (!isValidEmailAddress(email)) // poor man validation
            throw new Exception(“Email address is invalid.”);
        Email = email;
    }
    private bool isValidEmailAddress(string email) {
        ....
    }
}

To use the new object, we would have to do:

var newCustomer = new Customer(“Andy”, “Smith”, DateTime.Parse(“19/2/1988”));
customerRepository.Add(newCustomer);
…

The modified object tells developer a few information regarding the customer. Customer must have firstName, lastName and date of birth at the minimum. Those properties are immutable, and it means that it could not be changed after creation. This implies that any customer object that was created must be in a known state. Customer object must have the minimum properties that were set from the creation time.

Let’s dig this class bit deeper. As the firstName and lastName were immutable, we would need to throw away the customer object if the creation was using a wrong data, making the database row very much meaningless. Let’s assume this particular business context. The business did not care much about a customer coming back to fix their detail. The business just requires the list of customer and whereas possible their email address. Of course, in reality, this business requirement would be much more complex.

If we look above, the changes were very simple. It forces the object to be used in one specific way. In this manner, the customer object is more useful in the specific context.

In order to be able to create the better, more useful code, a deep understanding of the technologies and the business is required to communicate the business intentions. Just like what Bruce Lee said, this depends on mastering the techniques (in this case programming techniques) and deeper reflection upon the usage.

Do you agree that code is an art? How do you see code?
Share your opinion below!

4 thoughts on “Seeing Code as Art

  1. Pingback: 3 Code POV secret for Better Code | Code Construct

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s