I am very much looking forward to the new .Net Parallel extensions being RTM'd.  This Post from Stephen Toub shows just how simple and flexible the framework is. I for one can think of quite a few pieces of work that I am working right now that will seriously benefit from these new extensions. On Monday i think ill be getting the June CTP!

I had an interesting discussion with a tester the other day. I had put down a couple of beers, so had the dutch courage to let him know what i generally think about system testing. In a nutshell, I am not a fan of manual testing. Sure there is a definite need for it, but generally manual testing gets bogged down and I for one, (talking from experience - not just a random thought), think a comprehensive regime of unit testing adds infinite more value to a software project than manual testing.  The reason is a theory known as moral hazard. 

Moral hazard, as defined in the above Wikipedia link is " the prospect that a party insulated from risk may behave differently from the way it would behave if it were fully exposed to the risk". It is a theory generally used within the insurance marketplace.  The idea being that if too much protection is given to an insured party, they will behave in a manner that may give rise to them not protecting the insured assets from harm.  They are more likely to use the asset for risky purposes, to abuse it etc, asultimately they would know that in the event of the asset being destroyed, lost or broken, they would be protected by the insurance.  

From a developer/tester relationship standpoint, there is a clear moral hazard - and it's not the tester's fault. A developer who chooses not to unit test, or does a half-baked job of it, knows that the end product will still be system tested. They know that if a bug escapes out into the wild, that it would be the tester who gets it in the neck, and that they would only suffer a consequence if the bug was something deeply technical and outside of the scope or understanding of system testers.  This gives rise to questions targetted at testers such as "Why didn't you test this?", "how did this get through test??" etc.  It's almost as if the developer discards all responsibility and accountability as soon as the software moves into test. (by the way i know not all developers are like this but many, many, many of them are).  The moral hazard is clear.

If a developer is compelled to create highly effective, high coverage unit tests, then indeed they lose the moral hazard - they are responsible for their own quality. You could argue that this shifts the moral hazard onto testers, however i would argue that a well put together suite of unit tests in the order of 95% code coverage, and using proper assertions Is far less risky than allowing side effect ridden code through to test. Testers simply aren't going to catch all the sublte issues in the code, that only properly written unit tests can find. The other nice result of the above approach is that testers would then be testing functionality - not struggling through lots of minor technical bugs that would have been caught by unit tests.  This means that bugs are only likely to be found when a) there was a misinterpretation of requirements and b) the requirements were themselves incorrect.

In my experience, approaching a new project in this manner is highly effective.  Testers actually become nervous because they can't find many (or any bugs), but quickly everyone realises why this is, and testers become much happier because they can get on with their jobs and not fight against low quality, nonunit tested code. Also the final product is of vastly superior quality. 

Moral Hazard is not just an issue for insurers  - it's some thing that we as developers also produce by our choices about quality. If you don't own your own quality, you can't really expect to produce quality systems, and you can't always blame the tester if that happens.  

After months of having IE7 crash whenever loading anything more than simple content, I have finally worked out the problem. I've been blaming Vista for this since the beginning and it seems, alas, I was wrong. The culprit was Nvidia's Network Access Manager which somehow made its way onto my machine. 

Before getting rid of it, I could never load complex sites like Facebook. Fortunately I'm sick to death of Facebook so i could live with it, but it made me feel like something was wrong with my super cool Alienware high spec rig. After all, Internet explorer is so ingrained into Vista, that it makes you nervous whenever it seems rather unwell. 

Makes you wonder how many other issues with Vista are actually issues with third party vendors. You would think they would fix an issue like that but hey...

This post by Tim Bray of Sun Microsystems provides a nice bit of History about the beginnings of XML and the people who made it happen. It's hard to believe it's now over 10 years old. I remember early on in the life of XML when not that many people really understood it, what it was supposed to solve and how it was formed. Many people i knew were perplexed about finding out how to 'write xml', thinking there was a single form that solved all problems. Indeed, it was this casual, human readable nature that made it initially rather foreign to some people so used to 'set format' HTML markup.  Only when people realised the true scope and power of writing well formed, hierarchical, validated data in a human and machine readable form did it take off like wildfire. Most developers now don't go a day without seeing  xml.

Of course while it solved so many problems, it created nearly as many. XML Bloat is still an issue for instance. It can be a performance killer. But like all things that CAN be misued, it is highly likely with such an open and ubiquitous tool it WILL be misused. Nothing is absolute, and personally i think Xml's positives far outweigh the negatives.  So 10 years on and xml now forms the basis of messaging, data storage and retrieval, configuration, presentation (WPF etc!), decision logic (rules engines), entity representation, APIs and more. It's even used in the likes of Video games like World of Warcraft.

Well done for surviving the decade - I can't see Xml retiring anytime soon!

Yes finally, Jetbrains have started nightly builds for Resharper 4.0.   You can find the latest EAP notes here.  There are some quite interesting features in there including support for most of the new C# language features. Lambdas are only partially supported and there is apparently no LINQ support just yet. No doubt that will annoy some people, but at the end of the day I think i'd rather masses of red lines than lots of error windows due to the feature being really buggy.  It's also worth remembering that none of the builds currently available (2 at the time of writing) are EAP or even EAP candidates. Therefore don't expect too much just yet.

And you though towels were just for drying stuff? Apparently not ... 

Target Process is a great Agile process management and iterative development tool. It is amazing for several reasons.

Firstly the people who make the tool clearly work within a very agile environment. It is clear from their blog that what they do on a day to day basis is represented in the sheer coverage of the tool.

It is a tool that is priced very well (ie it's super cheap -especially if you let them host it). Unlike some other tools which cost literally thousands (thinking of a large test tool provider here whose name starts with M), Target Process is cheap and yet it does everything a true Agile developer, PM, tester, customer could want it to do. It can manage whole projects and does so in a very cool way.

Target process has nice features such as Task boards which can be used for distributed teams. It represents stories and sprints (iterations) really well too. If your team is distributed around the world or even in multiple offices then it's a great tool for you.

It's very simple and isn't overly busy like many other web based Agile tools.

It easily fits into Scrum or XP models, as well as FDD and presumably any other Agile or iterative process model. You can even change the workflows and terminology associated with any given process.

It's well designed (Ajax based web browser interface), its quite fast and it is very slick. Not dull and depressing like some others. It also has a really cool reporting capability.

Overall I can't recommend this tool enough. I've used it before on projects and I even use it for small background work for my company, Supple Technology Solutions (UK).  Its even something you could adapt for personal endevours such as the "Getting Things Done" method ... and it' not so expensive to make that seem ridiculous. 

Version 2.7 Is out now and has been improved even more. In fact another cool thing about this product is that they update it very often, usually with very clever features. You can tell that this product's features are motivated by developers who work in an iterative environment and not marketing and product managers . Let's hope it stays that way!

One of the first things you learn in the book "The Pragmatic Programmer" is not to break windows. To explain this more clearly, it has been shown that an abandoned house in good condition (no broken windows) will tend to stay in relatively good condition if it is maintain such that broken windows are fixed and fixed fast. As soon as one window is broken (the neighbourhood kids throwing stones lets presume), and no-one fixes it, then it becomes 'OK' to keep on breaking windows. Once this starts, the house rapidly becomes degraded with more and more windows being smashed with impunity. In a similar way, councils these days will try to remove graffiti from walls as soon as it goes up, (with the exception perhaps of Banksy!), making it clear that it's really not worth the bother of putting it there in the first place because no one will see it.  This is a very pragmatic ideal because it is about being disciplined to fix problems as they happen and not let them spiral into bigger problems down the line.

Have a look at this article on Coding Horror for more detail: http://www.codinghorror.com/blog/archives/000326.html  

Yet.. with the onset of more and more people adopting (and interpreting) agile, pragmatism is slowly being bent into meaning 'quick and dirty... just get it done'. One can argue in a highly intense environment that the most pragmatic approach to keeping a business afloat is to make sure that problems are patched up. If the problem goes away for now, the business will be happy... for now.  Pragmatism is becoming 'hackmatism'. 

If a broken window is  taped up... the problem is not resolved. If the window is removed the problem can be said to be resolved, but you are left with a windowless building. If the window is boarded up you have a similar problem.  So you are left with few options. You could say well "this is bad area ... even if we fix the window today, it will be broken tomorow". In this case you can invest in commercial level coatings for the windows - so that the problem is severely decreased. You could replace the windows with tough plexiglass so that the cost of the problem is perhaps decreased. But on the whole, I personally believe that if you fixed the windows quickly, (or better yet never let it get to that in the first place!) the problem would resolve itself. Removing ourselves from the 'window' analogy for a minute (the analogy starts to leak here), remember that in the software development world, if the people breaking the windows keep on breaking them (ie intentionally or through gross incompetence) you have many more options available for dealing with that scenario. You're dealing with developers, not roaming gangs of kids!  The pragmatic solution is the one that solves the problem quickly.... not patches the problem quickly and sweeps it under the carpet.

 More and more project managers are playing the pragmatic card these days as a way to meet schedules. In interviews almost all developers will call themselves pragmatic. Pragmatic doesn't really mean anything when it has been reduced to "I will always look for quick fixes... not solutions".  When building bespoke systems, it is too late to get to delivery with a thousand bugs (and more and more on the way), start hacking in fixes, and start calling yourself pragmatic.  The pragmatic developer looks at a problem at the outset and finds a solid solution. They use pragmatic techniques to build robust, quality systems. They spend time putting in place unit tests that actualy do something rather than being completely tokenistic. I don't think anyone originally thought pragmatism meant do the least possible work, or mean don't think through what you are doing. 

There are plenty of scenarios where you simply must thrown in a quick fix. The business should drive technology and not the other way around. Many businesses would go bust without the quick fix. But should we really be putting this type of behaviour up on a  pedastool?  To get to the point where you don't have time to do anything properly, you have not been pragmatic and you no longer can be pragmatic. The windows are broken, and the local gangs (bugs) are breaking more.  

Quick hacks beget more quick hacks.  They might need to be done, but don't celebrate the fact and please don't tell me it's pragmatic.

Welll as you would no doubt know, today Microsoft put in a  US $44B Bid for Yahoo the internet search 'giant'. You know i really wish Microsoft would just stick to its roots and build cool applications. They've never been that good at mass internet consumer products (with the big exceptions of Hotmail and MSN, the first of which has been significantly improved on by Gmail). Why are they so obsessed with search? Personally I just can't see them turning Yahoo into a real competitor against Google. 

The problem with today's Microsoft (imho) is that they've bitten off more then they can chew. It's almost like they obsessively have to try to compete at everything. Now they seem vastly overstreched, at war on several fronts (pending and past court judgements etc),  and have been reduced to a marketting and product manager driven culture of late delivery. I'd personally prefer if they would spend that $44B on making their core suite of products rock solid and user friendly like they used to be. And while they're at it go back to the sort of documentation and helpful content that used to be on MSDN.

Seriously Microsoft, go back to what you were always good at. Don't dilute your products by spreading yourself thin in someone else's market place. Google are very good at search because they just do search. Anything else they do on top of it is generally small and simple and aimed at making the core product better. By casting the net so wide, Microsoft is diluting the core (Windows, Office, Developer tools) and throwing money into an area that quite simply has been done and dusted by a focused and dedicated competitor.

Remember when you were learning the Software industry way... i remember one of my more enlightened University lecturers (there were few), who introduced me to the concept of GIGO (Garbage In, Garbage Out). The concept basically says that if you load lots of rubbish and faulty, erroneous data into your application then you can expect your application to return the garbage in kind. Kind of like data karma.

GIGO falls into the category of 'no-brainer'. But it's probably one of the most ignored fundamental concepts we have in existence. There are very few systems i have seen where developers make a point of preventing crap getting into their systems.  GIGO is fundamental to a number of basic architectural areas. For example,  It is the basis of  many security concerns (don't allow invalid data in or it might be harmful), and It is the basis of data quality.   Moreover I believe that GIGO is fundamental to basis system stability, robustness of applications and has a direct correlation to defect counts.

On a technical level we need to ask ourselves a few questions. If you allow potentially harmful data into your application, and you could of prevented it by doing nothing more than basic checks, is that a bad thing or is it an acceptable risk?  I think it is a ridiculous risk. So what counts as bad data from an application architecture perspective? Think about the following:

• Allowing null values to permeate into parameters on public methods.
• Allowing invalid sized strings, negative numbers (when only +ve are allowed) or other such data in
• Allowing data to enter through poor, ambiguous use of typing. (ie exposing object parameters when a generic or less abstract type parameter would provide more protection)
• Using null values as flags, decision points etc
• A host of other scenarios

So what is fundamentally wrong with say allowing a null to permeate? A null is the source of many errors. Firstly while you can gleam some meaning from a null, they don't play well if you manage to encounter one unexpectedly. I find it totally unaceptable to find code littered with ObjectReferenceNotFound errors. 99% of which are completely avoidable. So Look at the following  overly simplified code sample. It is highly susceptible to this type of error:

        public void ProcessOrders(List<Order> orders)
        {
            
            foreach(Order order in orders)
            {
                if(order.OrderLines.Count > 0)
                {
                    //Process Line
                }
            }

        }

First of all, orders could be null resulting in a bad error. Then OrderLines might be null too.  I would not go to the level of checking deep down into object hierarchies, but you should definitely check that orders is not null.

 	 public void ProcessOrders(List<Order> orders)
        {
            if(orders == null) throw new ArgumentNullException("orders");

            foreach(Order order in orders)
            {
                if(order.OrderLines.Count > 0)
                {
                    //Process Line
                }
            }

        }

You can easily create utilities to make this a simple and pain-free process. You can do similar things to check that collections are populated (before indexing) to prevent out of range errors and the like. It's all very simple but solidifies code and makes a huge difference when your code goes into the wild.

Another big no-no in my book is to pass around really ambiguous chunks of data and then never bother to validate these 'chunks'. For example passing strings hopefully containing properly formed and valid XML. This is really bad these days when you can serialize pretty much anything. Passing non-standard data and then using if or case statements to work out what that data is supposed to be is also asking for trouble. It's all about being explicit and making sure that in the scenarios when you do have to pass losely formed or un-typed data around that you do validate it on the other end, and you should always expect one and only one data format for any given piece of data. Less moving parts, less chance for error, simple validation, less bugs.  

In my experience if you use a few simple asserts, guards and other defensive techniques, and back them up with a really solid unit test suite you can reduce your bug count down to near zero levels. It's worth the extra effort to make sure you don't get Garbage out by not putting garbage in there in the first place!