My recent blog post Non-trivial and real-world feedbacks on writing Unit-Tests has been rewritten in depth with the help of the SimpleTalk team, and published on SimpleTalk as an article: On Writing Unit Tests for C#

This article has been an opportunity for me to dig deeper into several aspects of my experience with real-world unit-testing, especially concerning the Test-First and code coverage sections. The critics and feedbacks I got from the initial post has helped also rewriting this as a more insightful content.

Enjoy!

In my previous post I’ve been critic on the Visual Studio 11 Beta greyed UI (and especially greyed icons!!). Let’s be positive, and frankly it is easy to be positive. I am using VS 11 beta for a week and it will be an awesome release in terms of features and performance improvement. My only hope is that they won’t waste all these efforts, and they’ll fix the depressing UI theme, or at least let the choice to the user to get back colors where it makes the most sense (icons, panels boundaries…).

So one apparently hidden feature, I discovered through the John Robbin’s blog is the new diffing capabilities of VS11! Just type in a command window…

…and you’re done!

If a VS11 instance exists, it will be used, else, a new VS11 instance will be started to host the comparison panel. And there will be also the possibility to compare folders. Notes that with a bit more work, the VS11 diff text files feature could look like the awesome Kompare UI:

And, let’s precise a cool side note, the current version of NDepend supports already this VS11 feature! In the file VisualNDependOptions.xml, that you can find in the folder specified in NDepend > Options > Export/Import/Reset Options, you just need to refactor the <DiffTool/> tag this way…

… and it just works. Of course the next version of NDepend will integrate in VS11 and will cleanly supports this feature:

The user won’t have to tweak the XML manually, VS11 diff will be proposed per default in the list of default diff tools that the user can plug to NDepend:

I am using VS 11 Beta for a few days. If it can help things getting better, I just add my voice to the long list of complaint about the VS 11 no color, now famous, issue!

VS 11 Beta comes with really cool new features,  and is much faster and responsive than the slow VS 2010 (so slow that I am still mainly using VS 2008). But on the new grey mono-chrome design, I estimate they are completely wrong.

The intention underlying this design move is that VS11 appearance should be simpler, less daunting, and distract less the user by letting him focuses his attention on its content. In VS11 Beta, icons are black and grey, making it harder than ever to see at a glance, which ones are enabled and which ones are disabled. The whole point of icons has, and will ever be, to rely on the human eyes ability to distinguish quickly between colors, to locate efficiently a particular icon in the middle of several other ones. For example, at a glance, I cannot rely anymore on the fact that C# file are green-like and folders are yellow like in my solution explorer. Not only now I have to think, but it makes me feel like I am in jail! No joke here, I seriously think such UI will have consequence on my mood.

What the screenshot above makes also obvious is that now, panels titles are drawn with an upper case style, with no more side icons! The panels titles are surrounded with :::::::::::::: patterns, instead of the nice shaded header that used to let me now instantly which panel had focus, and how panels are partitioned. In my opinion all this is completely foolish, and this raise questions on how decisions are taken in the DevDiv? I can’t believe that most VS developers are enthusiast and think that this design shift is an improvement. The management must have been convinced by a small team of highly recognized and convincing designers, which attest their result on scientist studies.

I really hope that the VS management team will listen to the tsunami of user complaints. But admitting in the middle of an effort that we got lost and need to revert back, is not something humans are good at, especially if a lot of people are looking at what you do. Tons of scientific studies prove that!

This wouldn’t be the first time that the VS management is doing it wrong and persist in an obviously wrong choice. They based the VS2010 UI on WPF while VS2008 was based on GDI+ and Windows Form. Hence, VS2010 has been used as a showcase for WPF. But the fact is that GDI+ and Windows Form can do 100% of what WPF can do, faster, much faster actually. Just compare the VS2010 code graph (based on WPF) and the NDepend dependency graph (based on GDI+). Under the hood, both implementations use the same graph layout library MSAgl. But, and this is a fact, the NDepend graph layout is between one and two orders of magnitude faster than the VS2010 ones. And is it really less nice?

The real advantage of WPF is that (in theory) it takes much less development effort to achieve the same degree of perfectness. But apart the smooth zoom in and out into the code editor window, this advantage doesn’t shine in VS2010. And still, the first thing that the user notices is the slowness of VS2010 compared to the good old VS2008!

And notice the irony, that VS11 doesn’t have anymore any eyes-candy, while WPF is especially designed to provide eyes-candy!

There are certainly ways to improve the VS 11 appearance to make it both less distracting for the user, and still appealing with a few colors carefully chosen . Interestingly enough, in the forums, I found this pleasant attempt:

The same way I am still using VS2008 and skipped the VS2010 release because of its slowness, I might be well skip this VS11 release despite of all the new cool features I’d like to have! Sooner or later, I am confident that common sense will win. Some management heads will roll, and we will see back some colorful icons and decent panel titles and boundaries in VS! Better sooner!

The mythical book, Mythical man month quoted that no matter the programming language chosen, a professional developer will write in average 10 lines of code (LoC) day.

After a bit more than 6 years of full-time development on the tool NDepend I’d like to elaborate a bit here.

Let’s start with the definition of logical Line of Code. Basically, a logical LoC is a PDB sequence point except sequence points corresponding to opening and closing method brace. So here we have a 8 logical lines of code method for example:

See here the post How do you count your number of Lines Of Code (LOC) ? for more details.

I already hear the bashing; LoC has nothing to do with productivity, Bill Gates said “Measuring software productivity by lines of code is like measuring progress on an airplane by how much it weighs.“.

And indeed, measured on a few days or a few weeks range, LoC has nothing to do with productivity. Some days I write 200 LoC in a row, some days I spend 8 hours fixing a pesky bug by not even adding a LoC. Some day I clean dead code and remove some LoC. Some other days I refactor exiting code without, all in all, adding a single LoC. Some days I create a large and complex UI Form and the editor will generate automatically 300 additional LoC. Some days are dedicated solely to performance enhancement or planning upcoming code architecture…

What is interesting is the average number of LoC obtained from the long term. And if I do the simple math I obtained around 80 LoC per day. Let’s precise that I abide by high code quality standard. Each LoC must be covered by unit-tests + all possible code contracts must be declared (of course, not all LoC can, nor should, be checked by contracts and some classes are nit relevant for unit-testing, especially UI related classes).

So this average score of 80 LoC produced per day doesn’t sacrifice to code quality, and seems to be a sustainable rhythm. And what is really cool with LoC, is that, once calibrated, caring about counting LoC becomes an accurate estimation tool. After coding and measuring dozens of features achieved in this particular context of development, the size of any feature can be estimated accurately in terms of LoC. Hence with a simple math, the time it’ll take to deliver a feature to production can be accurately estimated. To illustrate this fact, here is a decorated treemap view of most NDepend components.

Thanks to this treemap view, I can compare the size in terms of LoC of most components. Coupling this information with the fact that the average coding score if 80 LoC per day, and looking back on cost in times for each component, I have an accurate method to tune my way of coding and estimate future schedules.

Of course not all components are equals. Most of them are the result of a long evolutive coding process. For example, the code model had undergone much more refactoring since the beginning than say, the dependency graph for example that had been delivered out-of-the-box after some weeks of development.

There is something else interesting this picture is telling. I can see that all these years polishing the tool to meet high professional standards in terms of ergonomy and performance, consumed actually the bulk of LoC. For example just having a clean Project Properties management is implemented through (model + UI control) =(3.751+2.686) = 6.437 LoC. While a flagship feature such as the interactive Dependency Graph only consumes 2.897 LoC, not even a half of the Project Properties impelmentation. Of course the interactive Dependency Graph capitalize a lot on all the existing infrastructure developed for other features. But as a matter of fact, it took less effort to develop  the interactive Dependency Graph than to develop a clean Project Properties model and UI.

All this confirms an essential lesson for everyone that wishes to start an ISV. It is lightweight and easy to develop a nice and flashy prototype application that’ll bring enthusiast users. What is really costly is to transform it into something usable, stable, clean, fast with all possible ergonomy candy to make the life of the user easier. And these are all these non-functional requirements that will make the difference between a product used by a few dozens of enthusiast users only, and a product used by the mass.