.NET @ Kape ni LaTtEX

This talk was delivered last August 7, 2010 to university students taking up Computer Science and IT courses as part of the JPCS-AdU Extreme Engagement event organized by the Adamson University chapter of the Junior Philippine Computer Society and sponsored by Devcon Foundation.

When a person first learns programming it is natural that they learn its form and structure first. They focus on constructs, syntax, concepts like variables and memory addresses, data structures, and eventually move on to programming paradigms like methods, functions, classes, and objects, as well as techniques and complex algorithms. These are the things that a student of software engineering will learn in school, but once they step into work there are some things that will take precedence over the elegance of the algorithm you write.

It’s not that these things are not taught in college – they most likely will be covered at one point or another in the curriculum – but it will only be in the workplace where their importance will become compelling. I’d like to talk about three concepts in particular that I feel are very important in the workplace but oft ignored at school.

Maintainability

I define maintainability as “a measure of how easy it is to understand, modify, and extend your code.”

Now when you think of the word “maintenance” it’s likely that you might think of handymen or janitors maintaining your building – this is not far from the truth. When you get employed the first thing that you will notice is that you won’t be able to write new code. While writing new code is the first thing you do at school, it is the last thing that you get to do when you first get a job.

One of my most significant experiences on this was when I joined Philippine National Bank and had to learn COBOL to maintain JCL reports running off of mainframes. Some of the reports I were handling were first written as far back as when I was in puberty; I suspect that these were replacements to even older reports that served the bank during the time I was the figment of my parents’ imaginations.

Some of that code is messy. By messy I mean they have variable names that you can’t figure out, method names that don’t make sense, and inconsistent techniques in writing code. How many of you have had lost track of a variable named “a”, “aa”, and “aaa” in your machine problems?

Some of you may graduate, join that bank, and then realize that I, that crappy COBOL developer from eight or ten years back, had left a mess of my code. How would you feel? How much effort would it take to modify those reports?

In his article “Learning to distinguish a solution from a problem” and his book “Facts and Fallacies of Software Engineering”, Robert L. Glass states that “Maintenance typically consumes 40 to 80 percent of software costs”.

That’s not just maintaining old code or code other people wrote; it includes code you wrote three to six months ago and have totally forgotten about. Large projects can last for up to a year, sometimes even two, and in my case I’ve had to face code I have written three to four years ago as we roll out newer versions of our software.

Don’t think that you don’t need to maintain your own code. Make it easy for yourself and for your colleagues. Make your code readable. Make it easy to understand. Make your code maintainable.

Testability

The Software Testing Glossary defines testability as “the degree to which a system or component facilitates the establishment of test criteria and the performance of tests to find whether these criteria have been met.”

Let’s simplify that to a question: “when there’s a bug, how easy is it to find out which part of your code to fix?”

A few years back a former colleague of mine IMed me asking for help. He wanted me to look at his code and find out what was broken. Thinking I could help, I agreed and downloaded the file he sent to me. What I saw was a disaster: one main void method, filled with 7,000 or so lines of code. I didn’t even want to ask him how he survived for so long in the IT industry writing code like this – all I could do was scroll up and down, gape at the nested ifs and for loops, then reply to him “sorry dude, I don’t know how to fix this.”

Now, I understand how tempting it is to do this kind of programming when its 2 in the morning and you have an 8 AM deadline for a machine problem. But in the workplace, whatever deadline they tell you is rubbish if the end result is an application that is broken and unfixable.

So how do we ensure that our programs are testable? If you’re doing object-oriented programming, there are several clear cut principles defined by Robert Martin in his article Principles of Object Oriented Design.

Together they are called SOLID Principles:

• Single Responsibility Principle – your class should have one, and only one, reason to change
• Open Closed Principle – you should be able to extend a class’s behaviour without modifying it
• Liskov Substitution Principle – derived classes must be substitutable for their base classes
• Interface Segregation Principle – Make fine grained interfaces that are client specific
• Dependency Inversion Principle – Depend on abstractions, not on concretions

There are tons of extensive discussions on these principles on the internet, and you would easily notice that these topics are intertwined with Test Driven Development. That’s because if you follow the SOLID principles, your code would easily lend itself to automated unit tests, and vice versa. Also notice how these principles relate back to maintainability – in many cases testable code is maintainable code.

It’s all good advice, so do take your time researching on these topics, because this is what separates the awesome programmers from the mediocre ones.

Usability

Wikipedia defines usability as “the ease with which people can employ a particular tool or other human-made object in order to achieve a particular goal”.

It’s much easier to define usability in pictures. In 2008 Eric Burke published on his website stuffthathappens.com a classic comic defining what usability is:

He entitled this comic “Simplicity”. I’m sure it’s easy to understand the correlation between simplicity and usability.

Consequently it’s easy to see from this comic why Apple products are just taking the world by storm. The comic was published in 2008, about a year after the first iPhone came out and almost two years before the iPad hit the market. Why is there a three week long waiting list for getting an iPhone 4 today? Why are Chinese manufacturers trying hard to copy the iPad and coming out with absurd products like the iPed? Why are those manufacturers failing?

It all boils down to usability. Apple products are easy to use, and if you’re developing software for it you are forced to make it easy to use.

One valuable lesson I learned in my two months as an iPhone developer is that, while the Cocoa Touch developer experience is inferior to my experience developing Microsoft products, its limitations clearly define one objective – all the controls provided clearly translate to the touch screen paradigm of the iPhone.

So how do you make your application highly usable? I recommend following Steve Krug’s First Rule of Usability: “Don’t make me think”. It also happens to be the title of his bestselling book which I highly recommend if you want to learn more about the very broad topic of usability. In essence, what “Don’t make me think” is trying to say is that the user interface of an application must not need any explanation, and simply tap common sense. This is the secret behind the success of Apple’s products.

Even more importantly, good usability sells your software because it makes your customers feel good. Joel Spolsky states that “good UI sells software, but it also makes people happy, because people are happy when they accomplish the task they want to accomplish”.

Is the user interface of your software capable of making other people happy? Think about it.

Maintainability, Testability, Usability

These three tenets are in no way simple to master – it takes years of conscious effort and practice to improve your code to be able to achieve this. However, it’s very rewarding whenever you realize that your investment towards these tenets create a great product that your customers appreciate.

They are powerful concepts that define the difference between an awesome programmer and a mediocre coding monkey. It’s no surprise a great amount of discussion in the internet boils down to these three “abilities” and will continue to do so for years to come.