A colleague of mine showed me this YouTube video a week ago, and I thought was so much fun that I had to share it with you. Please take 4 minutes to watch the video - it’s worth it. You’ll see the comedian Louis C.K. talks about how ungrateful we are, even though we live in this amazing world with all this fancy technology that makes our lives easier to live.

Louis made some darn good points, and he made me think about how many unhappy fellow engineers I’ve spoken to lately – many. This made me thing about how it would be to work in the early days in the IT-industry, where the tools were much more primitive. In this age of the industry we are capable to create it-systems to automate most of our daily routines, but back then the computers were mostly used in the field of science. Nowadays even grandma can pay her bills using a web browser without leaving her home to visit the bank. This enables her to spend more time doing whatever she think is important, like watching her grandkids. This made me think about a quote I read in The Pragmatic Programmer.

“Civilization advances by extending the number of important operations we can perform without thinking.” - Alfred North Whitehead

So let’s do something fun; let’s have a look at how it was like to be a programmer 50+ years ago, and try to imagine how much work it would take to get the computers to “work” for us back then compared to nowadays .

Programming today and 50+ years ago

Today there are many high level general purpose programming languages. Programming nowadays is more like having a conversation with the computer, and we can express ourselves in a language similar to English.

If you use a statically typed language like C# or Java, you need to compile the code, which will output assembler code (machine code) that can execute on a computer. C# and Java are a special case, because the assembler code runs inside a virtual machine, which means that the assembler code is more high level than regular X86 assembler code. Anyway, this abstracts us away from the nitty gritty details of machine languages, which is hard to program, understand, read and maintain.

So let’s do something fun, let’s implement the Fibbonaci algorithm in C# and in X86 assembler code (machine level code).

C#

   1: class Program

   2: {

   3:     static void Main(string[] args)

   4:     {

   5:         Console.WriteLine("23rd fibonacci number: {0}", Fibonacci(23));

   6:         Console.ReadKey();

   7:     }

   8:  

   9:     static int Fibonacci(int n)

  10:     {

  11:         if (n == 0 || n == 1)

  12:             return n;

  13:         else

  14:             return Fibonacci(n - 1) + Fibonacci(n - 2);

  15:     }

  16: }

Assembler

   1: .model tiny

   2: .code

   3: org    100h

   4: rt:

   5: mov    ax,cs

   6: mov    ds,ax

   7: mov    es,ax

   8: cld

   9: push    23

  10: call    fib

  11: call    print_eax

  12: ret

  13:     push    bp

  14: mov    bp,sp

  15: mov    di,offset fib_array+2

  16: mov    cx,[bp+4]

  17: loop:

  18: mov    ax,[di-1]

  19: add    ax,[di-2]

  20: inc    di

  21: mov    [di],ax

  22: loop    fib_loop

  23: mov    bx,[bp+4]

  24: mov    ax,word ptr [bx+fib_array]

  25: mov    [bp+4],ax

  26: pop    bp

  27: ret

  28: t_eax:

  29: mov    bp,sp

  30: mov    di,offset outbyte

  31: mov    ax,[bp+2]

  32: mov    bx,10

  33: xor    cx,cx

  34: p:    xor    dx,dx

  35: div    bx

  36: add    dl,48

  37: push    dx

  38: inc    cx

  39: test    ax,ax

  40: jnz    divlp

  41: e:    pop    ax

  42: stosb

  43: loop    store

  44: mov    byte ptr [di],'$'

  45: mov    dx, offset outtxt

  46: mov    ah,9

  47: int     21h

  48: ret 2

  49:  

  50: xt  db  "23rd Fibonacci number is "

  51: xt_l = $-outtxt+1

  52: yte    db  "00000000"

  53: array db 1,1

  54:  

  55: end _start

Pasted from: http://cubbi.com/fibonacci/asm.html. Ps: I’m not sure if this code even works.

And yes, I realize that the x86 instruction set is younger than 50 years, but I thought it would be a good example, and it’s still assembler code, which is low level enough! When the C# get’s executed it’s probably going to end up looking something like the assembler code above, and that’s the main trick of compilers - they translate high level languages into low level machine code and instruction sets.

This it’s a nothing more than amazing! In the modern language I used the concepts of recursion, functions, strong typing, classes etc. Now compare it with the Assembler code, which I by the way almost seems like a foreign language to me. This modern language really enabled me to do more with less.

So if you think that the modern languages today are crappy, or they should have been different in any way, you should try to think about what if we had to implement business applications in assembler? Compilers are one of the most technical challenging problems we face in our career as programmers. I think we owe the creators of modern languages a really big thank you!

And if you are in a situation where you maintain crappy legacy code implemented in C#, VB 6, JavaScript etc. Imagine if that code was implemented in assembler - it would be much worse that you can even imagine, and it probably would end up being your worst nightmare. The only one you can blame for bad code in modern languages is yourself and your fellow engineers.

It’s not only the languages that have evolved, but also the frameworks. Today we have tons of commercial and open source frameworks, which also is a key enabler when developing high quality software. The frameworks I can come up with at the top of my head are;.NET, Java, Apache, Hibernate, Ant, CruiseControl.net, Silverlight, Mono, Moonlight, Struts, Ruby on Rails, SPRING etc. And let’s not forget the tooling; Visual Studio .NET, Eclipse, IntelliJ, TextMate, TextMate, SharpDevelop etc. And the funny part is that since we are getting better and better tools, the development speed of these languages, frameworks and tools seems to go even faster.

Nobody is happy?

So even though you are not happy with what you are doing in your daily job as a programmer, imagine how it would be if you had to maintain assembler code, how it would be to write ORM mapping by hand or if you had to use Notepad as you development environment – now it doesn’t seems so awful, does it?

But don’t fool yourself to think that’s something wrong with the languages, frameworks and the tools; a fool with a tool is still a fool! Even though it’s possible to do amazing things, programming is still something that takes hard work and lots of practice if you want to become a master. If you are serious about becoming a programmer, you should know that you have to face at least 10 years of practice to really master it. Programming is really, really hard - period. When it becomes your profession, it’s not only about creating cool stuff, it’s about creating cool stuff with high quality, and it’s the last part that’s hard. I’ve been programming professionally for 8 years, and I still feel like a young journeyman when I read books by Robert C. Martin, Eric Evans, Andy Hunt, Dave Thomas, Craig Larman, Martin Fowler etc. I realize I have still a long way to go before I can call myself a master.

So even though we can do all these amazing things, you still need to learn how to master the craftsmanship of software development, and if you are serious about it, expect to practice for a long time. You can expect much from this industry, but it will also expect much from you! So if you want to become a happy developer, you need to become a decent software craftsman, and expect plenty of work to achieve that!

Som du kanskje vet, pågår det for tiden en runde av MSDN Live, et arrangert i regi av Microsoft Norge. De har allerede besøkt byene Stavanger og Bergen, og kommer til Trondheim i morgen, før de avslutter i Oslo.

For første gang i historien nyere historie så tar de betalt for dette arrangementet, og prisen er 1500 kr. Microsoft har begrunnet dette med at de også er blitt et offer for finanskrisen, og må stramme inn budsjettene som alle andre.

Man kan jo argumentere med hvorfor i all verden vi skal finansiere Microsofts egen salgsturne? Det er jo et arrangement som tross alt genererer flere salg av deres egne produkter. Jeg velger å ikke ta stilling til denne diskusjonen, men heller fokusere på det faglige. Microsoft har skapt en knakende bra faglige arena gjennom MSDN Live. Arrangement er gjennomført med dyktige foredragsholdere og alltid relevant faglig innhold!

Børge Hansen som jobber i Microsoft forklarer på hans blogg hvorfor arrangementet koster penger.

Hvorfor delta?

I vår bransje foregår utviklingen veldig raskt, og hvis vi skal henge med på dette så må vi holde oss oppdatert på hva som skjer på teknologifronten. Selv om vi er midt opp i en finanskrise og budsjettene strammes inn, må vi fortsatt jobbe med kompetanseheving. I dag hørte jeg et morsomt ordtak av en kollega av meg, som setter denne problemstilling på spissen; ”Hvis du synes kompetanse er for dyrt… forsøk uvitenhet”. På sikt vil dårlig kompetanse koste veldig dyrt, det kan sammenlignes med og ”pisse” i buksa når man fryser; først det blir varmt i noen sekunder, før det blir ulevelig kaldt.

Selv om du må jobbe litt ekstra med å få tillatelse fra din arbeidsgiver til å stille på dette arrangementet pga. kostnad, så mener jeg det er verdt det, for din egen del, og for din arbeidsgiver. Dette er en langsiktig investering!

Så har vi jo også det demokratiske aspektet; hvis den totale oppslutningen blir for dårlig for dette arrangementet, så vil vi som teknologer miste en fin arena – noe vi ikke ønsker!

Hvordan har tilbakemeldingene vært så langt?

Jeg har lest på bloggen til Torbjørn Marø, er en systemutvikler fra Bergen og en aktiv blogger, han har følgende å si om MSDN Live arrangementet;

”Dagen inneholdt en rekke, gode sesjoner, og selv om MSDN Live kostet penger denne gangen var det relativt bra oppmøte.”

Du kan lese mer om Torbjørns opplevelse på hans blogg.

Hva bør Microsoft gjøre neste gang?

Jeg har selv ingen problem med å betale 1500 kr for dette arrangementet. På papiret ser dette arrangementet akkurat ut som de tidligere rundene av MSDN Live, og når dere plutselig begynner å ta betalt, så hadde det vært en idé og gjort noe nytt. Jeg har følgende forslag til dere på dette området;

• Inviter et stort navn til å holde keynote, for eksempel; Scott Guthrie, Scott Hanselman, Phil Hack, Jeremy Miller, Robert C. Martin etc
• Dere kunne ha kjørt et ekspert track ved siden av det vanlige, med foredrag av faglig høyt nivå, som er rettet mot ekspertene i de forskjellige byene

På denne måten hadde dere gjort noe som er helt nytt, og dermed ville det vært enklere å forsvare gebyret på 1500 kr.

As you can see, the performance is very good. And by the way, Windows is running inside a virtual machine (VMWare Fusion).

And no, Visual Studio is not pre-loaded into memory. The startup was initialized right after the machine was booted.

Here are my slides from my talk at NNUG Trondheim 26 February.

The development of the technology inside the IT business happens really, really fast, and many of these technologies have one thing in common; OO (Object Orientation).

Since OO seems to play an important role in our business, I think it’s important for us as developers to achieve a deeper understanding of the concept. It’s more to it than polymorphism, encapsulation and inheritance.

If you manage to master the OO concept, you’ll be able to “reuse” your knowledge across various new technologies like Silverlight, WPF (Windows Presentation Foundation), .NET, Java, Ruby on Rails and the list goes on. It doesn’t matter if you are coding C++, Ruby, C#, VB, or Java, all of them apply the same concept; OO. Yes, they have their differences, but that’s another story.

Not only will a deeper insight to OO help you learn technologies faster, it will help you to write better code. In my presentation I also talk about 3 of the 5 SOLID principles; SRP (Single Responsibility Principle, DIP (Dependency Inversion Principle) and OCP (Open-Closed Principle). If you don’t know them, please learn them!!

You’ll find plenty of information about good design principles here.