In your search for achieving excellence in creating software you might have come across one of these statements that 'code is an art' or something in that fashion. Although these statements are very appealing, I believe it not to be true. I will explain why. First let's start with the reasons why a computer programmer (or coder) is considered an artist and it's product (code) art. Writing code is labour intensive and various attempts have been made to automise the coding process through the use of high-level visual languages or application-generator tools. They all fail. Why is this? Because writing code is a complex and, most importantly, creative process. The same reasoning explains why there are still no good pop-song-generating software or fancy automatic movie generating applications. Maybe this will come one day, but this area is still in its very early infancy. Still, the coder can be considered an artist because he or she is creating a product through an undeterministic and creative process where the exact outcome is not clear upfront. Just like musicians or novelists. So, if writing code can be compared to creating music, writing a novel or painting ... then why can the code not be considered an art? Music certainly is art, and so is a well-written novel. The important, but subtle, difference is this:

The value of art is determined by the art itself. Whereas the value of code is not determined by the code itself.

To restate: a painting is perceived beautiful based on the painting itself. Music is valued via the music itself. In contrast, a software product is not valued on the code itself, but on what it does. No user really cares whether you have an elegent recursive call, or a three-tier architecture. Software should work. We should never forget this. Surely, your colleagues may be impressed by the sheer elegance of your code, but your users certainly won't be! The goal of a musician and its audience are aligned: to create beautiful music. The goal of a coder and its audience is not, there is a clear mismatch and that makes it more difficult to create good software. Most programmers out there, if not all, enjoy writing beautiful and elegant code. Which is a good thing because elegant code tends to have other convenient properties such as easy maintenance, reusability, self-documenting, etc. But let's not forget that this is not the primary goal our users have; just create software that works.

One of the most overlooked aspects in any software project is the end-user (e.u.) documentation. Can you recall how many (web)applications you have encountered that had proper e.u. documentation in it? I for one cannot, even though the (web)applications are getting more sophisticated and more complex every day. And to be honest, the software projects I create often lack proper documentation as well. So why is this the case? There are a number of reasons that I can think of:

• Typically developers don't like writing end-user documentation. It is just way cooler to create new functionality than write about functionality you have already written.
• Developers are not the right people to do it anyway, you need a customer-perspective. That is where the role of a technical writer comes in.
• E.u. documentation is often written when a product is already finished. When the development of a software product is already over-time and over-budget it is extra hard to convince the customer or projectmanager to put even more time and money in it to create proper documentation.
• The available tooling is not sufficient or well-known enough

Just some pitfalls here. But most people do agree that end-user documentation is important. For the acceptance of any new system it is a vital part.

How can we adress these problems? On my quest for the right tooling I have not found many good products. There are soms tools that let you generate documentation help files, or even create tutorial videos. But they are by their nature very loosely coupled with the actual software product and development process.

As part of my education I have enrolled into a course where I will be able to explore this problem more in depth, and provide a solution for it. My idea is to create a usable tool that can be pragmatic used in an (agile) development process and establish the link between the developer and technical writer. Furthermore, I want to be able to make e.u. documentation part of the build process and also be able to break a build if the documentation is not correct. In the coming weeks I will think hard about how to create this philosophy into a concrete product. I will keep you updated!

Ah, so finally Microsoft has also taken the road towards the Model-View-Controller pattern. Scott Guthrie talks about it in his weblog. It was a matter of time ofcourse after the self-proclaimed success of Ruby-On-Rails and the popularity of unit testing. One of the most important motivations that Scott mentions in his articles are 'seperation of concerns' and 'designed for testability'. Let's take a look at these two:

Seperation of concerns. The tradition ASP.NET model, using WebForms, had already a form of seperation. Namely between the HTML template (.aspx) and the code-behind (.vb or .cs or which language you have chosen). However, often you still end up inserting a lot of UI logic and business logic in the code-behind. Mainly because it is just so much more convenient to have all your UI logic in one place, instead in both the .aspx and code-behind file. So it boils down to this; no, the .aspx and .cs are not really seperated. In fact, I often just see the .aspx as a more convenient way of declaring controls, instead of programmatically adding them in the code-behind. In the last couple of years I have barely done anything more in the .aspx except for writing the HTML controls. That is right, I never use the designer. It is a huge frustration to me and I feel I have no control, whatsoever. The development time you win by using build-in grid wizards and such is often minimal compared to the time you lose to get the html output correct in the end.

Seperation of concerns is a good thing. Because most importantly, it eases your mind since you only have to focus on one aspect at the time. The code tends to be more cohesive, more readible and better understandable. Besides that, you automatically gets a better reusability of the components you write.

Designed for testability. This is still a big thing not well done in development nowadays. It is just very hard to test the UI. That is exactly where the user comes in and where things get fuzzy. Difficult to automate and therefore difficult and time-extensive to test. The basic idea to improve testability is to make your UI as dumb as possible. Also known as a passive view. The layer that renders your HTML should be thin-sliced over and over again, untill it does nothing more than just rendering some tags around provided text. The idea is that you might have errors in this thin layer, but you minimize the change of this because most of your code will be in another testable layer. UI testing is difficult, but this might just be another step towards software of better quality.

When I read about the MVC framework in ASP.NET I did not see a lot of really cutting-edge features. Actually, I have already built most of these features into ASP.NET right now. I build my .aspx as passive views. I design my controller classes in another library. Which makes use of the object-oriented model, which is generated by an O/R mapper. I have been working with this design for the last year and it has been very satisfactory. I notice that I get less erors in my applications, not only because of the increased testability, but also because of a more seperated approach in the design which provides me a good overview and makes me feel in control.

The only thing thas been bothering me lately is the asp.net WebForms model. It is just a pain in the ass to create a lean and mean performant application with this model. Especially the viewstates put a huge burden on this. I think a lot of asp.net developers experience this, because it just is too easy to drop some controls, enable viewstate and do continuously postbacks. But it just adds too much overhead. That is why I am looking forward to the release of this lightweight framework. Not because it is very revolutionary, or that you can do things with it which are not possible today, but to get rid of all this extra drag you get with the WebForms model. The time has come to take back control!

A small wave has hit the developer community this weekend about a clash between two lead developers: Chris Wilson of Microsoft's IE team and and Brendan Eich of the Mozilla foundation. The dispute is about the acceptance of ECMAScript 4; the proposed successor of Javascript. Wilson wrote public doubts about this standard, which let Eich to write a public letter in which Microsoft is being blamed for being reluctant and passive in the development of ECMA4. The debate is interesting, but we have to keep in mind that these are two individuals fighting over this dispute; there are no official positions here. However, I want to leave this aside (I know too little about the dispute as well to make sound arguments), and focus on how I perceive the future of client-side scripting.

As a programmer, I have always been a little bit relucant in learning Javascript. I get the same feeling when I work with Visual Basic. There is something... uneasy about it. The last couple of years I have mainly been programming in modern OO languages such as C++, Java and C#. A procedural language such as Javascript forces me to make such a leap in my approach and thinking that I feel being held back by the language. But I have the same with C. So, clearly it is not the fault of Javascript. In fact, I think Javascript is a good language in that it is easy to read because of a nice syntax, it has good scripting properties such as dynamic typing and it offers a lot of expression.

The question raises.. why is there the need for a 'new' javascript? The main force behind it, is to make the language more 'professional'. Make it more object-oriented, advanced exception handling, templates, etc. Indeed, these are things that are very important for any application of reasonable size. But is it important for Javascript? I have never used Javascript outside the webbrowser. In fact, I think most of the Javascript I use is either developed by a 3rd party or generated on-the-fly. Ajax? I use convenient libraries that abstract me away from the low-level javascript.

An article bij Joel Spolsky on the newSDK made me think about the role of Javascript nowadays. It is a great thing that almost all browsers support Javascript. Could you imagine all browsers supporting a language like, say, C++? Most C++ compilers don't even support the langague the full 100%. I am sure that the software engineers at Mozilla do not want to spend their time supporting a huge and complex language like that. The reason Javascript is so widely supported and popular is for the same reason the C language is still widespread today. It is the biggest denominator across languages, OS-es and browsers. If you write something in Javascript, there is a very good change it will be supported by the platform a client uses. The same is true for the C language, it is extremely powerfull because of the universal support. Even if the C language in itself can be considered obsolete by modern standards.

I believe that we should keep an easy, intuitive, flexible and powerfull language that can be executed for all browsers on all platforms, including new technologies such as PDA's and small mobile browsers. If you want higher-level constructs, you can use high-lever languages and 'compile' them down to javascript. For example, I could specify application logic in C#, which would then be outputted as Javascript in the final output. We can see the same in many smaller domain specific languages which transform a higher-level program into a c-program, which can then be compiled almost everywhere.

I do not believe that adding higher-level constructs into a language such as Javascript will make developers leave their current language and switch to Javascript. Surely, it would be more convenient if you were actually creating client-side javascript by hand. But in my experience, that doesn't happen a lot. But it would make it much harder for current browsers and future browsers to provide a (correct) implementation. You do not want a browser to implement a virtual machine just to be able to run an advanced javascript.

Sommige mensen vinden het een beetje vreemd dat ik een persoonlijke domeinnaam heb geregistreerd. En vervolgens: je wilt toch niet dat iedereen alles over je weet?! Mijn reactie daarop is vrij eenvoudig: die informatie is er toch al. Ik wil het gewoon graag onder controle houden. Iemand die echt anderen wil uitpluizen kan via een aantal simpele zoekacties al een heel eind komen. Alles wat ik niet te verbergen heb, hoef ik ook niet te verbergen, dus ik kan het net zo goed overzichtelijk bij elkaar houden.

Wat heb ik dan wel te verbergen? Enkele voorbeelden:

• Ik ben vrij voorzichtig met het online gooien van persoonlijke foto's, zeker als er ook anderen opstaan.
• Ik ben voorzichtig met het plaatsen van (informele) sterk politieke uitspraken
• Informatie als wachtwoorden, geldzaken, bepaalde telefoon nummers, etc.
• Informatie die sterk vooroordeel inspirerend is

Waarom ik voorzichtig ben met dit soort dingen? Denk even met me mee: wanneer er persoonlijke informatie van jou op het internet komt dan heeft die informatie enkele unieke eigenschappen die je niet terugvindt in 'offline' informatie:

• Het blijft voor een lange, zeer lange, tijd online.. en het raakt snel buiten je controle. Denk hierbij aan google cache, mensen die files offline opslaan, verspreiden via p2p netwerken, etc.
• Het is verschrikkelijk eenvoudig deze informatie op te zoeken, te indexeren en te koppelen.
• De informatie die je nu online zet kan straks, in een geheel andere context, volledig misplaatst zijn. Bedenk bijvoorbeeld of je foto's van je wilde feesten nu, nog steeds gewenst is als je straks als ambassadeur aan de slag wilt. Of als je in een vlaag van jeugdige opleving je begeeft binnen extreem-linkse, of extreem-rechtse kringen, in hoeverre beinvloedt dat je carriere later, ook al kan je gedachtengoed geheel veranderd zijn.
• Veel online informatie is geheel contextloos. Dit werkt veel vooroordelen in de hand. Hoeveel mensen zullen al niet afgewezen zijn voor banen omdat werkgevers snel op Hyves iets zagen dat hun niet beviel. Het probleem hierbij is niet dat je niet jezelf moet zijn, het probleem is dat je geen kans krijgt om iets uit te leggen. Op basis van halve informatie, zonder context, wordt er over jou beslists en buiten je macht om.

Een vriend tipte me over een (nederlandse) zoekmachine, wieowie.nl. Hier kan je allerlei online informatie van personen vinden. Omdat ik een vrij unieke naam heb, is de gevonden informatie over mezelf zeer relevant. Al kan ik nu al zeggen dat het telefoonnummer niet meer werkt.. De site veroorzaakt blijkbaar wat ophef aangezien mensen zich opeens aangetast voelen in hun privacy. Feit blijft dat deze zoekmachine niks illegaals doet, het maakt het enkel makkelijker om relevante gegevens op te zoeken. Wellicht zet het meer mensen aan het nadenken over hun digitale identiteit en de belangrijke impact van alle online informatie. Ik vind dat de wetten wat betreft privacy wetgeving nog steeds onvoldoende zijn. Als software developer mag ik vrijwel alles doen met persoonsgegevens (analyseren, koppelen, verkopen) zonder dat iets of iemand mij hierbij op de vingers tikt. Ik hoop, en verwacht, dat hier de komende jaren verandering in gaat komen. Je wilt toch niet dat straks ook je medische gegevens via wieopwie.nl te vinden zijn?

Zoekmachine voor personen - Wieowie.nl

I recently wrote an article about the concept and implementation of something which I call Role-Based Security in a Hierarchical Environment . It is a form of RBAC (Role-based access control). However, it also takes in account a context object (on which item is my function performing). And role permissions cascade down the context-tree. So having a permission on a certain context object means you also have permission for all underlying context objects (or not, depending on the role parameters). A typical use of this kind of security framework is in a traditional filesystem like NTFS.

In the article I outline the basic concepts behind it and an implementation in SQL Server 2005. The basis for this article is an implementation done in a recent production-ready webapplication. And it turned out to be a very effective way to deal with both partition issues, such as multiple clients in a single database. And security issues: making sure the users do not perform actions they are not allowed to do.

My intention is to write more articles like these in the future, thereby giving a little bit back to the development community of which I have taken so much already.

Links:

PDF article

Article on CodeProject