Freekshow

October 20, 2011

That’s just perfect!

Filed under: Learning,Process,Programming — Freek Leemhuis @ 7:22 pm

I’ve been thinking about the concept of ‘Perfect’ recently.

In our business there’s a lot of talk about self-improvement, excellence and similar concepts.
Often the discussion is lead by ‘agile coach’ types who can not program their way out of a paper bag, but that is another story for another day.
The ‘Perfect’ meme is used to promote Deliberate Practice, as perfection is elusive by design and so by aspiring to perfection we can continue to learn.
Personally I find it a lot clearer to strive for improvement rather then perfection. Improvements are easier to define and measure than an abstract concept like perfection.
Suppose that you would strive to reach old age, would you focus on immortality? You’d probably be off looking for that magic potion. If instead you aim to get older you would maybe decide to obtain a healthier lifestyle, thereby actually increasing the chance to get older.

There’s this quote from George F. Will:

“The pursuit of perfection often impedes improvement”.

By looking for that perfect solution one often finds a gaping void between it and the current situation, making it hard to figure out where to start. If instead you try to think of one thing that would improve the situation, and do this as often as possible, then you are well on your way towards excellence.

The other problem with aiming for perfection is the potential for poor return on investment that more practical minds would point to. We as programmers care a lot about the form and shape of our code, where our customers usually really only care about it’s function. Too much focus on the internal quality can thus be perceived as being wastefull. Nobody will deny you the right to improve yourself and to spend time and energy for that purpose, so overall it would make more sense to use terms like Continuous Improvement (or ‘Kaizen’ if you want to be pretentious about it) then to strive for perfection.

I try to create code that is less sucky everyday, so as to stay in what I call the Zone of Usefulness.

Let me know if you find this a usefull concept 🙂

Advertisements

May 5, 2010

Programming for kids

Filed under: Devnology,Learning,Programming — Freek Leemhuis @ 4:44 pm

Some time ago I was running out of time for the Devnology codefest assignment to create my own Tetris clone. At the same time I was trying to spend some more time with my daughter, who is 8 years old now. She is sometimes very bored from school, which I sympathise with – I was the same at that age I guess. So I thought this would be a good time to try and see if she would be interested in programming. After some research on visual programming languages for kids I to give Scratch a go to see if we could build something together.
It took us very little time to get going, and in no time we had some of the build-in characters moving across the screen. Visual programming makes it relatively easy to grock some of the core concepts of programming. Loops, conditions, variables – you just drag them on a pane and they snap together.

We started out by discovering animation, and this is when something amazing happened. We added some animation logic while the app was running, and it changed its behavior while it was running.
I had a flashback to Alan Kay’s demo on TED – a powerful idea about ideas. If you’ve not seen it, go ahead and watch – it will be 20 minutes well spent.

Reading up on Scratch I found it is actually build on Squeak, an implementation of the Smalltalk language and environment.
After some goofing around we set off to create a simple tetris clone. Except tetris isn’t that simple, and with no means of testing or debugging, one quickly realises this is really an educational tool but not so good in producing something more complicated.
We did get sort of half-way, but it’s fair to say that by then neither of us was enjoying the experience very much.
I’m very impressed with Scratch as a tool for education young children, and it’s a real joy to see the thoughts and discoveries of your child click into place going through some of the basics. Some advice for other fathers: take it slow, one step at a time. After an hour or so trying to explain everyting, it turned out to be a lot to ask for from Hannah. ‘Can I play with my playmobile now daddy?’ Ofcourse you can, just wait while your daddy finishes this real simple tetris game…

December 10, 2008

The comment of all comments

Filed under: Programming — Freek Leemhuis @ 9:07 pm
These days I’m doing some code reviews for other people’s projects. Mostly these are architectural reviews, where we review an existing code base and comment on the design of the codebase, and sometimes also on software engineering practices (or lack thereof!).
One of the things that always comes up in discussions is the comments in the code. Tools such as Campwood Software‘s Source Monitor for example allow you to quickly produce a Kiviat Metrics Graph, such as the one displayed below.
no-comment

There are two different metric values for comments displayed: Documentation comments and actual comments.

Documentation comments

In the graph the value displayed for documentation lines (% Docs) is the number of documentation lines (indicated by ‘///’ at the start of the line) as a percentage of the total number of lines.
These documentation comments show up in the intellisense. For example, if have added documentation lines to the code below:

/// <summary>
/// Get the list of most popular jokes
/// </summary>
///
<param name="numberOfJokes"  ></param>
/// <returns>Generic List of Joke</returns>
public List<Joke> GetMostPopularJokes(int numberOfJokes)
{
   List<Joke> result = new List<Joke>();
   Joke jokeStub = new Joke();
   jokeStub.question = "How many developers does it take to change a roll of toilet paper?";
   jokeStub.punchline = "Who knows? It's never happened.";
   result.Add(jokeStub);
   return result;
}

Then if I call the method, the information in the documentation lines are displayed in the intellisense tooltip thingy:
comments_intellisense

In addition, tools like Sandcastle allow you to compile the comments into help files. Pretty neat?
If you’re Microsoft, and you actually have to deliver this kind of documentation, I suppose it is. In most other cases, I think this type of help documentation is pretty useless. It is out of date as soon as the code is updated, and I have seen on many occasions that the code gets update but the documentation comments are not. And if that does happen, will you ever trust the ‘documentation’ again?
There is no automatic link between comments and the code, and only the most disciplined team of programmers will never forget to adjust comments.
On the other hand, if you use concise variable and function names, should they not express the intent? What does the documentation code add, really?
Usually it is just a (partial) rephrasing of the actual code, and it violates the DRY principle. Have you ever done a lot of refactoring, and keeping the documentation lines up to date at the same time? If you have, I bet you’ll agree with me: this type of ‘documentation’ – let’s do without it.

Actual comments

I find it hard to attach any meaning to code metrics that express the number of in-line comments. It all depends on the purpose of the comments. The following example is from the Enterprise Library:

/// <summary>
// convert to base 64 string if data type is byte array
if (contextData.GetType() == typeof(byte[]))
  {
    value = Convert.ToBase64String((byte[])contextData);
  }
else
  {
    value = contextData.ToString();
  }

What does the line of comment add? Does it tell you anything that the code does not? Indeed not. Zero points. This kind of gratuitous comments is all too common, and if you have many of these, will you keep reading them? Will you not start to blank out the comments in your mind, thereby possibly missing the important comment that actually does explain a certain coding decision?
Please, only comment if you have something to add!
Would you not agree that having a very low count of comment lines is actually a good metric for quality? That it can be indicative for code that expresses intent very well, with a logical design?
Good code only rarely needs comments.

Martin Fowler, in his book Refactoring, indicates that comments can actually be a smell:

When you feel the need to write a comment, first try to refactor the code so that any comment becomes superflouos.

What are your comments?


May 27, 2008

Geek night out

Filed under: .Net,Events,Programming — Freek Leemhuis @ 12:01 pm

I went for a ‘geek night out’ yesterday to the Language Café at Sokyo. It turned out to be a very interesting evening. First of, Rob Vens spoke about the evolution of programming languages. Rob’s an interesting cat: rather than focusing on technical details he will speak at length on topics as General Semantics, Science Fiction, technology in general and a host of other subjects. Rob likes to get on his soap box and talk about his favorite subjects, and it made for an interesting tour through history. Plus we got a host of reference reading material.

One of the key points I’ve taken from the talk was: the near future in programming is all about ‘Back to the future’: most innovation that will take place will be driven by ideas that have been explored previously in earlier platforms and languages. Rob’s idea is that in the beginning of computer science people were more open-minded and ideas more innovative, and the focus has since shifted to making small improvements, rather than following big ideas.

When we broke up into different sessions, with tracks on Java, C#, Erlang and Smalltalk, this idea was confirmed by the subjects that were discussed regarding the future directions on these platforms. Both the Java and C# track discussed how parallel computing will be brought into the language. This is an area where Erlang for example has enabled programmers to do this for over 10 years. Pieter Joost, the C# track leader, has a write-up on the parallel extensions subject here.

The other example for future directions in C# was the idea of Design By Contract, available as Spec #, a Microsoft Research project. This style of programming has been around in Eiffel since the 80’s, so again it’s nothing new per se, but it’s interesting to see how we could use it to improve our code when applying the principles to the ‘modern’ languages on the .Net platform.
In the current download you could write statements in C# like

class ArrayList { void Insert(int index , object value)
requires 0 <= index && index <= Count otherwise ArgumentOutOfRangeException; requires !IsReadOnly && !IsFixedSize otherwise NotSupportedException; { . . . }[/sourcecode] The keywords requires, otherwise etc. are used to extend the signature of the method to include a contract that specifies the values that are allowed, not allowed, exceptions that are returned etc. Read the research paper on Spec # for full details.Voices from the Microsoft camp have stated that these extensions are not likely to be released as extensions to the C# language, but rather as additions to the framework, so you can imagine this will be made available as attributes and asserts rather than the keywords you can use in the current download. It will be interesting to see how this will affect the process of Test-Driven-Development: instead of writing your test first, you would write your contract first.

Will we move from TDD to DBC?

Blog at WordPress.com.