Question has been asked on some mailing lists recently, but I’m curious as to what music/thing (if at all) do you listen to while developing? As I’m asking the question, I’ll give the first reply: nothing.

Years ago, I used to listen to a variety of things, including Phantom of the Opera, Guns’n'Roses, Pearl Jam, Pink Floyd, Pink Floyd, Pink Floyd, Roger Waters and some early Pink Floyd. For the past couple of years however, unless I’m doing mechanical coding, I don’t listen to music, or anything for that matter. I find, especially when I’m thinking about design, that it distracts me. I’ve even tried music with no lyrics (except Kenny G.)

Maybe I’m just getting old…

I was just reading on a blog a reference to an article Michael Swindell published about native application development. It's fair to say that you don't always have to agree with everything someone writes, but I think in this particular case, there is misleading information.

The story of the .NET framework lagging behind native performance just doesn't cut it anymore. Wake up and smell the coffee. We are three versions into the .NET framework and Microsoft is already talking about 4.0. While we are seeing new things that will make applications and architectures more flexible and easier to maintain (such as dynamic binding), Delphi developers are still complaining about the garbage collector.

This might come as a shock to you, but in a business application, your end customer is not going to know how long it took him to destroy that order object, or to create it for that matter. He cares about his application. He cares about interoperability. He cares about his ROI. With all that the .NET Framework (or Java for that matter) has to offer in terms of productivity to the programmer, with all the frameworks that exists to make application development easier to maintain, the native vs interpreted performance argument doesn't stand anymore.

I'm not saying that native is bad, far from it. Right now, and for the foreseeable future, there is a place for native code, just as the article points out, something needs to be under that virtual machine or the RIA. Until all computer systems (excluding my mother, she's already on .NET 3.5) have the .NET framework installed, there will be room for small utilities to run natively. But enterprise level or businesses do not have an issue with making use of applications that use the .NET framework. They don't have an issue with deployment. You can still automate and accomplish easy deployment with .NET (and I'm not even talking about ClickOnce).

Every day we have faster processors coming out, we have cheaper memory and yet 6 years after the release of .NET we are still clinging on how native out-performs managed. They say you shouldn't dismiss something without having really tried it. Unfortunately that's something I see a lot in the Delphi community.

Last year iMeta was given the 100 Tech Track award, as one of the top 100 fastest growing IT companies. It was at position 91. This year, we’ve moved up 42 spots to position 49! Excellent news!

This is awesome news

20 minutes left in my session on Continuous Integration. Thinking great! More than enough time to go thru a demo with my CI server. Switch over to my VM machine that I booted up in the background (unfortunately the room was not "freed up" by the previous speaker until 4 minutes before mine started), and get faced with this:

WTF!?#@#@~!

I did what any good computer user would do, reboot and hope for the best. And it worked! Imagine if I had pressed "R".

This one is more of a personal reminder. I’ve just tried to connect to the office VPN and noticed my username/password is blank. I fill it in and try to connect. It won’t even dial. Gives some weird error about not being able to save or delete an existing password. I decide after several attempts to delete the connection. WRONG! I can’t create ANY type of new connection under Windows XP Network Connections.

It seems my RAS is corrupt and my phonebook is missing. Solution is to re-install it. I’m travelling right now and don’t have the CD of XP with me (I know, my error). Luckily I’ve found another solution. IF you run RASPHONE, you can create a new VPN connection and dial it from there. And it works. It creates the icon for you in the Network connections also. Problem is, it’s unusable. It won’t disconnect or connect from there. You still get errors. But if you run RASPHONE again, you can pick the connection from the combo and hang up.

I’ll figure out what messed up later, but for now it works.

I was setting up a recurring appointment today in Outlook that has "no end". I hate recurring appointments that are more than once a month because when I look at the thumbnail of the month calendar it shows many days in bold. Sometimes the appointment doesn’t justify that. I just realized that if I mark the event Show As "Free", I don’t get the "boldiness"

I’ve been using Outlook for many years now. Boy do I feel stupid! I think this post deserves a new category/tag

Become a more productive [computer user] (insert Developer, Excel Programmer, Word User, Internet Surfer….).

Every time you want to do something that involves taking your hands off of the keyboard and going for that damn mouse, see if what you’re about to do has a keyboard shortcut. Use the mouse if you have to to find the shortcut (sometimes they are displayed next to the item in the menu entry), but don’t use the mouse to perform the action, use the shortcut instead. Next time you want to do the same thing, you’ll remember the shortcut instead of the reaching for the mouse.

Result: you’ll be much more productive without the mouse.

It’s not a question of getting 3 minutes more out of the working day. It’s about not breaking your flow of concentration and at the same time improving your memory, and none of us are getting younger…

I was having a conversation with a developer the other day about working on different areas of a project. The subject came up after I made a comment about how the person that breaks a build should be the one to fix it. His immediate reaction was that he shouldn't be responsible for fixing something that wasn't his "area". And that it would be much more productive if the developer working on that specific area were to fix the problems. This isn't the first time I've had this conversation. In fact I've had it many times with many developers.

There is a general tendency in believing that distributing up a team of developers and have each one focus on one area and only one area during the lifetime of the project is a good thing, that it is more productive. If Jack learns everything there is to know about WPF and handles all the user interface during the whole project, whereas Joe works on all the back-end, that is good. Each know their part inside out and can fix a bug before someone else from a different area can even reproduce it.

I mean it makes sense right? It's pretty reasonable thinking right? Well not everything is black and white.

Productivity can vary based on surrounding circumstances. Let's say a project is delivered to a customer and after three months, a bug is reported. Jack can fix it fast. Productivity is high since Jack works fast. However, Jack is on holiday. Customer is waiting for a fix. It's hurting his business. Jack will be away for another two weeks. There is only Joe left, and now needs to get up to speed on what Jack's been working on and try and fix a bug. Productivity has dropped to an all-time low.

In principle, that doesn't seem that bad. The productivity ratio can still be better than having everyone know all the system from day one. If a bug comes in and Jack is away, Joe will learn. And once he's learnt, he'll know it. If it ever happens again, he's already learnt it. Sure, it takes maybe 2 weeks instead of 2 hours to deliver a fix to the customer, but it's still ok. Problem is that it's not that simple. We're looking at a two-man product with two areas. As the system grows, the numbers grow.

The problem gets worse when we're not talking about a bug fix, but delivering a project. That's where the bus number commonly comes in: how many members of your team would have to be run over by a bus, for your project to fail? The higher the number, the safer your project is [This is a metaphor, not some cynical sick project manager that cares more about the project than his team members being run over].

I've been on both sides of the fence. I've been the stakeholder behind a project that has a very low bus number, and I've been a developer on a project with a low bus number. And I can tell you, neither of them is a good thing.

From a stakeholder's perspective, it's risky. If you have a project with three guys, and each has his/her area of speciality, you can suffer and your business can suffer if one of those guys decides to leave.

From a developer's perspective, it's bad also, and the longer the project, the worse it is. Working on one area and/or with one technology can cause stagnation, which in turn can lead to lack of motivation.

Coming back to the initial paragraph, as developers we should not be afraid to work on any part of a project. If you are working on a user interface screen and you need a certain piece of functionality that does not work or is not implemented yet, you should be able to work in it. If you don't have enough knowledge of the project/l.o.b. to be able to work on it, that is another problem waiting to surface. Solve it. The later you leave things, the worse it will be, both for you, the team and the project.

I can understand that people that are not "software orientated" find it hard to understand. They assume it's like anything else. In most industries, if one of the members of the team leave, and they are specialized in a certain area, it's not hard to find someone else to replace them. Soldering steel, fitting steering wheels, etc. have pretty much non-existent or very low new learning curves (you can pick up how to fit a steering wheel in a Ford in a very short time if you've done it for a VW or a Toyota). With software it's different. You not only need to know the technology, you need to get learn the domain of the project and get up to speed with the architecture. It's not as simple as pulling one guy out and putting another one in his/her place.

Knowing this, the best thing we can do on a project is have the ability to temporarily replace one person with another. It isn't so much about being agile, but about having common sense.

I’m coming across a lot of tests with names like this:

AddEmployee_Should_Pass_When_Not_Duplicate() {…..}

AddEmployee_Should_Fail_When_Duplicate() {….}

For the purpose of this post, I don’t care about anything other than what’s in bold and red.

The word Pass in there is completely irrelevant and useless. The word Fail is just mind-blowing. What should fail? The test? What if the test passes? Does that mean it has really failed? Or when it fails it means it passes?

Now we all know what Fail means here. It means the test will pass but the call will fail. But it doesn’t indicate to us what failure consists of and therefore it’s not adding information. Someone looking at the test cannot validate it.

When naming, indicate what the test is trying to validate, not what the outcome is; the outcome is already known: pass or failure.

Something along the lines of Add_Employee_Should_Throw_Exception_When_Employee_Already_Exists would add substantial information for the person reading your test to validate the functionality. But more importantly, when the test fails, they would know what has failed and have valuable information for debugging.