Totally backwards!

I just discovered that Upgrading VS 2005 Web Site Projects to be VS 2005 Web Application Projects is a totally backwards procedure, as described in this blog. I just don't understand why this is so hard procedure, and why the "Convert to Web Application" context menu is available when you have already converted the project to web application, and it not an available menu for web sites.

Migrating to ASP.NET 2.0... from a Class Library project

See this blog post

Failed installations

To cleanup after failed installations (especially C:\Windows\Installer) you can use

MsiZap G!

Or alternatively download "Windows Installer Cleanup Utility" to do that using GUI.

MSBuild and Web Site projects

One of the developers found an interesting misfeature of the MSBuild. When you supply Project Name parameter it does not package the web site and does not create PrecompiledWeb folder. However as soon as you remove this parameter the folder gets created. Weird.

AzMan group (2)

Unfortunately the approach I described in the previous post does not really works. The problem is that the AzMan.msc breaks if I do that. Probably it expects the groupType to be exactly 16 or 32 rather than what would be correct behaviour: apply a bitmap.

AzMan groups

AzMan groups ain't security groups. If you check the groupType attribute of the Basic AzMan group it will be 16 (0x00000010). Now the security groupType normally is -2147483646 (0x80000002). This article deciphers the groupType values. Thus 0x80000002 really means global group that is also a security group. So if you want your Basic AzMan group to behave like a security group you should use group type 0x80000012 which will be -2147483630 in decimal.

ASP.NET AJAX performance problems

Look at this Fiddler capture: ScriptManager loads more than 400 MBytes of JavaScript code!

WebResource.axd: 20 KB
ScriptResource.axd: 260 KBytes
ScriptResource.axd: 65 KBytes
ScriptResource.axd: 22 KBytes
ScriptResource.axd: 9 KBytes

This will make people want to come back to plain old HTML.

OO JavaScript

Good article!

Microsoft SQL Server management Studio

The management studio is a big disappointment for me, because I expected the tool that has the best features of Enterprise Manager and SQL Query Analyzer. Instead I found the combined tool where EM and SQA exist as independent units, so I don't have any of SQA features when I open the table from the object explorer, and when I use "New Query" I cannot edit results, nor use Query Designer. I can't believe Microsoft is selling the tool as a SQL 2005 "improvement". :(

New syntax for NUnit 2.4

Check out the new syntax for NUnit 2.4 in this blog entry. Nunit will have more object-oriented syntax for assertions, allowing to encapsulate the complexity of unit tests in nice object model. I guess this is another reason to stick with NUnit rather than going to VSTS unit testing framework.

Unofficial Windows 2000 DST patch

http://www.intelliadmin.com/blog/2007/01/unofficial-windows-2000-daylight.html

I'll try to apply it today.

QuickCounters

QuickCounters is a library that will make it easier to instrument your .Net code with performance counters. It still requires you to instrument the code through, which could make it quite messy.

Agile Google

Well, this blog says that Google represents good Agile, while other agile processes are bad agile. I agree with some points of the post, like if you have super developers the process does not help as much as if you have a mix of junior and medium level developers. But my personal experience does not confirm that no process is better than an agile process.

An eye-opening experience report by Mark Striebeck on Agile 2006 conference confirmed my suspicions. His area of work is Ad Words system, which is different from other stuff Google develops in that it is quite complex and requires a release cycle and commitments (as a B2B system). When he joined he found a few problems that can be attributed to a lack of a process. First of all the development was always late. Worse off, the developers did not know how late they are until the last moment. The scope creep was more than 30%. Mark was invited to add a process into the Ad Words development, to help solve these problems. Now, according to Steve Yegge this is like adding bad agile to good agile. Probably smart people at Google think differently.

The Cost of Code Quality

One of the most controversial event on the Agile 2006 conference was a paper by Yuri Khramov from Apple on the cost of code quality. It is to bad I did not have a chance to see the presentation :( . Let's see what he is writing about:

"It is shown that a 'quick and dirty' approach is actually preferable in some situations"

There are quite a few statements like this in the article, it is clear the guy is very emotional about the issue. Let's see what he says further on:

"Code quality is not the ultimate goal of the development team, but rather one of the options considered for achievement of the real goal of the project, be it commercial success, timely solution of an important problem, or something else"

Agreed

"... there is no positive correlation between the quality of the code and the success of the product..." and also "If there is any correlation between code quality and the success, it is a negative one"

He bases his research on the 80 projects he participated. My impressions that they were mostly not very big projects or the system he built are not very big. But I can also say that this is my experience too. The worst system I ever built (in Perl) was very successful. It had no design whatsoever, not even a procedural one. And in fact it did not have too many bugs, was in production for at least two years. One of the best systems we built never made it to production. Usually the most successful systems I built had moderate code quality, although some of them have excellent code quality.

So anyway, the author says: "... most of the time the 'quick and dirty' approach delivers better return on investments"

Probably the reason for this statement is that the code quality is too expensive but does not bring much benefit. But how about all the projects failures due to the poor code quality? The author argues that volatility of requirements "is the reason for most project failures". This is probably true, although he of course does not count the projects that did not even start because the code was too expensive and risky to modify. Anyway what does the author suggest to fight the volatility of requirements. I suspect that he recommends building a poor code quality system and rewrite it with any significant change of requirements.

"High quality code performs correctly even on edge cases; quick and dirty solutions may work well only on the most frequent case". That's true. But the author argues that if the system will only be used in the most frequent case the quick and dirty solution is acceptable. I think this is more a design defect: why don't we design a system that will only have one or two use cases and remove all unnecessary alternative flows by not designing them into the system? For example, we don't need a breadcrumbs on the data entry applications. And what about all these "Home" buttons on the "wizard" pages? Do you really want the user to go back to the home page in the middle of transaction?

"...high post-release defect density is often related to the high degree of product success". That's true, if the system was never used it has no bugs.

"Despite the fact that several projects had failed, none of the failures was doe to high bug count" It depends how you define failure of the project. Some people define a project failure if it runs over budget or delivered with significant delays. Usually high bug count affects both cost and schedule.

Now the author argues with the theory that it costs more to fix bugs in the later stages of the project. I always thought that the theory was incorrect, but I am using agile principles for 7 years already. He says that "relative costs of fixing a single defect after release decreased substantially since 1994". "In our data, the cost of addressing an issue is not higher in the projects with low code quality". This may be true, but the issues are usually different for the systems with high and low code quality.

Now he says that there are many systems that are only in production for a few months, so why bothering with the code quality. I can agree with one exception: sometimes the business decides to keep the system longer than originally expected. We have one of the examples when a quick and dirty solution is in production already four time longer than originally anticipated.

Very beautiful:
"... a good project manager analyzes the project and designs the development process almost the same way as an architect designs the software."

Very evil:
"It is very natural to perceive the code written by another person as inferior..." But the point is clear: the developers don't enjoy working on the system with low code quality. For me low developer motivation is a project risk.

Good observation about xUnit:
"...xUnit approach means writing more code, and every line of code is a liability" Instead he suggests to use Design By Contract methodology where xUnit is too expensive. I think this is a good suggestion.

Conclusion:
"... experience demonstrates that the quest for the best code is not always justified."

KANO and Agile requirements

One thing the Agile methodlolgy is wrong is in insisting that all requirements must be explicit. Whereas from KANO methodology we know that the customer are explicit about only satisfiers and are implicit about dissatisfiers. Of course they don't even suspect about delighters. Agile methodology is wrong in requiring to explicitly state the dissatisfiers. This is quite irritating for the customers, and if they missed a dissatisfier and it does not get implemented the customer satisfaction swings into negative territory. Good Agile methodology should always make sure the dissatisfiers are implemented as a part of the solution. Correspondingly the customer should be aware that some of his money are going to maintain good standards of software, but he should be confident that all things he is taking for granted will be implemented in the system.

Test-driven writing of standards

We all know about test-driven development, and even test-driven management (which proves to be just setting goals and checking them at the end of the year).

Now I introduce Test-Driven Writing of Standards. Indeed you can start writing coding standards, but it is likely you will miss something, so when you see another ugliness in your code you need first to go and check if your standards cover the problem. If not you need to add it to the standards, and then raise a defect based on the newly added coding standard.

Wiki and Blog in WSS 3.0!

This video shows how to use WSS to create a Wiki web or a blog. WSS also supports RSS. Very cool.

Meeting-driven development

Excellent article about meetings.

Standalone Wiki

I should try this: http://www.tiddlywiki.com/

DBCC MEMORYSTATUS

Whenever you suspect memory problems in SQL Server 2000 use DBCC MEMORYSTATUS. Here is the KB article about how to interpret results.