Computer enthusiasts are amazingly good at producing meaningless comparisons. I came upon an excellent example: Languages Versus D. It's a Wiki page that compares several programming languages to D, a rather nice evolutionary language.  I'll pick just a couple of examples to show you what I mean by meaningless here.

The table says Java doesn't have function delegates while e.g. D, C# and Delphi do. Is this a problem? Perhaps for some, but function delegates are largely replaced with use of inner classes and interfaces. Is it a better approach? I don't think the programming community at large has yet arrived to a consensus here.

C# has Dynamic Class Loading while C++ doesn't. Well ok, the .NET BCL contains tools for loading .NET Assemblies dynamically. That's a good feature, but the truth is not really that clear-cut. C++ programs can load classes dynamically, too! Some of that may be OS dependent or based on a COM-like architecture, but hey, dynamically loading plugin architectures have hardly ever been anything .NET specific.

I could go on and on. Binary reductions rarely work, and in addition to that, the selection of comparison features is somewhat biased. Rows for language features such as class properties, multicast delegates, template/generic typing and many others are missing. A partial reason is there, too: "Don't forget that original of this page was created to praise D, so it still, even after all our modifications, contains strange features that are of interest only for whose seeking even smallest D advantages over C++/C#/Java". It's just that this disclaimer is in relatively small print in a "Definitions" section of the page.

My point? This comparison borders on being more harmful than useful. It does have many facts straight, but on the whole, it is not balanced. For example, it says C has Regular Expressions available as a library but C++ doesn't. Looking at the comments, it is obvious that somebody with only C knowledge added the "Lib" marker for C, but hey, C++ can use the same libraries. It's just that nobody considered the change made for C to require re-evaluation for other languages (or even if he/she considered it, it was beyond his/her ability to perform the double-check).

While single data items may be mostly correct, a valid comparison takes something more. The chosen values need to reflect a valid comparison between columns, not just the "correct" data. There are very few individuals who could conjure up that table by themselves (and I'm certainly not one of them!), but using a Wiki to gather the information isn't that reliable either. Wikipedia survives because it has a sufficient number of editors to merge the different perspectives. Most projects do not have that luxury. 

I certainly do not wish to bash the authors of this particular page. They've done their job, and quite likely in good faith. But good faith doesn't produce a good comparison. Pages like this are very easy to misinterpret, and the world is filled with them. We really need Annotea or a similar system to aid with pointing out the problems in various information sources. Wikis work to an extent, but are not the final solution.

Ps. To be constructive, let me suggest: If you want to compare programming languages, write series of short articles describing common approaches to everyday programming problems in different languages. It's far less fancy-looking than the red-green table, but hey - it's a complex world we live in, and proper information takes bandwidth.

Many programmers seem to be afraid of creating new terminology and concepts. This certainly has some positive consequences as well - the world has enough confusion already :-) But when wielded properly, the possibility of introducing new concepts is a powerful weapon of simplification.  In this article, I'll explore the concept a bit further.

The example

You're creating an application with some built-in user management features. You want different accounts to have different permission sets. It's becoming obvious that you commonly check for a certain pattern of permissions, namely user.HasPermissionGroup(0) where the zero represents a group identifier, something you've hardcoded as the group for the superuser level access. After writing a few dozen comments like "Only users with group 0 access can do this", you realize this makes no sense.

At that point, it's feels pretty natural to resort to naming the phenomenon of having group 0 permissions. If you have them, you're an administrator (or superuser or root or whatever suits you). The condition is now hidden under a common name. You can create something called user.IsAdministrator and reuse without ever knowing about group 0 again.

This example feels natural to most of us. I believe this is because the notion of an administrator is common enough to strike a chord even without prior knowledge of the application's domain. The true challenge lies in creating concepts which the reader cannot know and understand in beforehand.

The practice

Most applications operate in a complex domain where many objects are typically identifier by a set of conditions, not just their object identity ("Customer #1234"). Much of this can be easily expressed with proper prefixes. For example, a customer's "LastOrder" is often defined by a lookup of orders with a certain sort criteria, a "MailingAddress" is a lookup in the Addresses collection with the requirement of "Address.CanSendMail = true" (or whatever) and so on.

It helps a lot if you can use terminology that maps logically with the natural language. Previous examples do this nicely. However, it gets trickier when you have to introduce terms that are ambiguous or unknown by nature. Terms such as "primary", "preferred", "valid" and "external" are often useful but are relative by nature. For example, it would be valid to ask "external to what?" or "valid by which rules?" On the other hand, words like "last" are commonly interpreted pretty uniformly - in this case, the vast majority of people would consider "last" to mean "the most recently created".

Still, creating new terminology based on relative attributes is often necessary - it just requires some special attention. For example, if you're creating a web application that employs complex urls without fixed semantics (i.e. a request to an url can return various results based on the application state), you might want to create a notion of "a stabilized uri" meaning an address that can be used to return to this page even without the state information (such as cookies). Nobody has ever heard of a "stabilized uri", and understanding the word "stable" in this context pretty much requires understanding its negation, i.e. the dynamic nature of the application's normal uri composition.

The rules

Looking at the previous example, you need to weigh in a few factors before making the call. Here's a stab at establishing some common criteria for picking the terminology.

First, if you didn't call it a "stabilized uri", what would you call it? How would that term work in natural language ("An uri that can be used without previously set cookies")? How about APIs (GetUriThatWorksWithoutCookies)? Would your planned replacement be considerably easier?

Second, would your new concept conflict with existing natural terminology used in the field? For example, calling our stable uri an "absolute uri" would be a bad idea due to the commonly used distinction between absolute and relative uris - some words are already "reserved" or at least excessively burdened by previous associations.

Third, does the new terminology scale well? Concepts you create often turn out long-lived, perhaps even moreso than the system (as they tend to get used in the specification for the next system). Does the term have a sufficiently stable and universal definition so that it doesn't become misleading after a few rounds of refactoring? Of course, unless you're a psychic, you'll have to make an educated guess here.

Fourth, do you have the means to sufficiently document and broadcast the meaning of your new terminology? If you can significantly reduce ambiguity and complexity by creating the new term, you'll probably want to do it. But if you can't (or won't) document the new concept you've created, you should abandon the idea. Even a clumsy vocabulary beats an unclear one.  Also, you will have to be able to make the use of the new term relatively uniform and ubiquitous - if you can't, it's often better not to mess things up by adding new concepts aside the old ones.

Summary

It's not inherently bad to require the reader to learn some terminology before understanding the code. We do this all the time. Think words like "assembly" in .NET, "expression" in mathematics, "bag" in C++/Java and so on. Still, you don't want to raise the language barrier artificially, so you'll have to strike a balance. Totally abstaining from new terminology often turns your source code into a quagmire of complex expressions, thus removing the human advantage of remembering and combining concepts instead of their building blocks (often called "abstraction").

I feel many programmers do not make these decisions consciously. The gut reaction often involves initially opting for not-naming, but with growing pains later on, they then create an ad hoc name for some specific context. At this point, propagation often fails and mixed terminology throughout the project is born. I hope this article has been able to provide some tools for thinking things through at the point where the changes are still relatively straightforward to make.

If you happen to be Finnish, take a look at the new ITpro.fi community site aimed at bringing together all Finnish IT professionals. It's a long way to go, but at least there's a serious effort - something we haven't really seen before in this field. Oh, and if you're a techno-geek, you might want to know that the site is entirely built with MOSS2007...

I'm a member of the Software Development Expert Group on the site, so you can also find some of my writings in the group blog. This doesn't mean I'm abandoning my personal webspace though. I'll come up with a reasonable publishing plan one day. It won't mean regular updates, but it'll mean a rational approach to this multitude of publishing media I seem to have at my disposal.

Many oldschool SPS developers seem enthusiastic about the new possibilities of MOSS. I share some of that; the product certainly shows a lot of potential. But I'm getting more and more worried about the developer support that's going to available when the first really ambitious projects hit the shore. For example, I was trying to add a custom entry to a popup menu - a well-supported and documented development scenario. Googling with the strongly related term, ECBItem, returned two results. Neither of the documents helped. And zero newsgroup matches.

Also: I've attended some of the most esteemed Office 2007 courses held in Finland so far. For the most part, the instructors haven't been able to help with many of the practical development questions. There are white papers and even books around, but practical information is far less common.

The examples above are just a few isolated incidents, but they do tell a story: When developing with MOSS 2007, it's easy to stray into areas where you're reasonably alone. Sure, Microsoft's support will give you a hand and intensive Googling may help - but you're also exposing yourself to a lot of beta-level - or even SPS2003-age - material. Most of MOSS potential is relatively easy to unleash, but stretching its limits requires a lot of effort at the moment. It's easy to underestimate the amount of work required for some tasks - beware! The new world does come with its own dangers.

It seems to have become a common phenomenon to explain how much more you could do, how much better results you could produce, how much more talent you could expose... if you were only given the chance.

Stop whining and get to work. I'm not doubting you at all - I've struggled all my work life to carve myself a role that allows me to fully leverage my personal talents and to work the way I want to. I think I've come pretty close now, but it has taken several intermediate positions, some political work and most of all, swift, well-planned and courageous moves - including giving up or turning down a few management positions.

Proper casting - that is, the matching of people's talent and the requirements of different roles - is a key element of an organization's long-term health. Your manager should do everything he/she can to put your abilities into use and maximize your motivation. On the other hand, you are the specialist when it comes to your dream role, and it's just possible that casting isn't your manager's forté either. You are the one who should actively pursue your ideal job.

If you've done everything within your power to lobby your ascension to the dream role where you'd actually be at your best but still can't reach it, you have exactly two choices: Swallow your pride and become a content average worker - or change the scenery. I recommend the latter, as life is a bit short to be wasted. But do remember the realities: It's not like the next company were much more likely to automatically cast you correctly just based on your interview. Be sure to work hard enough so that you really know you've done everything you can.

Much of today's work life is total chaos in a positive way. Most of the things you want are available for grabs, but often you must stretch yourself - not just once, but for years. Selfish gain-seeking won't work for long, but balanced and responsible plans tend to execute more smoothly. Spineless worms will end up doing what they're given - active participants in their social environments tend to end up in the chooser role. Get out there and be the change agent!

If you are a Computer Science student, take heed:

When you're about to take on an assignment that takes more than two hours to implement, do Test-Driven Development. (that doesn't mean you couldn't use TDD in smaller assignments if you feel like it)

First of all, what is TDD? It is a philosophy that encourages you to create runnable tests before you write code that they test. Of course, the tests won't even compile, but the mere act of writing them forces you to think about your code and its interface - "How would I go about using this B-tree class I'm about to implement?".

TDD documents often refer to sophisticated unit testing frameworks to support automated testing, but forget about that for now. Focus on the testing. Write console applications that do stuff like if (MyTools.Sum(3, 5) != 8) throw new Exception("Sum is incorrect.") for all your relevant methods. If you write more complex stuff, such as a linked list, write tests that insert some items and then read them out, verifying that everything works as you expected.

Now, why?

• You're about to write code that you're unfamiliar with. To be honest, it is likely you have never written an application of this size with this technology before.
• You have a desire to get rid of the application as soon as possible. This means that you, probably a reasonably inexperienced programmer, will make many mistakes in a hurry. It also means that every uncovered bug will slow you down seriously.
• University-level assignments in particular often require an academic pedantic attitude. Such attention to detail is often best left to a computer. You couldn't check for all the details anyway.
• If you're implementing your first data structure / algorithm / whatever, it is likely that you're partially copying your code out of examples and text books. Doing that, you often skip a critical step in understanding. That slip won't save you time, trust me. Doing TDD will force you to understand what you're coding, which will save great amounts of time at a later phase.
• Since just writing tests will be somewhat boring (at first), TDD will encourage you to test the application more often. And passing even a minimal test suite will encourage you to code more.
• Unit tests tend to pinpoint errors rather exactly (at least compared to C++ segfaults and other hard-to-debug exceptions).
• Assignments often require documentation and testing (eww!). It's easier and considerably less frustrating a task when done during the coding. And saves a lot of late-deadline hassle, by the way.
• Good unit tests score well.

So: Write a small chunk tests, then write (or copy/paste) code. Fix the code until the test passes. Then repeat until you're done. If you discover bugs not uncovered by your tests, write a test that fails because of the bug before fixing the bug. That way you'll never fall for that particular trap again.

Most of the reasons above can be used to argue for unit testing in professional programming as well. However, students should consider TDD doubly because: a) TDD saves lots of personal time and students suffer from no corporate friction to offset the savings, b) they are generally unfamiliar with what they're doing and c) they lack the general experience required to guess the location of errors, thus resorting to time-consuming WriteLine-style debugging.

If you try it and like it, learn to use a proper testing framework. It's easy when you already have the TDD mindset ready, and any automated testing environment will make your coding yet easier - even when you move up to professional coding one day. And yeah, it looks good on your CV. And we need more programmers that have been trained to think about testing and their mistakes right from day one.

As the fall progresses, some changes are beginning to affect my life. Finally, one might say! The most important of them is the fact that I'm slowly getting into the job I'm supposed to do. I've been the Chief Software Architect at our company for half a year now, but much of what I've been doing has still been linked with the past and the strains of everyday projects, thus leaving much of the real company-wide architecture planning into a side role.

That, I hope, is now changing in a more permanent way. The project tide is slowly turning away from me, and my focus - as well as the focus of my closest colleague, Sami - will now gradually shift more fully to the more generic productivity and technology issues within the company. What does this mean? In practice, we have three focus areas:

• Company-wide technology strategy and product architectures
• Discovering, supporting and teaching best practices in the company's current implementation projects
• Software development processes, agile methods in particular

While all of this has been in our agenda for the last half a year or so, the forthcoming changes should provide us time to actually realize some of the thoughts we've come up this far. We expect it to be both fun and productive.

On another note, my fiancee Riikka is starting her new job tomorrow as a System Designer in TNS Gallup, a Finnish branch of TNS Global. All of this is new enough not to have made its way even onto her home pages ;-)

Flux indeed!

There used to be a time when spamming was limited to mass sales articles. Viagra and things like that have an immense marketing potential, and at least I could convince myself to believe that the spam-based sales originated from less advanced home users who didn't realize the global impact of the economy they were feeding. My beliefs have suffered serious blows. Although majority of the spam is still aimed at mass markets, there's been more targeted stuff too.

Today an ad from a French software company called Novalys managed to squiggle through my double spam filters. It says "Dear .NET user" at the beginning, and is sent to my email address used exclusively for newsgroup postings. The signature even says "Microsoft partner", and the footer assures "You're receiving this email because we thought you might be interested in VG news"... Well thanks, but you're obviously mistaken. While something called Visual Guard certainly sounds interesting, I don't need it.

Well, what can I say? Avoiding dealing with organizations that rely on destructive marketing measures is something I can do. I wouldn't place my spam ethics before a customer's benefit, but in a 50-50 situation I'd definitely tip the scales against somebody who blatantly ignores the Internet rules of conduct (and some legislation, too). I hope many of you will do the same as well. Software developers need not support this sort of dark economy. Truly excellent products have many great - and free - advertisement channels already.

According to Wikipedia, "Refactoring is the process of rewriting a computer program or other material to improve its structure or readability, while explicitly preserving its meaning or behavior". Since the agile culture emphasizes refactoring of the code as necessary, it does set a new stage for code quality demands: How relevant is the initial quality of a code block? Can't refactorings be later used to "restore quality" as considered necessary? Is "high quality up front" an anti-agile beast on a level equal to "big design up front"?

"No!" screams the choir of agilistas. High quality has always been in the limelight in the agile methods community. The desire to use refactorability as an excuse for lowering the quality bar is cowboy coding, a mutilation of the agile ideals. In fact, quality is refactorability - only decent-quality code can be refactored, bad code must often be rewritten.

What is the true intended scope of refactoring, then? It is to avoid the need to build extensive hooks and abstractions for anticipated future needs. It is to enable flexibility that allows the design to adapt. All these ideals relate to changes in requirements or architecture, not to the quality preferences of an individual developer. If the main use of refactoring is reduced to making code conform to best practices or coding guidelines, many of the true benefits of refactoring are lost.

To summarize: Refactoring is not about using the rename pattern for fixing mindlessly named constants ("string s"). It is about turning a monolithic, bit-by-bit-grown customer object into a small class hierarchy to improve design. Be minimalistic, do what you need and only what you need - but do it with quality. If you see bad code, don't just accept "Feel free to refactor it" as an excuse - it's nothing but "I didn't care to do it properly" in disguise.

I had a pretty grueling duel with a fresh installation of Virtual Server 2005 R2. The error message mentioned above popped up on the administration web site even though the installation was completed flawlessly. I also had "You do not have permission to access the event viewer" on the same page. All Google matches returned hits referring to installations on a Domain Controller or Windows Vista.

My problem was neither of the above. Rather, the issue was that my IIS web site wasn't configured to use Windows authentication. Apparently the anonymous user didn't have access to some directory somewhere on my hard drive, although I did try the Everyone / Full Control medicine on several directories. But configuring the site to use Windows Authentication did the trick. I'm just wondering why doesn't the installer do this... Or maybe it does? The installation did work fine for me on several other computers.

Hope the experience allows somebody to save an hour or two...

Some time ago we encountered a really strange problem with ASP.NET. A site that had worked properly under ASP.NET 1.1  suddenly freaked out. .NET 2.0 was installed on the server, but no settings were changed. At approximately this time the site suddenly broke down with a "The handle is invalid" error message. It was none of the usual ASP.NET error messages, it was just that text on a blank page.

Well, this was certainly something new! I'd never before seen an ASP.NET error message without a single HTML tag, just the text. Well, as it turns out, ASP.NET never even got started (there was no aspnetwp.exe for instance, but everything failed before that).

Reinstalling .NET didn't help, nor did the usual aspnet_regiis trickery. A new IIS site demonstrated the same issue. I was pretty stumped after some googling returned only a single useful discussion thread, which unfortunately provided no answers. Well, it was again the time to send our prayers downwards... wait, no, call the Microsoft Support.

As usual, they were able to help, but we were never particularly enlightened by the real reasons. After some diagnostics, removing and re-installing IIS was the proposed cure; a considerable effort on a server with several heavily configured sites, but we managed - and it worked. We - and I think this includes the support engineer - never got to know if the .NET 2.0 installation was to blame here.

Perhaps it's time to start considering heavier backup plans on 2.0 installations, at least on the most critical servers. It's certainly not common, but pretty nasty when it hits you. Well, at least I hope sharing the experience will save somebody the trouble  of discovering this (and a support ticket).

"Does my 1.1-compiled software work if the user has Framework 2.0?" -- This has been a real FAQ for me, and I've been asked about different sorts of scenarios quite a few times since 2.0 was released. The short answer is "Yes, it works", and the long answer is "You should read the MSDN white paper on the subject". But truth be told, Microsoft did such a good job in providing runtime compatibility that these problems aren't particularly interesting - even to the point where I've seen the example of an ASP.NET 1.1 site accidentally being run under 2.0 without anyone even noticing.

That said, there are always issues that always surface when migrating. Also, version upgrades are the spot where you come into terms with all your past sins. One nasty example from the close past: you've always relied on the fact that you can get the filename of your .ascx control using typeof(this).Name. Well, that's what happened in ASP.NET 1.1, because "Foo.ascx" got compiled into something called "ASP.Foo_ascx". Well, Microsoft then fixed a bug that occasionally caused controls in different directories but same filenames to overlap with each other, and now "Foo.ascx" gets compiled to something like "ASP.MyControls_Foo_ascx" (if it resides in the MyControls directory). Changes like this are real headaches as they're not really documented - from Microsoft's perspective, this is certainly not a breaking change. It's just that you were wrong all along, trusting that class names have a relation to file names - an assumption that carries no validity when thought of independently, but one that probably made a lot of sense to the coder at the time.

When we get to the field of recompiling applications under 2.0, and web applications in particular, the Redmond-provided swamp gets far deeper. I hope to be back on the subject one day - there's quite a lot I wish to say on the suboptimal work Microsoft did on rewriting the web project model in Visual Studio.

Mind Mapping is an underestimated technique. Many have bad experiences and as a result, they are too focused on the techniques (or their lackings) involved. The true essence of mind mapping, i.e. the ability to quickly draw up association nets from your brain with little effort required in formatting, is often missed. Let me rephrase: mind mapping at its core is not a tool thing, it's about rolling the ideas out and sketching them up quickly enough.

The dislike towards the technique stems from a kind of perfectionism. Drawing a mind map with pencil and paper is hard (at first!), as you'll have a hard time figuring out the proper amount of space to reserve for a branch. As you do it more, you grow better - and learn not to care, using crossing lines and other untidy markings instead. There's much to be said for hand-made mind maps and quite a few arguments against computer-powered ones, but at least an electronic mind map doesn't suffer from the friction of reorganizing content.

Mind mapping software is often horrible in quality or expensive, possibly both. Due to my past experience, I wasn't really anxious about mapping some ideas on the screen, but decided to go for it anyway. And boy it feels good to be wrong - FreeMind is an excellent mind mapper! It is free and works well enough to be transparent - you don't really have to think about the tool.

While whiteboards and papers still rule, redistribution and editability may at occasions take precedence. Although I'd pick a good publicly visible whiteboard over email-transferred documents any day, the whiteboard concept tends to collapse with increasing distance. Now that I have a decent software tool at my disposal, both analog and digital maps are again far more appealing.

Ps. FreeMind also healed me from my distrustful attitude towards Java-based GUI applications. It's smooth enough to make one forget the Java 1.1 age software. And it's about time for that to happen.

Windows Live Writer is out, and it's another interesting innovation from the guys at Redmond. Being the dubious me, I was certain any offline blogging engine they could produce would certainly not integrate seamlessly with my years-old Movable Type installation.

Well how wrong could I be - here I'm writing this using Live Writer. The UI beats the web interface any time, and now we've also got some nifty features such as spell checking. But hey, why doesn't the spell checker recognize Redmond, rather attempting to replace it with Redondo instead.

On a serious note, a return to blogging has been overdue for quite some time. There is no foreseeable increase of available time, but the increase of things to say is making my head bulge. Perhaps this new toy will help. :-)

It chills me to see that in spite of all this, there's a monstrously long list of things I've neglected. From the top of my head: Bugzilla, ODP, Usenet, the railway hobby, this web site, more studying, more reading and staying up-to-date with what's really going on (I even read newspapers on a three-day backlog), ... The list goes on.

In situations like this, I'm usually the first one to talk about setting priorities. However, I'm having a surprisingly hard time juggling all these balls this time. Following all these diversions has resulted in no net direction - it would be rather hard to define the way I've moved "forward" (to whatever direction!) after summer. Usually it's been easy to identify some key achievements for every few month period. Now it's certainly not.

The intention of this blog post is to say I'm alive. The list of my bloggable subjects is about 8 pages long (10 pt font), so I've certainly experienced things I consider worth saying. Now I just need to find out if writing really is high enough on my priority list.