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.

That left one area to cover: the database. Not only was it slow, the client was also talking about unexplained near-exponential growth of the database in terms of size on disk. I went on searching online for a tool that would help us optimize on the database the way dotTrace helped us optimize on our code. Using that tool, I was able to rewrite certain indexes that were made inefficiently while at the same time squeezing a considerable amount of improvement on our query speeds.

Fast forward to today: my old supervisor chatted me up in Skype asking me what the name of the tool was, and I couldn't remember. Now most of the time I could find these things on my blog, but I distinctly remember not blogging about this tool, and I had a "doh!" moment right then and there complete with a Homer Simpson-slapping my forehead look.

Trace Analyzer, how dare I forget thee?

After about 20 minutes of frantic googling and mucking around my 18,000 tweets (total FAIL) I found the correct search terms to bring it up -- the tool was DBSophic Trace Analyzer. How could I let such a great tool go undocumented?

Moral of the story: always blog about the tools that helped you a lot. Even if you don't think you would use it again. Because you or someone you know might need it again long after you've forgotten about it.

P.S. Dear Twitter, you're totally useless for remembering things. Love, Jon

Jonjon, with an iPad he doesn't own

"Won't they take away your MVP for that?" was one question. The words traitor, betrayal and turncoat all came up one by one in different occassions.

The answer to the MVP question is no: around the world there are numerous MVPs working as Java, Ruby and iPhone devs in their day jobs, whether or not concurrent to their use of Microsoft platforms. The MVP award is all about community, and I won't be giving up on my community activities anytime soon.

However the answer to the "why" question will bring me back to 1998, when I decided to join the Filipino language newspaper in college. Back then I considered my command of the English language as excellent, both spoken and in print, and I was having some sort of writer's itch, so it might have made sense to join one of the two college papers. So thinking about which one to join, I asked myself; should I merely stay in my comfort zone or not? Eventually I decided that joining Ang Pahayagang Plaridel was an excellent opportunity to hone my writing skills in my native tongue -- something much more unusual in this country and in many ways more special -- and so I wrote for the paper and the rest is history.

Bilingualism has many known benefits, and it could usually be summarized as being able to think in more ways than one. With the paradigms and mindsets of two languages usually being very different, it allows the mind of a polyglot to have a much wider perspective and more points of view, and as my own experiences suggest this same phenomenon applies to programming languages. This is very much the same reason I'm now studying Objective-C and developing iPhone applications -- striving to be a polyglot programmer contributes to your own awesomeness.

As for .NET, I'm sure I'll be writing in C# again soon, especially now that I appreciate its form all the more.

Dynamics and Object Runtime Composition With C# 4.0

It was nice meeting (again) the vibrant and passionate Cebu developer community! Hope to see you again next year!

Some pics from the event:

Jon Limjap at DevCon 2010

Kevin Leversee delivering his awesome presentation on WIIFM and Mediocrity

DevCon 2010 audience

Hackathon participants submit their entries onstage

Enric Sen Canales cheers after winning the Sybase Hackathon

The complete set of pictures are in Flickr and Facebook.

Update Enric Sen Canales won the Sybase, not the IBM Hackathon. There were 2 hackathons held, sponsored by Sybase and IBM. Congratulations to the winners.

Topics include:

• Sharepoint 2010 Programming with Visual Studio 2010
• Web Development with Visual Studio 2010 and Telerik Web Controls
• Runtime Object Composition with C# 4.0 dynamics
• Service Factory on Visual Studio 2010 (Web Service Software Factory 2010 RC)

We'll also have a roundtable discussion on T-SQL vs. Non-T-SQL data access with the Microsoft MVPs where everyone can engage and exchange ideas and thoughts.

Tickets cost PHP150 and will be payable at the venue, starting at 1PM. Please register at http://www.clicktoattend.com/?id=148162

This will be PHINUG's first activity after some time, so we hope to see you there.

            dynamic myObj = "blah";
            Console.WriteLine(myObj.Contains("lah"));
            Console.WriteLine(myObj.IndexOf("x"));

            myObj = new List<int>();
            Console.WriteLine(myObj.Count);

Mr. Fantastic's suit is made up of "unstable molecules" that expand with his form -- like the ExpandoObject.

No errors occur when compiling the above code because the dynamic keyword suppresses checking; if the member is absent an exception is thrown during run time.

However, the introduction of the DLR introduces more than just the capability to switch types during runtime.

Enter the ExpandoObject

The System.Dynamic namespace introduced in .NET 4.0 includes a bunch of new objects that leverages the dynamic capabilities of the DLR. One of these is the ExpandoObject. The ExpandoObject allows members to be added at run time.

For example, we could arbitrarily add properties to a class during run time:

            dynamic mrFantastic = new ExpandoObject();
            mrFantastic.Name = "Reed Richards";
            mrFantastic.BirthDate = new DateTime(year: 1961, month: 12, day: 2);

            Console.WriteLine(mrFantastic.Name);
            Console.WriteLine(mrFantastic.BirthDate);

However, we stated that the ExpandoObject can add members during run time, which doesn't only mean properties, but also methods. To be able to treat methods and functions as assignable objects, delegates have to be used. The two primary examples of delegates are the Action delegate, and the Func<TResult> delegate.

Action delegates take on a single parameter and doesn't return a value. Essentially Action<T> accepts void methods as its value. Func<TResult> on the other hand, takes on no parameters and returns a result of type TResult.

Using lambda expressions, or even anonymous delegates, we could then add methods to our ExpandoObject like this:

            //write the value of the Name attribute to the console:
            mrFantastic.SayMyName = new Action(() => Console.WriteLine(mrFantastic.Name));

            //calculate Age of person by subtracting current time with birthdate, and dividing by average number of days in a year:
            mrFantastic.GetAge = new Func<int>( () => Convert.ToInt32((DateTime.Now - mrFantastic.BirthDate).Days / 365.25) );      

            mrFantastic.SayMyName();
            Console.WriteLine(mrFantastic.GetAge());

Of course, you could use other delegates like Action<T>, Action<T1, T2>, Func<T1, TResult>, etc. to accommodate multiple parameters into the object definitions.

Further reading

There are some interesting and practical applications of ExpandoObjects. One of them is Client Application Development MVP Anoop Madhusudanan's ElasticObject, which allows for multilevel ExpandoObjects, which can then be used to create dynamic XElement structures. Read more about it here.

Image taken from http://en.wikipedia.org/wiki/Mister_Fantastic.

The author of this C# article fails to mention even a single thing (a real example, in a real business situation) where he did something better and quicker because he was using C#

...

And if it is true that C# programmers cost 10% more, then I as a person who has been hiring programmers for 15 years, certainly do not want to bring in C#. Instead I will put my money in VB.NET which is easier to read and programmers cost less – so I save my company money – and achieve exactly the same results – in less time.

And in a later comment:

More importantly, almost all programming is done for use in a business environment. Which means there needs to be ROI, and the best one possible.

...

Of course ROI does not apply if you are doing non-critical (to business) programming work, in which case the longer learning curve of C# does not matter – as it is all for fun; but for serious business applications, Lambda expressions, and the odd features really do not matter.

His opinion on the matter is interesting because first, it comes from the perspective of a business person who, in the "15 years of hiring developers", has found no need for the use of any language more complex than Basic. He has found C# or other non-english-like language so unnecessary to his applications that he is convinced they are a waste of resources in terms of return-on-investment.

The AK-47 is probably the most popular assault rifle in the planet

I actually agree with him. The key of success in many products is often their simplicity in terms of construction, operating principles, and the ease by which you could find or manufacture spare parts (as an analog to software maintenance) for these products. Consider for example, the most pervasive assault weapon in the planet: the AK-47.

The reasons for the AK-47's success is simple:

Even after six decades, due to its durability, low production cost and ease of use, the model and its variants remain the most widely used and popular assault rifles in the world. It has been manufactured in many countries and has seen service with regular armed forces as well as irregular, revolutionary and terrorist organizations worldwide. The AK-47 was also used as a basis for the development of many other types of individual and crew-served firearms. More AK-type rifles have been produced than all other assault rifles combined. [Wikipedia article on AK-47]

Clearly, the AK-47's superior qualities should have made it the assault rifle of choice for every military unit in the world, but there are a wide variety of assault rifles and other such weapons used around the world, for a variety of purposes. While some riflemen will simply dislike it because of idealogical reasons (e.g., its Soviet origins or association with paramilitary and terrorist organizations), others may find a variety of practical reasons not to use it: whether it be dimensions, recoil, range, handling, etc.

The same will be true for Visual Basic or its variants. While it's perfect for many, many business applications, with the perception that developers can easily be trained for using it for a reasonable return on investment, there will be cases and applications beyond simple business logic that will render it cumbersome, and where C# may be the better choice of language for development.

Mike also accuses me of dismissing Visual Basic simply because I don't want to be considered a beginner:

It is very clear that he associates VB with his first language BASIC; and because he wants himself not be considered a beginner (but a very experienced programmed well capable of using all symbols in C#) he chooses C#. It is C after all and not a Beginner languange(sic)...

C# with its more cryptic looking code, certainly costs more to the business.

How many commissioned paintings are made with crayons?

If I follow his logic, believing that "cryptic looking code" costs more to business, and using a "simpler language" is more beneficial to businesses, then tell me, why aren't there more paintings made with crayons than those made with oil pastels, acrylic, and other more complex media?

I have to make this clear: I don't think using Visual Basic is tantamount to using crayons. But if I like doing paintings more with acrylics than with oils, or with watercolor than with gouache, or with sable brushes than synthetic ones, or with lacquer-based rather than water-based paints, should it be taken against me?

If the person who commissions my work mandates me to use Visual Basic, then by all means I'll use it, but that doesn't mean my preference for working with C# will go away. It's a tooling preference, a matter of choice, and not the kind of elitism Mike implies in his comment.

Every craftsman will have his tool of choice, and they'll try to use it as much as the circumstances will allow.

First, I once more received a Microsoft Most Valuable Professional for Visual C# award for the year 2010. It was an interesting year meeting people both in real life and online with the same passion for software development and it feels good to know that there are people all around us who we can teach, and from whom we can learn from.

Apollo Johan Alipio Limjap

But the bigger gift to me this month is the birth of my second child and first boy, Apollo Johan Alipio Limjap. He was born on April 11, 2010. He was confined for the following week because of an elevated white blood cell count, with visits limited to his mother. I was only able to enjoy his company the past week, and needless to say it was a very happy and fulfilling week that reminded me how it is to be father to an infant again, soiled diapers, pee baths and all.

Can't wait to teach him all the geekery I could muster.

I was lucky to have been able to present, as a 10 minute Lightining Talk,  a topic I loved a lot -- What's new in C# 4.0. And for the first time, my talk was live-streamed over the net and recorded using ustream.tv.

Thanks to Karl Arao for the photos below!

Later in the evening I was part of the judges for the Hackathon where PHP10,000 pesos was awarded to the winner Elmer Rivera, after a 30 minute programming challenge.

Hackathon participants congregating around an access point. Maybe for faster documentation browsing?

Participants look on during judging

Special thanks to the Philippines Software Industry Association (PSIA) Secretariat, especially Diane, for a great DEVCON Luzon.

Hope to see you in Cebu for DEVCON Philippines this June!

Here are some of the pictures from the event:

The speakers squaring off...

The VB camp...

The C# camp...

Ladies of VB

JL Tolentino with his passionate defense of C#

Jad with his views on VB

We want to thank new Microsoft DPE Dale Jose for all that booze (and the idea for the event, actually )

I again thank all the awesome audience who came, spoke their mind and helped us make this event truly awesome! Thanks!