I seem to be having the same conversations with the dev teams whenever I switch clients. The topic of this post is one that many people have written about before. I’m just going to put my opinion on my blog so I can refer people to it in the future instead of having to repeat myself every time. What prompted this post is that since I’ve moved to Belgium I’ve had to take a step back from living on the bleeding edge and using open source projects. Most of the work is concentrated in Brussels and is at big corporates or banks not exactly what you’d see as the progressive thinkers (with reason). I guess it would be safe to say that I’ve been immersed in “enterprise” development. In short I still haven’t seen anything that is more complicated than a web app like Xero. But perhaps more about that in another post. This one is about stored procedures and their valid uses.

My current client is pretty interested in the newer technologies (anything that is out of beta) and how to put them into production. As such they use LINQ as their data layer. They follow the classic MS guidance of data logic, business logic and - the trigger for this post - stored procedures to encapsulate all the data access. People that have worked with me in the past will be able to vouch for the fact that I feel strongly against stored procedures. But before we get to why I don’t want to use them, let’s look at some of the reasons people have given me in the past why they were using them.

• Performance. Because stored procedures are (pre)compiled
• Security. They can lock down tables from being accessed by users directly but they can get to the database through the stored procedures layer
• Maintenance. You can change a stored procedure more easily than deploying a new build of your application because no compilation is needed.
• Less data to send over the wire because stored procedures can execute more sql statements at once.

All of that stuff sounds pretty great right? As I’ve said before my current client has developed their data layer in their framework using Linq2Sql. I think Linq2Sql is not too bad, at least it gets the corporates into an ORM mindset because it comes from MS which makes it a vastly easier technology to sell than NHibernate for example. But when you’re going to use Linq in conjunction with stored procedures for basic CRUD operations I think you’re kind of missing the whole point of Linq2Sql or ORM’s altogether for that matter. So there you have it, this is why I cannot resist posting about this subject although many people have said pretty much the same as I’m going to say in this post.

Credit where credit is due

The list of people below have helped me in forming my opinion on this subject. I’ve had the pleasure of having lengthy discussion on this topic with the first 3 people on the list. I consider the people on this list to be authorities in .NET development and 4 of them have written their own ORM in the past. Alex James and Andrew Peters now both work on the Entity Framework team. * Alex James * Andrew Peters * Jeremy Boyd * Frans Bouma * Ayende (Oren Eini) * Jeremy D. Miller * Jeff Atwood

Let’s look at the reasons mentioned above and work our way through them seeing how they pan out in the end and you can draw your own conclusions on the matter.

Performance

Stored procedures are precompiled

The fact that stored procedures are precompiled and dynamic queries aren’t is a complete myth. Ever since Sql Server 7.0 the query plans are cached for both of them. If you change a parameter in a stored procedure it has to be recompiled too.You can check the Sql documentation to verify that. IMHO this also falls in the category premature optimizations. It could be that you have a query that is so complex or that is a real bottleneck for your application then it might be worth it to invest the time and write a stored procedure for it that queries the database differently and as such get rid of the bottle neck but take on a higher maintenance cost.

Batching of queries and returning multiple result sets

Another argument people often bring to the table is that in a stored procedure I can issue many sql statements on the same database connection. I hate to break the news to you but you get the same benefits when you’re using dynamic sql (preferably the parameterized kind). You could issue one command that returns multiple result sets just like the body of your stored procedure. Or you could issue more than one command on the same connection and still get a very similar result.

Security

Sql Injection attacks

Another argument I keep hearing is the fact that when you build dynamic sql statements you open yourself up for sql injection attacks which isn’t that case for stored procedures. There is some truth in that but it definitely isn’t the whole truth. What they mean by that is that if you’re going to build your dynamic query by concatenating strings then you could indeed open yourself up to a sql injection attack but I’ve seen this happen in stored procedures too it’s just a little bit harder to do it there. However if you build your sql statement by using a parameterized query you get the same security benefits as a stored procedure would give you.

Different permissions on tables and stored procedures

This isn’t such a big problem. I’ve mostly seen people use one dedicated user to access the database. Lots of times there is a SOA like architecture that allows the client application to not even know what type of database it’s connecting too. I haven’t seen many places yet where they actually implement security that is that strict. So the reasoning goes if you secure your application properly then this shouldn’t be a big problem. Ayende has a more elaborate post on the subject: Stored Procedures for Security

Maintenance

This is probably a very ambiguous problem. From a development point of view this might probably be the worst argument in favor for stored procedures. However if you look at it from the POV of the enterprise it might actually hold some value. At my current client all the applications have to be distributed by a separate team, and that makes the deployment a costly scenario. That is because once your application goes into production and something small needs to change the deployment team has to go around and deploy that application again on every workstation in the company. I know about click-once but nobody has any rights to install anything on their pc which makes that pretty hard to do. Now from my POV this is the most invalid argument of all of them because of the maintenance overhead it adds. When you give stored procs to a developer they see shiny quick shortcuts to quickly get some data out and perhaps already transform some of that data in their query. That is all good the first time you have to deploy the application. But the next person needs to add a column to a table and suddenly he will have to go through all the stored procedures (at least 3 of them for the C,R and D of CRUD) to add the column. Then he has to go in the data layer of your n-tiered application and modify the entity and perhaps the methods that map to the stored procedures. Then comes time to deploy and you forgot to modify your update script with that one column you added to a stored proc. Of course this stored proc is the one that saves one of the core entities of your application and suddenly the new release is throwing errors all over the place. I skipped the part of transforming some data. As my previous post suggests: that stuff is business logic and doesn’t belong in a stored procedure.

Some more reading on the subject

• Jeff Atwood claiming that T-SQL is the assembly language of contemporary development.

Who Needs Stored Procedures, Anyways? * Frans Bouma explaining his point of view:

Stored procedures are bad, m’kay? * Jeremy Miller swearing this is really going to be his last post on stored procedures:

Why I do not use Stored Procedures

At work today we were playing around with the console.. here’s one of our experiments whilst creating a stoplight workflow (WF).

private static void FurElise()
{
        Console.Beep(420, 200);
        Console.Beep(400, 200);
        Console.Beep(420, 200);
        Console.Beep(400, 200);
        Console.Beep(420, 200);
        Console.Beep(315, 200);
        Console.Beep(370, 200);
        Console.Beep(335, 200);
        Console.Beep(282, 600);
        Console.Beep(180, 200);
        Console.Beep(215, 200);
        Console.Beep(282, 200);
        Console.Beep(315, 600);
        Console.Beep(213, 200);
        Console.Beep(262, 200);
        Console.Beep(315, 200);
        Console.Beep(335, 600);
        Console.Beep(213, 200);
        Console.Beep(420, 200);
        Console.Beep(400, 200);
        Console.Beep(420, 200);
        Console.Beep(400, 200);
        Console.Beep(420, 200);
        Console.Beep(315, 200);
        Console.Beep(370, 200);
        Console.Beep(335, 200);
        Console.Beep(282, 600);
        Console.Beep(180, 200);
        Console.Beep(215, 200);
        Console.Beep(282, 200);
        Console.Beep(315, 600);
        Console.Beep(213, 200);
        Console.Beep(330, 200);
        Console.Beep(315, 200);
        Console.Beep(282, 600);
}

In my previous post I explained some very quick wins to make your code a little bit cleaner. As I’ve been appointed an asp.net project at work at the moment I have the chance to get more ammunition for blogging :). This time I’d like to talk about properly separating your tiers so that the next person doesn’t have to go through the complete application and make changes everywhere just to make a minor change to the application.

One of the problems; one of the most time consuming that is; I’ve seen is that people are confused on what they have to put in the data logic layer and what is business logic. In my case this is fairly extreme because there isn’t an ORM tool but rather every entity gets populated by calling a stored procedure and then in the code the graph objects get set. Whether this is a good approach for fetching your data or not is not within the scope of this blog post, but I’m guessing there are more people who are facing this type of situation.

Anyway let’s start with the beginning and explain the typical n-tier architecture people seem to follow. This is not a particular pattern like MVC or MVP that people are talking about so much lately. This goes back to the guidance that can be found on the msdn website. This type of architecture is often used in combination with data sets but not in my example for this post. This architecture is generally divided in 3 parts that can, but don’t have to, run on different machines if needs be. When talking about this type of architecture people mostly talk about an n-tier application.

The first part is the data layer.

The golden rule for this one: this is the gateway between the rest of your application and the database. NONE of the other layers should be talking directly to the database but instead should be doing their talking through this layer. That means if you have stored procedures you provide wrappers for them in this layer. You populate your entities in this layer too. Other functions you can perform in this layer is setting the graph members (populating relationships). IMHO if you’re talking to the database (open/close connection) you’re doing stuff that belongs in the data layer which includes populating relationships.

Encapsulating this logic in it’s own layer, which could potentially be walled off through only exposing it with remoting or WCF, allows you to reuse the code in different places of your applications or sharing this data access assembly with multiple applications.

The second part is the business logic layer.

This layer encapsulates all the operations you do on entities to express the business rules. That means you would probably do most of your work in this layer. Basically all of the programming you will be doing for the business rules should be done here. Business logic doesn’t live in stored procedures, it doesn’t live in the UI or the data layer. Nope this layer is where it lives and nowhere else. This statement may raise some eyebrows but only and only when you find that a certain routine is a bottleneck and it is really data intensive you can put it in a stored procedure but more on that subject in another blog post. If you find yourself transforming data so you can display it in your GUI then you’re probably expressing business rules that aren’t explicitly stated as a business rule. When you find yourself to be concatenating strings or writing logic to translate your pages in your GUI layer then you’re probably expressing business logic (business logic doesn’t have to come from business ;) in case that wasn’t clear). Another common find in business logic is validation for example because this generally expresses some kind of strict rule that comes from the business domain your application deals with. Validation is a tricky one but the rule is you should do all validation in your business logic. To provide a better user experience you can maybe reuse that validation on the client side. In the case of web development you probably will have to duplicate that validation in javascript if you really need it.

Separating these rules into their own layer allows you to reuse the methods and classes you create in the business logic layer, in different parts of your UI or even reuse it in different applications. By separating this logic it should be easier for you to do some automated testing like unit testing and/or integration testing of that code.

The third and last layer

This is typically the UI layer but you could easily use web/WCF services as an interface to your logic. The UI doesn’t have to be a GUI it can also be a CLI (Command-Line Interface) or something. But that is how you interact with the user or external application. The idea is that in this layer you have virtually no logic except for what’s on the screen everything else should be handled by your business logic. To clarify this statement: you can show/hide UI elements or add/remove elements to the UI and respond to events triggered by user actions but the data of that response and the processing really belongs in the business logic layer.

The UI layer can talk to both the business logic and data logic layers. If for example you’re getting a category list with just an id and name from the database chances are you won’t need to transform that data so your UI can bind directly to the entities returned by your data layer. But more complex items like an invoice for example will probably need some processing and then it should probably pass through the business logic layer.

This is typically a somewhat harder part of your application to provide tests for although there are some libraries out there that make it easier but still there are easier parts to test in your application.

So that was a quick refresher on what the classic n-tier architecture is about an how it should be structured. I hope you will agree with me into stating that its not that hard and pretty straight-forward to implement, but what I find in the “enterprise” is far from the points mentioned above. It is a bloody mix of everything everywhere, leaving me thinking -come on guys it’s not that hard-: talking to the database => datalayer showing windows/adding UI elements,… => UI layer everything else => business logic

Failing to abide by the previous simple rules will result in hell freezing over, entire plagues will be released upon the world; to cut a long story short: the world as you know it will seize to exist and turn into complete chaos. Following the rules should result in less code duplication, an instantaneously easier to maintain codebase and probably more happy successors for when you move on to the next project. It should also give you a higher degree of code reuse. If there is one thing you should take away from this article then it should be: Don’t mix your tiers

Of course there are a couple of situations when you can diverge from the ideas presented in this post but you should always be able to justify why you break the rule. So you need a good reason to break the proposed architecture and that would probably also warrant a comment so the next guy also knows what’s going on. The most important part is to separate all non-UI logic out from the UI layer and put it in one of the lower layers.

Thanks for reading Ivan - writing for more maintainable software -

Rant Alert

At my current client I’ve got to do mainly maintenance on existing applications. This gives me the chance to look into codebases that have been created by other people and that don’t really reflect how I would write things. That is all good though it gives me a chance to learn new ways of doing things and when I think their way is better I’ll surely adopt.

Anyway when I’m browsing these codebases I do find a lot of things that could have been done better or more correctly and that’s what I’ll be writing about a little today.

The first one is returning bools:

I’ve found this in just about every project I’ve been in:

public bool IsNull(){
  if(obj == null)
    return true;
  else
    return false;
}

The snippet above is a very long winded way of writing. IMHO this hurts readability and you’re saying the same thing twice. obj == null already returns a bool it makes no sense writing it again.

public bool IsNull() { return obj == null; }

Another thing I keep seeing is very liberal use of try..catch blocks that catch all exceptions. Admittedly try..catch is cool but it should be used at times you are actually interested in the exception that is thrown. But it shouldn’t be used as a safeguard to swallow exceptions you don’t want to fix at this moment.  I keep seeing this code in projects:

try{
    myBLObject.FindSomething(someId).SomeMethod();
}
catch(Exception){
    // Nothing to be done but error stops
}

Now that can be easily written so that it won’t throw an exeption and then the try catch isn’t necessary anymore at all. Try..catch blocks most certainly have their use but throwing and catching exceptions definitely hurts performance because the system has to generate a complete stack trace etc. for every exception that is being thrown.

var result = myBLObject.FindSomething(someId);
if(result != null) result.SomeMethod();

The code becomes a lot more readable, not to mention faster. I’ve seen this being used in OnRowDataBound events etc on grids with 500+ rows, removing the try catch blocks more than doubles the speed of that page.

The next one on the list is using if,else and switch statements. They are sometimes a cause of code bloat. To put it in the words of Scott Hanselman:

I think that using only if, for and switch is the Computer Programmer equivalent of using “like” in every sentence.

Scott does a great job explaining why they can be pretty evil so I’ll just leave you with a link to his post

I have another couple of posts in the making on this subject but I had to get this out of my system. These are also very quick wins the other things I’m going to talk about are application architecture and stored procs….

Manning published my white paper – or green paper as they call it – on IronRuby.

You can find it here: http://manning.com/free/green_carrero.html

This paper tries to give you an introduction on what the ruby language is and how it could work for you. If you want to know more than what’s on those pages there is always the book: http://manning.com/carrero

Technorati Tags: IronRuby

I thought it might be a good idea to update you guys on how IronNails is progressing. I think I’ve got it so that you aren’t exposed to writing many of the boring boilerplate code that comes with taking this approach (M - V - VM- C). Also to execute an action on a controller asynchronously you can by just adding :mode => :asynchronous to your view_action declaration.

A lot is still left to do but this proves that it is possible to use IronRuby today to do some pretty cool stuff. From the top of my head here are some things that still need to be done:

• The ability to load xaml from an assembly like the one that is generated when you use Blend for your design.

• More predefined behaviors

• Templated generators

• Silverlight support

But the core of the framework is working. Now it’s a matter of extending the functionality. Some of the features the framework does support

• Binding to controller actions through commands

• Binding to controller actions through event handlers on the view proxy

• Asynchronous execution of actions

• Timed execution of actions

• Binding to models

I will be developing my sample for my chapter against this framework and will add the pieces I’m missing as I get on.

Some of the things I foresee that might need to be added are:

• support for controlling the application from an IronRuby console so that you can interact with the interface as it is running.

• support for a console to interact with the code of the application.

• support for plugins

So after all these lists how would an application look like when you are developing it?

The controller:

class DemoController < IronNails::Controller::Base
  view_object :status_bar_message, "The status bar message"

  view_action :change_message

  def change_message
    @status_bar_message = "#@status_bar_message appended"
  end
end

The ViewModel:

public class DemoViewModel : IronNails.View.ViewModel { }

The View:

<Window
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:behaviors="clr-namespace:IronNails.Library.Behaviors;assembly=IronNails.Library"
    Title="Window1" Height="300" Width="300">
    <StackPanel>
        <TextBlock Text="{Binding Objects[StatusBarMessage].Value}" ></TextBlock>
        <Button Content="Click me" behaviors:ClickBehavior.LeftClick="{Binding Commands[ChangeMessage]}" />
    </StackPanel>
</Window>

There are currently 2 dictionaries available to the view. One that contains the models (Objects) and one that contains the commands (Commands). The value of an entry in the Objects needs to be observable by implementing INotifyPropertyChanged and that is what’s responsible for the binding syntax Objects[ModelName].Value

At this moment there are only a couple of behaviors implemented: LeftClick, RightClick, DoubleClick and Hover.

The framework expects that you follow the basic naming conventions of the technology you’re programming in. So in ruby you underscore names but in C# and xaml you camelcase them.

By defining an object with view_object :object_name, default value you define it with a default value that you can change afterwards in the controller actions. By defining an action with view_action :action_name, :mode => :asynchronous you tell that framework that you want to link a method or a block as a controller action and execute it asynchronously.

I finally managed to figure out what the insert key is on my macbook pro. I missed it a lot because in Resharper the standard command to generate code is Alt+Ins. This key combination seems to be engraved in my brain because it was really hard for me to use it with a different key combination. Anyway the winning combinations are:

Insert: fn+return

Alt+Insert: fn + alt/option + return

For my book IronRuby I’m working on chapter 4. That chapter is about doing WPF development with IronRuby. I started out with a straight port of Witty to IronRuby. As I was doing that the cogs started turning and I came up with a way to bring the rails style of development to WPF. I decided to investigate that route a little bit further and now I have a small framework that enables you to write WPF applications with the MVC paradigm. I decided to open that code up as open source and host it on github.

At first I used the name Sails for my framework but it turns out there is java clone of rails that is called opensails. So to avoid confusion David M. Peterson proposed the name IronNails.

On Sat, 02 Aug 2008 08:00:44 -0600, Charles Oliver Nutter wrote:

FYI, there’s already a framework named “Sails” for Java:
http://www.opensails.org/

For the sake of sticking to the “Iron” theme, why not replace the ‘S’ with an ‘N’ and go with IronNails. ;-) Maybed it’s just me, but if given the choice, I’d much rather nail it than sail it any day of the week. :D

–
/M:D

1. David Peterson

You can find the project here: http://github.com/casualjim/ironnails

At this moment it’s definitely not finished at all, but it does work. The remainder of the week I’ll move my previous demo code onto this framework, update the code samples in my chapter and finish the content. I hope I will have all of this done by the end of next week.

Back to the IronNails project:

Because DLR objects cannot be used to bind to in WPF you have to define a skeleton of the ViewModel in C#, but this will change in the future. When that changes I’ll look at extending the framework to make use of some other WPF patterns like defining a DependencyObject and Behaviors. Once those are defined you get a very clean separation between design and behavior.

This is abstracted away from you but in the background the framework works with the View - ViewModel - Model - Controller pattern although I’ve tried to keep your exposure to the view model to a minimum. The framework follows naming conventions per language. So in C# and XAML you camel case stuff and in IronRuby you underscore stuff.

The very core of the framework is defined in C# but most of the code is IronRuby, depending on how hard it will be after the DLR RTM’s I may look at adding support for all the DLR languages.

IronNails

IronNails is a framework inspired by the Rails and rucola frameworks. It offers a rails-like way of developing
applications with IronRuby and Windows Presentation Foundation (WPF).
This framework uses the pattern Model - ViewModel - View - Controller (M-VM-V-C). It should be able to run on both WPF
and Silverlight.
The idea is that the views can be created using a design tool like Blend for example and just save that xaml as is. The
designer should not need to use anything else than drag and drop to create a GUI design. The behaviors are then added to
the view by using predefined behaviors in the framework or by defining your own behavior.
The framework then generates a proxy for the view which will be used to transparently wire up the commands in the
behaviors to controller actions.

You are now able to write the following code for a controller:

class MyController < IronNails::Controller::Base

  view_action :show_message, :triggers => :my_button do
    MessageBox.show "This is the great message from a block"
  end

  view_action :change_color, :triggers => { :element => :my_text_block, :event => :mouse_enter }
  view_action :reset_color, :triggers => { :element => :my_text_block, :event => :mouse_leave } do |view|
    view.my_text_block.foreground = :black.to_brush
  end

  view_object :people, Person.find_all

  def change_color(view)
    view.my_text_block.foreground = :red.to_brush
  end


end

At this moment the project has 0 unit tests, it has below minimal documentation and it still needs a work like defining the behaviors. I have to move on with my book but intend to continue developing this framework after my book is finished and IronRuby RTM’s. There are some more workarounds in the project that will all disappear as IronRuby progresses.

Technorati Tags: IronRuby,IronRubyInAction,IronNails,WPF

Tonight is my last night in New Zealand. Tomorrow I will fly back to Belgium to see what has changed in the 3 years that I’ve been away. I already know that my home city Antwerp has changed a lot because they were completely redoing the place when I left. I think it might still too soon for a reflective post on my experiences in New Zealand. What I can say is that I had a great time here and I made some great friendships with some extraordinary people. Depending on who you ask this is a good or bad thing but I’ll surely be back in a couple of years :)

The first one on my list of great Kiwi personalities is Alex James. We had a whole bunch of architectural discussions and many of his ideas are still sitting in the back of my mind every day I write code. I met him at a point in my programming career when I was looking for something new. I didn’t want to use datasets any more, was looking for a replacement for webforms and he had quite a clever project Base4. This project is what got me started on Open Source and at this point I wouldn’t mind making a living working on open source projects I just don’t know quite yet how to start that :)

The second one is Alex Henderson, he knew and probably knows a lot more about Castle’s windsor than I do and through some kind of blog conversation about using Base4 with Castle I finally got what Alex James meant when he said my code was quite monolithic at times. Alex Henderson showed me how to write readable code for other people than me. Very sometimes I know still catch myself writing big chuncks of code in one go but thanks to resharper I can quickly fix that now.

Furthermore there is the wonderful bunch of people at Xero. I had a great time working with them and figuring out what my strengths are as a developer. Although we didn’t always saw eye to eye Kirk taught me that security goes way further than just the data. Security has to flow through from the whole company and all the way into the lowest level of your application. He was probably the voice of reason I often need and when I was programming other projects after I left Xero. I still thought to myself: would I be able to get away with uploading this and seeing what happens or should I really test this on a different non-dev machine. Then I see that look he gets and will dilligently grumble and test the thing, which, as it turns out, is almost always a good idea.
Everybody at Xero were really great collegues and there are times that I regretted going away there even if it was just for the cool bunch of people that work there. Craig for letting me see that “the Hutt” is the closest thing Wellington has to “the hood” and that the word box has more than one meaning.

Of course there are the guys from Mindscape, all brilliant programmers. I don’t think you’ll find another company in New Zealand that has that big of a brains/person ratio. I’d say if they can’t solve it for you nobody can. I’m sure we will stay in touch. The discussions I had with Andrew Peters, Ivan Towlson, JB and JD really upped my game as a programmer. I think it’s always great to have discussions with people that have a different point of view, although I can get quite passionate about things, but I think it’s even more great if you can do it with brilliant people. That’s what my lunches with geeks were about :). Not to forget the poker nights, they were always good fun. I think I still lost some money but I now understand the game of Poker :) It’s much like real life and in my case the best advice there is don’t get too ballsy and enthusiastic too early in the game it can prove to be disastrous. Another memory from poker is “the blue stuff”, an alcoholic beverage easily mistaken for anti-freeze but it works really well ;). The hangover the day after wasn’t always that great but that’s the price you pay :)

Then there are some people that aren’t necessarily kiwi but I met them here in New Zealand. Owen Evans for showing me the light on mocking :) Simone Chiaretta, a very smart Italian programmer, his contributions to the community are quite invaluable.

I realise I left out a whole bunch of people like Keith Archibald, Jeff Wegesin, Vicky Rawsthorne and Ross McWhannel a.o. but I wanted to constrain myself to the programming experiences. I apologise too all the people I left out like the Kiwis that went to Europe before I got back: Adam Burmister and Nic Wise I guess we’ll catch up soonish :)

Furthermore if you haven’t been to New Zealand yet. I think it’s about high time you order that ticket and get yourself over here. It’s absolutely drop dead gorgeous, the natives are friendly and it’s probably one of the safest places in the world. The atmosphere here is great it’s a huge mix of people coming from all over the world, which leads to some very interesting friendships and discussions. I think the rest of the world can learn a lot from the kiwi’s on the matter of tolerance and not taking yourself too serious, as well as their acceptance and openness to different cultures and new experiences. So get over here and get yourself some kiwi outlook on life.

I’ll finish off this post with: It’s been absolutely magic mate ;)

Hei konaa raa

Michael Eaton started a meme with the question: How did you get started in software development?

Yesterday Simone Chiaretta tagged me in his post, so it’s now my turn to answer the questions and tag other bloggers:

How old were you when you started programming?

Like many other programmers I started at an early age. I learnt to read and write when I was 6 years old. By the time I was 8 a friend of my mother showed how to use the DOS command line and how to create batch scripts. This got me started to create the menu system so that my mother could also use the computer, I’ve been supporting my parents on their pcs ever since. All the books I could find in those days were in English and I’m a Dutch speaker which made reading them at 8 years old quite hard.

How did you get started in programming?

That same friend also showed me windows 1.0 and paint which was nice but more cool to me was the gwbasic command he gave me. That thing opened up a wonderful world of line numbers and goto statements which made the computer do stuff. Hmmmmm do stuff. Suddenly I could understand the books because they had code in them and I understood code.

As a kid I was more interested in soccer and playing than programming but I came back to it from time to time.
A couple of years later I got interested in girls which was disastrous for my programming time, not much later I could drink alcohol so I abandonned programming as a hobby for a couple of years. In school however I got taught Turbo Pascal which revived my interest around the age of 15. I wrote blackjack in it that year and that was my big achievement for that year.

The next couple of years I had to make do with a very old computer that wouldn’t do much. In school I got 2 hours a week of programming dBase IV (joy joy) and MS Access in my graduation year. After my graduation I started working in the hospitality sector and started partying hard, no programming for the next couple of years :).

What was your first language?

I guess it was batch scripting, the fancy menus back in those days with drop shadow boxes etc.

But I wrote snake and such around the same time in GW-BASIC which I really consider to be my first language.

What was the first real program you wrote?

I won’t count the little batch scripts etc. I guess the first program I wrote completely from scratch and without the help of a manual of some sort must be BlackJack at the age of 15 in Turbo Pascal.

What languages have you used since you started programming?

Batch scripting, GW-BASIC, qBasic, Borland Turbo Pascal, VB6, VB.NET, C#, Javascript, HTML, CSS, XML, XSL, Bash

What was your first professional programming gig?

I guess that would mean the first time I got paid. I wrote a couple of scripts and a little bit of Access for a company my father worked for when I was 16. After that it took me until I was 22 to get started as a web developper after my day job.

If you knew then what you know now, would you have started programming?

Hell yeah :) I loooooove programming :-D. While I took prolonged break during the early years of my programming life it has always been there silently calling my name. I don’t know if there is anything else in the world I love doing more as a profression.

If there is one thing you learned along the way that you would tell new developers, what would it be?

RTFM and consequently go forth and explore. And never stop communicating with the team and users.

What’s the most fun you’ve ever had… programming?

While there are many things in programming I love like learning new stuff and such. I guess for me programming is about getting into the zone. You code away and a couple of hours later you wrote something great. I also love the constant little victories :)

Now on to others

This is the time where I get to pick a couple of people. Uhmm, I pick:

• Andrew Peters
• Alex Henderson
• Ivan Towlson