This Blog is On.The.Move

I decided to get my own domain and conquer the world from that base.

You can now find me at

ardonio.com

hope to see you all there!

Music

Since Studio Brussel is having a birthday party these days, I wanted to share some thoughts on music, mainly how my collection got where it is. People that were on some of my kot-parties or copied my music at ICT-Blue.lan parties (don't copy music kidz) know I have a rather wide variety of music on my regular playlist.

As far as I can remember, I've always had some thing with music. If I'm not playing myself than there's some music on (my ipod is an always-on device so to speak). I grew up with MTV, back in the day it was not yet hijacked by hip hoppers,  R&B (Rhythm & Boobs anyone?), ringtone ads, ... . The days where TMF was just rising. The times where Katja Schuurman presented "so 90's", the days where Nirvana, Pearl Jam, Bush and The Smashing Pumpkins were all the rage. I played guitar in a (rock/grunge) band for a while (the infamous "Moldy & the blasting nymphlikes"), I still enjoy playing piano and guitar (hell, I sometimes even take a 30min drive to my parents house just to play). All this to simply say: I love music, it runs in the family, and I couldn't live without.

It all started out with hearing what my brothers had on tape (yes, tape, those were the days). It ranged from early Clouseau over R.E.M. to Nick Cave. The inspirational odd piece of classical opera or French popular chanson were brought in by my parents. The parents also included some "pré historie" of late 60's (Ricky Nelson, Jewel Akens, Edith Piaff, ... ).

It's fair to say my brothers (Ardi and the not-online Zors) shaped my early taste. Add on top of that the Sunday morning ritual called "De Afrekening" on Studio Brussel and it's not too hard to see where I got my rock influence.

In the Dutch series, there was 10 om te zien, leaving me with a notorious collection of "foute muziek" (politically incorrect music, think YMCA on a straight, heavy metal, biker party, but worse). An influence that still shows today in my collection through artists like the Backstreet Boys, Take That, Bart Kaëll, Frans Bauer, various aprés ski hits (Drei Weisse tauben by EAV was an instant classic @ Casa Ardonio). Who cares, I like those songs just as much as the more established, politically correct artists.

Little rebellion I am, I dug into house music around the age of 15 (when I started going out on Saturdays). I filled my head with beats all day long. The more the better, hard and fast beats. Me and my friends were Jumping before it became a hype. Times spent in Discotheek BBC, Kokorico and Lamborghieni (simply called "De koko" and "De Lambo" because we were hip & cool and long names were so against our fastbeats life style) introduced me to a new era in my music evolution. I don't know what pulled me into it, but I think Formula had something to do with it (or at least the cover of the single)

I discovered the bliss of trance music in those hellholes. Heavenly voices, violin arrangements, long notes hanging high in the air on a solid line of slightly varying base and rhythm sections. Some of my all time favorite tracks are still the ones I discovered early on in this journey. Think about (amongst others): Delirium - Silence, Maria Naylor - Angry Skies (terrestrial vox mix), Lost Witness - Song to the siren.

For the sake of completeness, I have to admit I took the occasional wigger sidestep. Filling my collection with homies like 2Pac, P. Diddy, Nas, Eminem but also the lighter "black" music such as Aaliyah, All Saints (that's probably more "foute muziek" anyway)

All those beats started begging for a bit of counterweight and a bit more "substantial" music. Slowly, what I liked about trance started to resemble deephouse. The fact that, around that time, the internetmusic really started to be everywhere probably helped on this part of the journey. I also must pay the necessary respect here to my bro/DJ Ardixiv and the gang of KinkyPeople.

As I indicated earlier, I played piano ever since I was a little kid meaning I got some classical baggage. I still enjoy the sound of a well played piano, even on less classical works like this. Next to everything mentioned above this is a constant parallel path that every now and again pulled some classical music in. My hard drive still features a lot of Mozart (probably my favorite), Chopin, Bach, Vivaldi (what would I do without the wonderful rendition of Sposa Son Disprezzeta by Cecilia Bartoli). I recently started to go and see live opera performances. Not for the acting, simply for the live music. There's something magical about hearing opera music performed life in front of you, regardless of the acting and stage setting. It's something even the best in house audio system can't compete with.

The last part of my influence is down to my love for Italy and the language, fueled somewhat more by The Sopranos (the soundtrack is simply wonderful). One of the most memorable moments (music wise) must be the end of season 3 where uncle Junior performs Core Ngrato supported by just a guitar. Simply magical. It's not just the Sopranos that triggered it (even though they helped refueling). I was an early adopter of Andrea Bocelli, the recent passing of Pavarotti made me (re)discover his works (&friends). To top it off, here's a classic in my "Italian" list, a rendition of Caruso by Lara Fabian.

Since I'm a geek and love devoting myself entirely to videogames, It should be no surprise that I've been influenced by the following music stations:

And off Course:

That's a fairly large amount of variety in music I'd say. It pretty much ranges from heavy metal over a whole lot of mid-stream rock (some vids: Smashing pumpkins, creed, pearl jam, guns & roses, R.E.M., ...) over to the more soulful matters (more vids: Norah Jones, Sade, Erykah Badu,...), a lot of electronical influences (youtube all the way: Moby, Hotel Costes,...) to the big classics (Mozart high above). Recent discoveries include Carla Bruni, Soulshine, Vasco Rossi and Marvin Gaye (in  "The Very Best of Motown" 3cd set).

I know I forgot a lot of music I listen to on a regular basis, if I wanted to really detail what I like on music I wouldn't have time to actually listen to it and figure out what else I like besides what I know.

I also promised myself that, as of today, I would start using last.fm client on my work laptop also and connect my ipod to my pc so what I play can be scrobbled (I hate itunes auto-sync, don't bother telling me about that). If I can now take up the habit of regularly changing the 8Gb on my ipod that should give a reasonable last.fm in due time.

Product Ownership, in reply to Bramus!

My pal Bramus! (mind the exclamation mark) was so nice to post a long comment on the series. Instead of replying on the comment, I decided it deserved a full post. (I've snipped the comment, the original can be read here).

Define a set of features/tweaks for the next release and go for it.
Hereby I keep a list of urgent/less urgent/nice to have which indicate the priority (the so called backlog).

This sounds more like a release plan to me, in which you define a feature set (number of groups of stories) that will be delivered. Generally these will take some time, and you will divide your time in sprints. Part of the power of sprints is that they allow a certain pace and rhythm (each sprint takes the same amount of time), making your process and release dates predictable to a certain degree. (you're never sure since you're estimating).

However I implement these in a kind of a waterfall method (define, implement, test, fix bugs, final). Don't know if I get the full picture here, but to me a sprint seems like a mini-waterfall to me.

Part of scrum is based on reducing the time between development of code and the testing of it (hence test driven development) and making sure you have something 'shippable' at the end of every sprint. So you could indeed look at it as a mini waterfall (there are points where it doesn't hold true, mainly in design phases and the command&control style inherent in waterfall systems)

You wrote "In order to do all this, there is no way the product owner will get away with having a high level overview of what the product is supposed to be". Shouldn't that be without?

I admit, it's not the most wonderful sentence I've ever used. What I intended is that he won't get away with JUST having the high level overview. He needs more, deeper understanding. He won't get away without any overview also, but that's a different matter altogether :)

Adding more developers, will increase the price, leaving less money for the development itself (as you indicate).
Yet, when adding more resources, the product won't necessarily improve the product (once read: "nine women can't deliver a baby in on month").

I know that one, but there is an essential difference. Women are people (yes, they really are, I'm not just saying that because of wijvenweek). If delivering a baby would only require thought (=cpu power) it would probably be possible to deliver a baby in one month with nine women. (probably little over a month due to the overhead generated by nine women). Never thought I'd say that one day :)

Yeah, I'm a bit confused on the placement of scope & resources in the variant (IM me :D)

Will do. Or we'll catch up sometime at one of the local bars.

the final goal must never be kept out of sight.

Couldn't agree more.

And to the questions you asked: no and yes. Two obvious answers imo as ones decisions are highly impacted by knowing what's possible and what's not (cfr. "A good enough technical background")

Had an interesting discussion about this with someone arguing that a project manager (slight difference to product owner) doesn't need technical baggage. To a certain degree I can follow this logic. However, if you think scrum is widely used on software development projects, I still would like to see the first project manager on a software project who hasn't got a technical background and does a really good job. On more operational projects, I agree you can get away with less of a technical background, but that's somewhat outside the scope of the series.

Yes, guilty of that one, I'm a freelancer too after hours. And yes, that affects my day job one way or another (both in a positive and negative manner).
However, the interpretation of job can be expanded as in "no other big projects to handle" as one cannot focus the full 100% on the project otherwise

That was indeed what I had in mind when saying job. This being said, in an ideal world the fact that you freelance after hours shouldn't have any impact since it's after hours. Product Ownership is a full time day job, it's because people (golf players) are not taking it seriously that they are putting it next to someone's day to day job. This ends up in that person doing 2 jobs and generally resulting in a poor job on the product ownership side (it is perceived a side job after all). If one wants to do it right, it takes more time than what is available in a normal week resulting in less free/personal time, and in that case it starts negatively affecting the freelance business (and vice versa).

Product Ownership (6)

In this post I'd like to elaborate on the last point from the introduction. You can read this post as a standalone, or you can go back to the introduction, part 2, part 3, part 4 or part 5.

Point 5: "No other job"

No other job, that would indicate that you dedicate all your useful time in the office (there's always some overhead). Just think about that idea. Only having to care about one project would allow you to shape up on the knowledge you need, take your time for all the stakeholders, spend enough time dissecting the backlog, have regular talks with the team, provide timelines and other needed documents for project support and follow up amongst the golf players of this world, ... AND you probably still would have some sort of social life left. Doing a good job as a product owner is a full time job, if you don't believe that, try being a good one. So really, I literally mean, not having any other job.

The statement also implies a second thing, because no other job means no other priorities. 
We all know the office is rigged with politics and hidden agendas. I think as a product owner guarding your own neutrality in that jungle is something you should aim for.

Looking at it from a pragmatic side, it might be worth having a product owner governing a few related products. It means a good use of needed knowledge since, amongst similar projects, often similar knowledge is needed and generally the same (or big overlapping) group of stakeholders is involved. The downside is that it might somewhat distort the product owners neutrality.

I'd like to use these last few words as some kind of a closing note on the entire series. A lot of it was written with a perfect world in mind and with the idea that there are little to no personal preferences and/or tradeoffs to be made.
Since we don't live in an ideal world, I think it's important to carry forward the ideas and try to implement these in the best possible way. You may not always get what you ask for, but being creative with what you get is never a bad thing.

Product Ownership (5)

Continuing the series on product ownership, here's links to the previous parts: Introduction, part 2, part 3, part 4.

Point 4: A "business sense" and a vision

When I was first thinking about the qualities and how they fit together I had a bit of a hard time placing this one. I felt they are essential, but couldn't really nail down how or why that would be.  Not just the combination of business sense and vision, but also how a product owner should use these.
The more I was thinking and organizing my ideas, I started to see that they are actually closely related and rely on some of the other qualities I put forward earlier. It brought up some interesting discussions and ideas, which I've tried to capture in this post.

Since business sense is a pretty subjective and vague description, I'll clarify what I mean by that. To me, business sense is all about making good decisions. And in order to make a good decision one would need to understand the tradeoffs, the iron triangle, such concepts as risk vs. value. All these need to be balanced in order to make a good decision imho. So you could sum it up as "the art of making a good decision at the right time". Some of this can be picked up through study and/or experience. What is harder to pick up is "seeing an opportunity", this is where a vision comes in.

A vision could be defined as a long term strategy or goal. Often, it's not realized overnight but in small incremental steps. Other terms that could indicate a vision is "the Plan" (with capital P), "the big picture",.... Since a vision is some thing like trying to see the future, it means that some assumptions and question marks will be present.

Keeping the above definitions in mind, it's fairly obvious to see that good business sense is essential for a product owner to make the right decision at the right time. Or at least, to make the right decision with the information known to him at that point. Which to me also makes the decision to gather more information and not make a final decision (given that there is enough time to do so) an equally good decision to "yes" or "no".
A product owner with a well developed business sense should be able to prioritize and make clear decisions about the backlog. This is supported by good communication and negotiation skills, which allow him to convince stakeholders and to get an open dialog so it works, as much as possible, for everybody.

On the vision part, the product owner should be the one guarding the vision, that does not mean he has to be the only one creating it.

I'd like you to think about 2 questions before reading along (and feel free to disagree with my answers below).

• Can a vision be defended without a deep understanding of the problem?
• Does the amount of understanding the problem have an impact on refining or adjusting the vision?

I'm inclined to say no to the first and yes to the second. And here's why.

If the vision needs to be defended, chances are pretty high that there will be an argument on the assumptions and question marks or, in general, on the more vague parts of the vision. In a good vision, those vague parts have been filled in somewhat with a belief, an assumption that is based on knowledge in some way, shape or form. Knowledge, typically drawn from the problem domain. It could be a predicted market change, a new technology that's upcoming, a desired feature that would give competitive advantage, ... . And in order to defend that, you better know what you're talking about.
On the second question, my answer is yes for a rather similar line of thoughts as the previous. If you end an argument with a need to adjust the vision, typically you'll be adjusting/refining the vague parts. If you half understand the problem, how will you refine or adjust the solution?

As a final thought, here's how I see business sense and vision working together. If the vision is your end goal, the business sense makes sure you follow the right path to reach it, with small steps at a time.

Product Ownership (4)

This post is part of a series on my view on essential qualities for a good product owner in scrum. If you just bumped into this post, here are the previous articles: the introduction, part 2 and part 3.

Point 3: "Great communication and negotiation skills"

Let's first of all pull up one of my favorite pictures about project management.

The traditional representation looks like this:

I prefer  a slight variant to it:

[[small sidestep, skip if you understand the pictures]]
For those that never seen this picture, here it is explained in an easy way.
Scope = what needs to be done
Budget = money, people, hardware, software, ...
Time = days till delivery date
Quality = how good the result is (compared to what the customer asked for)
The triangle is sometimes called the iron triangle (there are a few variations out there). Each side and the surface representing one of the aspects. Since it's an iron triangle you can't change one aspect without affecting the others.
What the second version factors in is that scope & quality are closely linked. They actually fight for the same area in the triangle, meaning they mostly behave in a "scope+quality=1" manner. The only way to improve both is generally to play with the sides of the triangle to provide a bigger surface.
The other nice thing about it is that it takes out the resources (=people) from the budget aspect. In most development projects, adding developers is not something that is as easy as adding more hardware or software (which typically falls in the budget area)
[[end sidestep]]

As far as I'm concerned, this is one of the most fundamental pictures to understand. The good news is, it's not rocket science. The bad news, you'll always be fighting about at least one aspect of the triangle.
The thing that is not on the triangle though, is equally important. Communication! I consider communication the glue that holds this triangle together. I already expanded on communication in an earlier post. What is said there still holds true (hurray), and the key point in this case would be the feedback. Because feedback means exchanging ideas, ideas generally mean new ways of looking at something and eventually coming up with a solution. In the case of our triangle, that solution might be to make a tradeoff that suits all stakeholders as good as possible. Or put differently, communication is a key aspect of negotiating. And both skills are indispensable to come to an agreement.

Another part of reaching an agreement is striking a good balance between complexity and added functionality, based on the time (and other aspects in the triangle) that are set. This is where the negotiation really kicks in. Every stakeholder feels his feature set is the most important, highest value, first to be developed feature. And probably, in their distinct worlds, that could be very true. However, if stakeholder A is asking a feature that is so complex it would take 2 sprints of the team, that would cut off the minor update for B and that small module for C for at least another 2 sprints. Stakeholder A's feature may bring some added functionality for B also, but C has no benefit. Where do you go from there? This is where it becomes interesting. How do you balance this? (on a sidenote: yes, I love thinking about balancing stuff also outside game design)
This is where the scrum metrics velocity, business value and storypoints (indicators of complexity as I like to see them) come in handy. They provide you with ammo for your negotiations. How you get out of the situation above? I would probably ask A to split up the 1 story in multiple stories first of all, and see how B could benefit from some of those . Since they are split up, they shouldn't require 2 sprints and complexity on the individual elements should go down. This would open a time for C's request to be fitted in.

The last part of this communication is something I already touched in part 2 of the series. There is a need to communicate with a wide variety of people. Ranging from hardcore developers to golf playing VPs. The way something needs to be presented to those groups is without a doubt very different. In an ideal world, you would have a product owner that can easily summarize technical detail into executive summaries and can expand executive thoughts into detailed user stories. Read that last sentence again, it's key to solving many problems. Speaking the right way to the right person is something I tried to get through on my old blog one time (I'm not entirely happy reading back that post now, but still, the idea in there is key to this last statement)

Product Ownership (3)

In this article I'd like to elaborate on point 2 of my take on good product ownership qualities.
The introduction can be found here, point 1 is here.

Point 2 is: "A good enough technical background"

I know this is a somewhat controversial topic amongst many of the people I spoke to, yet I still think it's an essential quality.

First of all, how do you define "good enough". A tricky issue and a very subjective matter in my opinion.
Secondly, all of us who have a manager that used to be a technical guru know that he generally misses the deep technical stuff. It's the reason why most technical managers still like to play with Lego, they make tiny constructions in their office with their pens and paperclips and a lot of them still love to write some piece of software at home. Given all this, I think it's fair to say that they just miss the "creating" part of software engineering. The technical challenges, coming up with solutions and riding the high waves of new technology and its possibilities. This is one big caveat, and I've seen a lot of product owners fail there! (and most people learn it the hard way)

Looking at the natural order of things, it feels normal in the early stages of a project for the development team to drive a lot of the priority settings. They know best what base layer is needed and which components take precedence in order to reach that first thin end to end slice of functionality. They understand what infrastructure needs there are and how low level components (generally those a user will never notice) need to be available before the first features can be built. (sidenote: I am not trying to say they will have a big design up front cycle, but just enough to understand the dependencies). Having a technically trained product owner will help the team out in defending this priority setting to the stakeholders, even though they may not always understand why there is such a need for a "non visible" component or feature.

This being said, that cycle can't go on forever. At a certain point (you'll feel it when it's there) this needs to change and the product owner needs to start taking charge of priorities, based on stakeholder requests. Here again, it takes a product owner with a technical understanding to see when a project is ready for this switch (it's more of a fade than a hard switch anyway). The risk of not having a technically skilled product owner is that the team will keep running circles around him and develop "cool" features (for developers) instead of listening to what the market is asking for. On the other hand, when a product owner is in his mind still too much of a developer, he'll happily agree to keep working on those cool features and start ignoring stakeholders and market demands. He'll drift away as part of the development team and that early stage cycle will never be broken.

So, how would one define the "good enough" than?

In my opinion, good enough means something along the lines of:

• able to understand technical problems and solutions to an extent that an autonomous judgement can be made on the progress of the development team. This generally requires a product owner who did do some development himself.
• able to grasp the complexity of a proposed feature and its underlying needs
• able to understand the high level architecture of a system
• able to place the development team on an equal level to other stakeholders and make a decision based on business demands rather than on "coolness"

Product Ownership (2)

Continuing on my earlier post about Product Ownership, I wanted to dig in a bit more in maybe the most obvious of the items on my list.

"A deep understanding of the problem".

The product owner is the main point of contact for all stakeholders. In most projects these are a set of very different profiles, ranging from high-tech to no-tech and from senior VP of directors to working class heroes. In order for your product owner to communicate well with all those parties he needs to be able to give the executive summary of a project, but also to have detailed discussions about problem areas.

Imagine the following scenario. A simple project (if there is such a thing) to develop a piece of data displaying software to track impact of press releases. Your main 3 stakeholders are a senior marketing executive sponsoring the project, some junior on the marketing force who will be mostly working with the tool but hasn't got any skills beyond viewing a form in access, and a data analyst who is used to slicing and dicing data with custom scripts and queries.

In order for your product owner to be able to effectively communicate with all these people he needs to be able to give the executive summary, work with the junior in understanding his requirements and translating these into backlog items and, lastly, working with a data guru who thinks in hooking custom scripts and plugs to that output and cares about APIs that should be in there.

These are, in my opinion, 3 completely different approaches to be taken. Perhaps the executive summary could be winged with less understanding of the problem, but that would definitely harm the credibility of the project. Working with the junior may require mostly listening and trying to slot his requirements in a timeframe that would suit him best at any given time. The last one will delve deep into the technical aspects. Some of these requests are better taken up with the developers, but the product owner should at all times be a first point of contact in order to shield the development team from deviating from sprint tasks by outside requests.

In order to do all this, there is no way the product owner will get away with having a high level overview of what the product is supposed to be. He will need to filter out requirements, talk stories through with developers, give regular feedback to his stakeholders and really be just as involved as the development team in order to reach the goals of this sprint.

Since the product owner is equally committed and involved, and will stay involved during the entire project, replacing him is something that would add the same amount of troubles and overhead as replacing anybody in the team. The problem with replacing a product owner is that he is a first point of contact and the "external" interface. Meaning that he doesn't have a lot of margin to slip up. Any slip up, miscommunication or doubt in understanding the project may (and usually will) result in confusion, angry stakeholders, a mess as to who is the actual product owner. And especially that last part is concerning. One of the most difficult tasks to handle, speaking from experience, is having a lot of channels that are all directly talking to the development team and setting their requirements. The development should focus on development of whatever is needed. It's not up to them to make decisions about what is a priority to the business. And doing so requires a strong product owner, who understands the problem at large.

Tripit, it just works

Albert Einstein once said: "Everything should be made as simple as possible, but not simpler." That's exactly what TripIt does.

All TripIt does is aggregate all data that you get from confirmation emails when booking flights, hotels, rental cars, ... . Adds in bits of information scraped from the likes of wikipedia, the weather channel, google maps, ... . It doesn't require a genius to come up with this, parsing some standard generated emails is a piece of cake. Adding in extra info may require a bit more effort, but still isn't rocket science. Nothing all that brilliant at first sight, but here's the catch.

It's dead easy to use, it's fantastically thought through and cleverly crafted to minimize your effort. The lazy web at it's best.

Really, all you do is forward those nasty gibberish confirmation emails. Tripit will figure it out for you. It doesn't require a lengthy, time consuming, sign up procedure. Since you sent them an email, they know your name and your email address. That's enough personal information for one day isn't it?
Once you forwarded your first mail you get a nice return mail (caught by my company spamfilter, but they are aware this happens often, unfortunately). That return email contains a link so you can quickly go check out your travel plan, at that point you'll be prompted by a "real" sign up, which has a nice skip button. So you can easily use it without having to register. Ever!
Further in that return mail is also a username (your email address) and a password, for future log-on purposes.

Finally, to add in some 2.0-ness, you can share and discuss your travel plans with friends (or colleagues) and figure out who out of your network is close to you. I still need to get some friends hooked up on this, so I can start checking this thing out :)

Conclusion. Awesome, it simply does what it needs to do, without making it complicated, time consuming. And since 90% of the population uses the same top airlines, travel agents, car rentals and hotel chains, it's able to parse everything most people will ever need (you can still manually add/change if you really have to). I know the year is still long, but this is already a huge contestant for my personal "tool of the year" award!

Also check out the demo videos. It really is that simple.

Product ownership

I've been catching up on agile development lately, more specific, on the scrum methodology.

After sorting through various books, course material and tons of useful talks to colleagues, peers and agile people (not necessarily claiming they are agile but definitely adopting the concepts). First of all, I wish to thank all of these people for the time they took to educate me. I feel at a point now where I have a grasp on how it works and I'm past the steep hill in the learning curve. A good time to look back.

Starting with a statement: "Having seen the waterfall system in action one to many times, I am sure there is a better way". This, combined with my current employer wanting to adopt scrum, is what drove me down this road. Being on the operational side of the building, I have been experiencing product ownership from up close and here's what I think are important qualities for becoming a good product owner.

1. A deep understanding of the problem at hand
2. A good enough technical background
3. Great communication and negotiation skills
4. A "business sense" and a vision
5. No other job

Unfortunately, many companies (including mine), horribly fail at most (or even all) of the above, especially the last one.

In the coming articles, I'll be elaborating more on those 5 points (= nice hook to have some more articles on my blog :) )

Ardenskie 3.0

For the third year in a row, a bunch of former fellow students went on a weekend to the Ardennes. Doing all you expect a bunch of geeks to do on a boys-weekend-out. Upon arrival, the big table was taken by a 24 port gigabit switch and laptops, network cables, gizmo's and other electronics. Not that we spent a lot of time there, just every now and again setting a queue to borrow some of the friends material.

Friday night was mainly sponsored by Dr. Oetker and Jupiler. On Saturday we took some time out to sit back, chill and enjoy some of the local beverages. I put my hopes on Captain Morgan (original spiced rum), he didn't disappoint me. It's nice to just sit in the sun, share time with friends and forget all about the daily worries, even if only for a day. We ended up in Durbuy at night, in a near empty restaurant. After getting our food served, we started to understand the near emptyness of it. The food on it's own wasn't bad, but "serve with a smile" seemed an odd concept to the place. Too bad, we did have money to burn if they did some effort.

Sunday, traditionally, ended at Don Antonio for an excellent fresh made pizza.

Memorable facts of this edition:

• Vicious Vince (aka Poofter) calling the sleeping people at 3am to hear their ringtone.
• Bladders, Eraser, Crossmol and myself going shopping and buying all of the Mozarella Discs available at the local Delhaize.
• Bladders having a bit of a jet-lag after 2 weeks Shanghai and so waking up at 7am every day.
• Azzy doesn't like pizza, and still he's our friend :)
• Many more, not all suitable for publication

Many thanks to the usual suspects for making it a great weekend. Poofter, Rubella, Punkie, Azzy, Apolio, Eraser, Bladders, Crossmol.

Why we will not have senior developers anymore

I have the pleasure of working with some people who live and breath software development. Coming from the old days where assembly was new and cool and above all something that made you think about the inner workings of a computer.

Now what makes a software developer senior?

These days it seems like becoming "senior" developer means having a few years of experience under your belt. You can easily have senior guys who never did anything else than php or .NET development. (nothing against php or .NET if used under the right circumstances, don't get me wrong).
To many businesses this would qualify as someone who would be labeled 'senior'.
I think there's a bigger issue here. Those new senior developers don't have that deep understanding that many of the current senior developers have. They never had to be bothered with allocating memory or worrying about limited hardware resources.

The current trend seems to evolve to "if we have an issue with resources or performance, we'll throw some extra hardware at it". I understand Ruby relies heavily on this principle, after all, development time is more expensive than cpu time.  A fact, just like looking good is more important to Paris Hilton than having something useful to say.

I personally doubt this level of seniority somewhat. They might be very good developers, but in their own language. When it comes to high performance apps and scalability, often it requires an intimate understanding of the inner workings of a compiler, down to bit level.

The "old" senior developers know for every line of code they write what bits move around, how that relates to the heap and stack. They intimately understand Pascal and C strings and the (dis)advantages of both, or why certain algorithms are more scalable than others. Simply because they grew up having to care about every bit in that machine.

Our future senior developers...

These days people often don't get down to that level of computing. They have fancy things like objects, garbage collectors, excessive amounts of disk and memory available, ... . And they often start out with a higher language like Java or C# which makes them unaware of all these intriguing little details that make or break large scale applications. I don't blame the persons, those who really want will still find all the information necessary to get that understanding of the machine.

I think we should start reconsidering our school system (for Belgium for sure) and start teaching our computer graduates the basics first before letting them have a go at a high level language which takes away a lot of the machine related problems. In their first years, give them an 8086 or an emulator that lets them run assembly. Make them aware of address registers, stack and heapspace, allow them to fool around with 0 terminated strings and the up and downsides. Make them feel the pain, they will even more so appreciate the higher level languages, but above all, they will learn why some things simply require a lower level language.

This is a call to all deciding people on school boards. Don't try to have a sexy education with fancy new languages, just get a good old hardcore education that teaches what they need to provide the world with senior developers.

2008

Everybody seems very preoccupied by lists around this time of year. So for what it's worth, here's a personal round up.

Last year has been a year of firsts. First business trip across the ocean, first powersuit-mandatory meeting (for an engineer, go figure), first product launch, first feedback after a 1.0 product. All in all, it looked good. On a personal level, I finally moved away from the love and caring home my mother provided me all those years (thanks for that). All in all, it's been a good year (no, not the tires) for my NADD brain. A lot of frequent changes, a lot of fun, a lot of pressure (somehow, I like that) and living on the fast track in general.

When it comes to 2008, I have no device to see the future so I can only hope and wish. Most of what I hope for is very similar to what I had in 2007. 

As Kane would have said it:"He who controls the past commands the future, he who commands the future conquers the past"

Wise words, wise words...