As usual the answer is it depends. If you insist on looking at short term effects of TDD for example there is no doubt in my mind it is a waste of time. Why deliver great software in six months when you can deliver decent software in four months? Personally I believe there is too much software out there that started as "a little temporary solution we will only use a few times" and that later turns out to be used, tweaked, fixed and updated for years and years to follow. You never know what will happen except that you probably have to maintain the software you write for a longer period than you really want. And the best way to not spend time on old stuff you wrote ages ago is to make sure it works in the first place and that changes/updates can be made quickly (and preferably by someone else without asking you for help). So in the long run, TDD is definitely not a waste of time in my book. There are also some research on this if you like to crunch numbers.
So what about pair programming? As pointed out here, you do much more than just write code when you develop software. In certain situations such as spreading knowledge pair programming is a no-brainier. One experienced person showing someone else how things work at the same time as new features gets created is probably more cost effective than having somebody sit for days by them selfs trying to figure out how things work in the code. And two skilled developers probably solve any problem faster together than if they try alone. Since two people also look at the code all the time you will probably end up with a better design because it is the work of two rather than one. And you always have (at least) two people that understands each part of the code so if somebody gets seriously ill it is not catastrophic. But all this (except maybe teaching novices) is definitely a waste of time if you insist on looking at the short term consequences. But once again, software always survives longer than you think. And each thing you do in your development process must be measured against the total life cycle of the software. Not just until the next release (or on a day to day basis).
I think all agree that quality costs but it pays in the long run. And there is always a breaking point. Some things are just not worth the price of quality but before you can make that call you must know the real costs and the real benefits. As provided above there is some research on TDD and developers don't just write code so two developers pairing is not half as fast as two working independently. And if you really need numbers then you should try TDD and pair programming and actually measure the cost vs benefit rather than focusing on the short term cost in time. Remember, quality typically pays of in the long run. Both in terms of less bugs and happier staff that stays on the job.
I recently observed a discussion where one person hesitated to add new dependencies to one class since it meant all calls to the constructor had to be changed. At first glance this only looks as if the person was very strict about constructor dependency injection. But there is nothing wrong in having a constructor that uses all the default dependencies in your production code.
Or maybe the person felt this about the test code where he couldn't use the default constructor. But in this case we're talking about code duplication in some form. You probably want a common function to set up your test environment. Or maybe the person just thought it was ugly adding yet another dependency creating a constructor parameter list marathon.
Regardless of which the real reason for feeling it's awkward to add new dependencies the annoying answer is: "you're probably doing something wrong". And this applies not only to dependencies but to all kinds of behavior/test writing. As soon as something feels awkward, back-wards or just wrong to write it is a huge warning bell for me. When this happens I try to stop and think about what I'm doing questioning myself to see if there is a simpler way to do what I'm about to do. Sometimes something is wrong in the design and sometimes there is something more simple to test instead of the thing I thought of first.
So finally it has been released. SCOM 2007 R2 where one of new big features is monitoring Unix/Linux computers (which happens to be what I'm been working on for the last two years). There is an evaluation copy available here. More community resources available here, here and here.
General availability is July 1st 2009 (i.e. when everybody can get this). Right now only existing customers with the correct upgrade agreements can download this release as far as I understand.
One thing that struck me as kind of odd when I first started to look at PowerShell and how to include other script files in order to gain access to functions in that other script is that all examples I found use an absolute path to include scripts (ex: ". C:\Some\Path\Script.ps1"). At least for me, using absolute paths is never good so I tried a relative path like this: ".\Script.ps1"
The result is no errors running the script but no functions from the script are defined outside the script. ". Script.ps1" is even worse since it does not even execute the script. What you have to do is this: ". .\Script.ps1"
Remember to use "double dots" with space between them! And I cannot understand why all tutorials I found use the absolute path approach since relative inclusion is much more likely to work.
If you're negotiating with a customer over a contract for something and you want to be agile I think one of your hardest problems probably is to convince the customer of the value of an agile development process. Because you don't really want to be negotiating, right? And most customers want a fixed price so they know how much money they'll spend at most. I think this compilation of contract variants is great since it helps you (and your customer) to compare different types of contracts/collaboration. The most interesting is of cause the "Money for nothing - changes for free" contract (more on it here). What it essentially means is that the supplier estimates the initial work just as if it was a fixed price contract. That price is the target price. Rules for what happens if the target is exceeded may vary but that is not really something new. The interesting part is that if the project is canceled prematurely the supplier gets some percentage of the remaining sum without doing anything. And the customer may change everything and nothing at will (change for free) during the project. The idea is that if enough customer value is delivered early then the project ends early. This is good for the supplier since there is money for nothing. And the customer gets maximum value in shortest time probably also cheaper since the project can be canceled whenever the customer is happy enough. Because we all know that a fixed price or cost ceiling in reality means the same thing. So even if the customer pays "money for nothing" it is still better than paying for things you don't really want...
I recently needed to move all my private domains to a new hosting solution and the new solution did not allow any other access than FTP. I considered setting up a mirror on my ubuntu host at home but that didn't feel like the best solution. So I thought there must be a way to mount a file system using FTP. And there is several I think. The one I tested and that looks good so far is curlftpfs. The only tweak not mentioned on the curlftpfs site (in an obvious place) is that you need to put the following in your /etc/fstab to make sure all users (and not just root) have access to the mounted file system:
curlftpfs#ftp-user:ftp-password@ftp-host /mount/point fuse rw,uid=500,user,allow_other,noauto 0 0
"allow_other" is the magic enabling all users access. Since it uses FTP under the hood you will notice the file system is quite slow at times. Especially when editing large files. But compared with having a local mirror and updating all changed files when needed I think this a pretty convenient way to access the files on the FTP server.
Since I moved to Redmond I've been looking for a regular coding dojo in this area but I've not been able to find one. So I first planned a number of team dojos in my team but I felt that was not enough. I think an important part of each dojo session is to meet other people and learn their TDD tricks. So since I couldn't find any dojo in the area I planned one myself and invited people on one of the internal mailing lists (also set up a separate internal mailing list for the dojo). I thought Microsoft would have more than enough people to be interested in attending coding dojos.
So yesterday was the first dojo session I arranged open to all Microsoft employees. We did the kata I'm most familiar with: MineSweeper. For the first time we tried to build parts rather than stick to the end-to-end type of tests. It was an interesting experience and we got further toward a complete solution than I've ever seen myself. Not sure it was just because we approached the problem slightly different or the fact that the group was fairly small. The important part is that I got to learn a few small tricks and I'm pretty sure others learned some tricks too.
So now I just have to plan the next session...
There is a very funny introduction to F# available here. So if you want an introduction to F# and/or a few laughs you should watch it.