Intel everywhere? Programmers will like this...

This year's CES is presenting us, software/programmer types, with a very rosy picture of the future. A good example of what I mean is the push that Intel is making to the mobile phone segment with it's Moorestown platform.

Imagine a world where you can easily port all of your work to a new platform just by re-compiling with a new UI (which will no doubt be easy to do once the whole world runs on Qt!).

I like the future. How about you? Leave your thoughts in the comments below.

Check out this demo of an Intel based phone:


(via Ubergizmo and Jkkmobile)

The cost of un-fixed bugs or Good Code on top of Bad Code

While discussing with a colleague we started talking about the costs related to not fixing a bug immediately (yes, this does mean that you have a way to immediately figure out if you introduced a bug).

The reason for fixing bugs immediately is not only the cost of content switching later on when you have to come back, but it is even more the cumulative cost of fixing all the code you have built on top of the bug you introduced.

Think about it this way. Bug = Bad code. If you have a bug and continue development you are developing working code (good code) on top of that bug (bad code).

When you later on go back to fix the bad code, you will then have to fix all of the good code that is now broken because of the bug fix you introduced.

Software is build in stacks, the lower level affects directly the upper levels (many of them), if you have a bug lower in the stack and then fix it you will have to change all of the upper levels! And that is where the real cost is.

So, if you find a bug, fix it now. If you did not find a bug, think of ways you could find it faster -- before you build good code on top of bad code.

Windows Vista as secure as planned, not much... (or Plans don't work, working code rules!)

One of the fundamental problems with Security is that if you change something in your code (anything) you are increasing the risk of a security vulnerability being created and later found.

Now, if you consider that, and know what Microsoft changed a lot of code in Windows Vista before releasing it, it's clear that something like this was about to happen!

In Security, the more exposed you are, and the less you change the more likely you are to stay safe. If you don't expose your code (like Linux does) and on top of it go around changing it and it's architecture you are asking for trouble.

Nice going MS! When can we expect for a new version of Vista with this fixed?

PS: time to change back to XP dady-o!

How much should you keep the code checked out, before the team kicks you out?

"Some developers keep their code checked out for a really long time... Like a day or so"
-- Craig Larman, lecturing on feature teams

From Jeff Atwood's blog, a similar argument.

Blogged with the Flock Browser

On the subject of problem solving, and problem root causes

Problem solving is key to the discipline of software development. What we do when we code/test/release a software product is essentially problem solving. We learn about a problem we analyze the root causes and then we come up with a solution.

This post by Brett Schuchert reminds us that very often the apparent causes of problems in our efforts are not the right ones. In his example, a developer is blamed for "doing the wrong thing" when in fact the policies and rules in place force developers to actually do the "wrong thing". Often, problems in software development come from policies and rules, not from people wanting to be bad.

If you are analyzing a problem in your team right now, ask yourself: are there any policies or rules that may cause this behavior?

W. Edwards Deming suggested that in 96% of the cases the deep root causes of a problem lie within the web of rules and policies put up to "regulate" the work (he called it the system) as opposed to suggesting that the problems are caused by people, on purpose or due to incompetence.