Ndc 2010

I’m very proud to announce that I will be speaking at the Norwegian Developers Conference 2010 (track 6, day 3, 16:20).

My talk is named “A Style of programming”:

“This talk describes a set of coding principles that constitutes a style of programming that focuses on ease of coding, ease of changing the code, and ease of testing the code. The presentation aims at helping programmers understand how the principles relate to actual code. Every principle is made concrete through examples. This style of programming is influenced by leading object oriented and agile developers, and it is perfect for applying on object oriented languages such as C#.”

Hope to see you there!

- Tore Vestues

Let me give you an example.

When Kent Beck and his extreme programmers started out (with XP – extreme programming), they were talking about not writing comments in your code. And they explained what they meant: Comments are often an indication that your code isn’t readable on its own, the fix is often to write code that is easier to understand, not to add comments.

For me this is great advice. I try to keep my code clean and readable, and when I feel the urge to write comments, I first check if I can make the code more self explainable on its own. I personally write some comments, but never to explain code that looks like crap.

The problem with this advice is that it is actually bad advice if you do not understand why you should follow it. Those that do not understand why they should reduce their amount of comments, but still dig the idea, are probably writing as unreadable code as they always did, but now explaining the mess with even less comments. The result is probably all over worse code than if they didn’t follow the advice in the first place!

There are at least two lessons to be learned here.

First, if you do not understand why you are doing something, you are probably doing it wrong. It is time to start questioning what you are doing, always ask why.

Second. Say too many people misunderstand the purpose of something, thus applies it wrong, and thus is actually producing worse results than before. In our “no comment” example, people would, based on empirical evidence of the practitioners, say that the “no comment”-idea is a joke (since most of its followers are actually writing worse code). So by applying the idea wrong you are probably discrediting the whole idea.

I like to define agile in one sentence: “Ask Why”. “Why should we write this piece of documentation?” “Why should we follow this process?” “Why should we follow this practice?” If we better understand what we are doing, and can adjust our practices accordingly, I think we will get a long way. I think this is the core of agile.

- Tore Vestues

Disclaimer: There are several reasons software projects fail and many of them are caused by management – way above the developers. Still, we as developers have to take our part of the blame, and crap code is our contribution to the failure.

It is not about algorithms and performance

I didn’t learn much about communicative code at the University. And I still do not think people learn a lot about it. Students probably still think that software development is all about performance and effective algorithms. I’m sorry, often it’s nothing like that. In most business applications today there are no fancy algorithms. It’s just a huge amount of code that is trying to express the rules and logic that exist in the business. Performance might be an issue, but it has nothing to do with tweaking algorithms, it’s about architecture, data loads and sometimes really bad code.

So, what’s the problem?

The major problem with business applications today is the huge amount of code. The amount is not a problem in itself, but it gets to be a problem very fast when it’s hard to understand what it does.

Let’s take a simple example: Methods in today’s software are often way too long. It takes a lot of time to understand 100 lines of code that does several different things, and it’s even harder to change it without breaking something. I’ve seen tons of code that looks like that, and I’ve spent ages fixing such code. Believe me, code like this is very expensive and it will soon be full of bugs. Such software deteriorates pretty fast, and before you know it you’re at a point where whenever you remove a bug, you add two new ones. We should all be ashamed, honestly.

Code that is hard to understand is hard to change; software that is hard to change will be expensive and slow to change, and the risk of the changes adding new bugs is high. Who wants an application where it costs a fortune to add features, takes forever, and adds new bugs?

It’s about communication

Yes, it is a mess, but what can you do? We have to understand that writing software is about communication!

Put simple: Code that is easy to understand is easy to change. When it’s easy to change the risk of introducing bugs is low. That’s the kind of software your customers want!

Martin Fowler hit the nail on the head when he said:

“Any fool can write code that a computer can understand. Good programmers write programs that humans understand.”

What can I do?

When I write software, my main concern is actually if I am expressing my code in a way that others will be able to understand. And the “others” are quite often myself. When I get back to code I wrote two months ago I want it to be really easy to both understand and change that code.

When I have to work with code that is hard to understand I often make it easier to understand first, then make the changes. I keep my methods short. I keep my classes short. I try to organize my code so that related logic is grouped together, and unrelated logic is separated. I write tests for my code that explains the code. I care about the code I write.

Writing code that communicates is first and foremost a mindset. Get it! Then it is a set of practices and principles. Read them, train them and practice them. Find out what works for you. Nothing can replace experience.

Robert “Uncle Bob” Martin has written an excellent book on the topic: Clean Code. Read it now! Kent Beck is also passionate about this, and wrote this book: Implementation Patterns.

I’m holding various presentations about what I call Code Quality. Communication is a vital part of that.

- Tore Vestues

I enjoy learning different ways to solve (the same) problems,  and I strongly believe it is important to do that. Seeing other ways to solve common problems will help expand your mind as to how you can solve problems yourself. That’s why i found this meeting so interesting too. Maybe I will not use Prolog so much myself, but I can still learn from it’s way of thinking, and enrich both my thinking and my code written in other languages.

Prolog 

Well, back to Prolog. I haven’t really been introduced to Prolog before, so I enjoyed the introduction we got. Three things strike me with Prolog:

1) How different it is from other mainstream programming languages.  Here we have a language that actually does not contain an “if”-statement, and it still solves problems. I find that fascinating in itself. It’s a completely different way to solve problems.

2) How declarative and explicit it is about the (domain) rules. Given a well defined domain I would love to express the rules for that domain in Prolog. It’s really beautiful.

3) It must be a nightmare to debug. When your ruleset and dataset starts to grow, it must be a nightmare to debug and even worse to try to make changes to it.

Java and Prolog (jTrolog)

Given my observations about Prolog are “correct”, I believe Prolog can be a beautiful tool, but I think the domain must be small and specific. And given that many of us normally work on enterprise applications with not so small and well defined domains, maybe Prolog is not the thing.

But then again, what if we find smaller well defined sub-domains within those enterprise applications?

Enter jTrolog (or one of it’s equivalents). jTrolog let’s you define and execute Prolog in plain Java. What I see here is opportunity. Now we can still make our enterprise applications in Java, but all of a sudden we can introduce the elegance of Prolog for specific sub-domains.

When it comes to it, it’s ofcourse not just that easy to introduce Prolog in your next Java project. For instance, introducing a new language that probably no one else on the project understands well, will most often not be a smart thing to do. But such barriers are there to be overcome.

Expand the horizon!

- Tore Vestues

Realizing this, I started using a simple, yet effective method of making this transition a bit easier in everyday life. Basically, whenever I read something interesting that I want to make use of, I study it, make out the essence of it, write it down, and put it over my desk (virtually or physically). Then I make a point out of considering/applying it whenever applicable.

For instance, when I first read about the Law of Demeter, I wrote down the essence of it, and put it over my desk. whenever I got to a point where I broke that law, I was reminded by my note, and started to dwell abit about what the Law of Demeter was about, how my design would look if I solved my problem without breaking it, and the costs and benefits for doing it this way. Pretty soon I really understood the point, and it became a part of my general skills. I learned by doing. Doing it this way kind of forces you to actively consider the theory, testing it, applying it, and evaluating the results.

I’m really happy with this technique, and nowadays there is always a note over my desk.

If you want to try it out, you really should. Here’s a few simple guidelines:

• Keep your scope simple. Don’t write things like: “apply XP”. It’s too general. Keep the scope narrow and concrete, like: “always write the test first”. It’s easier to apply, and it’s easier to evaluate the costs and benefits.
• Do not have more than one scope at a time. It’s important that you can be focused. Having to many things to consider, will complicate things, and you’ll probably fail applying anything.
• Commit yourself. When you have a scope, be true to it. This is the best way to learn it.
• Switching scope. Don’t switch the topic before you feel you’ve learned it properly.

Tore Vestues

Finally I’m up and running.

Communication is the key to learning. Through communication we learn from others, and through discussion we develop new knowledge together. This blog is an attemt to communicate. It’s about sharing my thoughts, and getting feedback on them from the larger community. I think there is a lot of learning in that process. So give me a comment, and let’s learn together!

 Tore Vestues