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.

I began writing tests around 8 years ago and I must say this revolutionized my way of developing code. In this blog post, I’d like to group and share several non-trivial feedbacks gained over all these years of practicing real-world testing.

Test Organization

There must be a one-to-one correspondence between classes tested and test fixture classes. Very simple classes like pure immutable entity (i.e simple constructors, simple getters, and readonly backing fields) can only be tested through test fixture classes corresponding to more complex tested classes.

The one-to-one correspondence stated above makes the following operations easy and straightforward:

• writing a new test suite for a currently created class,
• writing some new tests for an existing class,
• refactoring tests when refactoring some classes,
• identifying which test to run to test a class.

Tests must be written in dedicated tests assemblies because product assemblies must not be weighted with test code. Hence tests and tested code lives in different VS projects. These projects can live in the same VS solutions, or in different VS solutions.

Having tested code VS projects and tests VS projects living in the same VS solution is useful to navigate easily across tested code and tests.

If tested code and tests live in different VS solution, a global VS solution containing both code and tests VS project is still needed. Indeed, such global VS solution is useful to use refactoring tools to refactor at the same time tested code and tests

Test-First and specifications

I don’t abide by the test-first theory. Tests concerning a code portion should be written at the same time than the code portion. The reason I advocate to do so, is because not all edge cases can be faced up-front, even by expert of a domain and professional testers. Edge cases are discovered only when thoroughly implementing an algorithm.

Test-first is still useful when tests can be written up-front by a domain expert or a client, with dedicated tooling such as FitNesse. In this conditions test-first is a great communication mean that can remove many pesky misunderstanding.

However only the code itself is the complete specification. Tests can be seen as a specification scaffold, that is removed at runtime. Tests can also be seen as a secondary less-detailed specification, useful to ensure that the main specification, i.e the code itself, respects a range of requirements, materialized by tests assertions.

Test and Code Contracts

Calls from tests to tested code, shouldn’t violate tested code contracts. When a contract is violated by running tests, it means that the tested code is buggy or (non-exclusive) that the test is buggy.

Assertions in tests are not much different than code contract assertions. The only real difference is that assertions in tests are not checked at production-time. But both kind of assertions are here for correctness, to buzz as soon as something goes wrong when running the code.

Test Coverage

The number of tests is a completely meaningless metric. Dozens of [TestCase] can be written in minutes, while a tricky integration test can takes days to be written. When it comes to test, significant metrics are:

• percentage of code covered by tests and
• number of different assertions executed.

Not all classes need to be 100% covered by tests or even covered at all. Typically UI code is decoupled from logic, and UI code is hard to test properly, despite the progress in this domain. Notice that UI code decoupling, which is a good design practice, is naturally enforced by tests.

When testing a class, covering it 100% is a necessary goal. 90% coverage is not enough because empirically we observe that the 10% non-tested code contains most of unidentified bugs.

If to cover 10% of the code of a class it takes as much effort as covering the other 90%, it means that this 10% of code needs to be redesigned to be easily testable. Hence the 100% coverage practice is costly only when it forces the code to be well designed.

Having zero dead code is a natural consequence of having code 100% covered.

It is a good practice to tag a class 100% covered with an arbitrary [FullCovered] attribute because it documents for future developers in charge of an eventual refactoring, that the class must remain 100% covered.

Code 100% covered by tests + containing all relevant contracts, is very hard to break. This is the magical practice to be very close to bug-free code.

Personally I consider that the job is done only when all classes that can be covered by tests are indeed 100% covered by tests.

Test Execution

The concrete difference between unit tests and integrations tests is that unit tests are in-process only, they don’t require touching a DB, network or the file system. The distinction is useful because unit-tests are usually one or several orders of magnitude faster to run.

Tests must be run from the build machine to validate any code before it is committed.

Test should be fast to run, like a few minutes maximum, because tests must also be ran often on the developer machine, to detect regression as soon as possible.

Having a one-to-one correspondence between tested class and test class + 100% coverage, makes easy to identify which tests to run for a particular piece of code.

Test and Refactoring

Last released version of the product that is working fine in production, should stress out that bugs are more likely to appear on newly developed code and refactored code. Hence tests must be written in priority for newly developed code and refactored code.

When some refactored code is not properly tested, it is a good practice to write tests that should have been written in the first place. However this practice of testing refactored code is not mandatory because it can be pretty time consuming.

Code 100% covered by tests + containing all relevant contracts, can be refactored at whim. In these conditions, there are very few chances to miss a behavior regression.

Test and Design

Code that is hard to be covered by tests is bug-prone and need to be redesigned to be easily coverable by easy tests. This situation often results in creating one or several classes dedicated to handle the logic implemented formerly by the code hard to cover by tests.

The previous point can be restated this way: writing a complete test suite naturally leads to good design, enforcing low coupling and high cohesion.

Singletons should be prohibited because they make the code hard to test. It is harder to re-cycle and re-initialize a singleton object for each tests, than it is to create an object for each test.

Mocking should be used to transform integration tests into unit-test, by abstracting tests from out-of-proc consideration like DB access, network access or file system. In these conditions mocking helps separating concerns in the code and hence, increases the design value.

Mocking is also useful to isolate code completely un-coverable by tests, like calls to MessageBox.Show().

Test Tooling

Personally I am happy with:

• NUnit, I like the fact that only the NUnit.Framwork.dll needs to be referenced from VS tests project and that NUnit is supported by all testing tools.
• NCover, it is the fastest code coverage tools available. Its performance are almost magic since in coverage mode tests are executed almost as fast as without coverage. Contrary to VS coverage, the assembly instrumentation phase is completely transparent for the user, and coverage results files are easier to work with. Also NCover is very easy to use and integrates with most testing tools.
• TestDriven.NET, its flawless VS integration made me addicted to it. Resharper also comes with cool testing facilities but my addiction to the simplicity of TD.NET is too high.
• When it comes to testing NDepend is especially suited to create rules to continuously check for code coverage by tests, to ensure that new and refactored code is properly covered by tests and to navigate between tested code and tests across VS solutions opened in different VS instances.
• It is worth also keeping an eye to ContinuousTests currently in beta to identify which tests to run when a portion of code is touched, and run them in background.

Today, I won’t talk about coding, while I see this discussion related to programmer’s life. If you read CodeBetter you are certainly a programmer, making and saving money with your coding skills and your energy. I’d like to talk about a few things related to money and especially loan. The point is that getting in debt is essential in life. In this time of crisis, where millions of people got ruined because of their loan, I don’t want to sound ironic. The secret is to get in debt with a fixed interest rate loan. The important word is fixed. Why? Because of inflation!

A word on Inflation

Inflation is the measure of the fact that the price of everything increase over time. Something that costs 2 bucks today, used to cost 1 buck a few years ago and will cost 3 bucks in a few years, we all know that. If you talk with your dad and ask the amount of salary he got, you might be surprise to hear it was a just a fraction of your salary today.

For example, your dad as an engineer was paid 25.000 US$ a year 20 years ago while you get pay 70.000 US$ today. 20 years ago, to purchase your dream’s house, a loan worth 8.000US$ a year over 20 years was enough. But today the same loan for the same house could cost well 30.000US$ a year. The amazing thing with fixed rate, is that, if today you were about to pay the last annual fee for your 20 years fixed rate loan contracted in 1991, it would cost only 8.000US$. If it was a variable rate loan, you could be well paying much more instead! So with a fixed rate loan, the higher the inflation is, the more you win. Getting in a long term fixed rate loan is the way to see inflation as something positive.

So what can we say about the near future of inflation? Nowadays, both US and Europe states got into an insane debt level. The US debt alone is worth 15.000 Billions US$ while something as ground-breaking and successful as Microsoft, Google or Apple ranges in the 100 Billions US$. The following famous picture represents the US debt stacked in 100US$ bills:

There is absolutely no way these debts will be honored properly. What could happen is debt canceling, which could provoke a war with say, China that owns a large portion of the debt. More preferably and more realistically, what will happen is that government will provoke more inflation. Nobody likes inflation, because it ruins people, corporations and economy. Remember? the only winners in case of inflation are those who have a lot of debts.

Actually during the last 25 years inflation has been kept low artificially, because states changed their strategy and borrowed to tiers actors like banks and other states, instead of borrowing to themselves. Indeed, before that period states used to borrow to themselves by provoking inflation. The result of this new strategy is the insane debts. More inflation is something governments know how to start, by printing more money, but don’t know how to stop. Hence they are still reluctant to go back again with inflation, but inflation is the only chance to give the global debt less value, and maybe get the head out of this situation one day.

If you look at historical US inflation, you’ll see low 3% to 5% rate since 1985, while it used to be up to 13,58% in 1980 and even more after the two world wars. I produce this US inflation graph from 1914 to 2010, from data available here, : http://inflationdata.com/Inflation/Inflation_Rate/HistoricalInflation.aspx

If you contract say, a 4% interest rate loan today, each future annual inflation rate above 4% will make you richer. And as said, there are serious reasons to think that inflation rate will grow insanely soon. Inflation rate above 10% has been reached not so long ago, this is clearly part of the possible.

Visualizing Compound Interests

Recently, me and my relatives had the chance to contract a few fixed rate loans, and I got pretty interested into the math beyond it. It is actually pretty basic math, but still, Einstein called compound interest:  the greatest mathematical discovery of all time. To my disappointment, I found zero compelling offers on the web to quickly play with loan parameters (amount/term/rate) and get an immediate visualization of the impact on the loan cost. Weird but true: There is no good offer to visualize properly what is certainly the most important financial decision anyone has to take?!

This is why with a friend working in the financial area we created the free site http://www.loanfor.us/ in English and http://www.simulcredit.fr/ in French. At a glance, you can see that if you get a 20 years long loan for 300K US$, the loan amortization will look like that with a 4% annual interest rate:

And like that with a 8% annual interest rate:

And like that with a 12% annual interest rate:

The orange area represents the cost of the interest of the credit, while the green area represents the 300K borrowed. With an interactive calculator it is clear that the interest cost are not 4%, 8% nor 12% of 300K, which are 12K, 24K and 36K. The interest cost are 154K, 320K and 511K or 52%, 107% and 170% of the amount borrowed!

Imagine to give away 511K to have the chance to reimburse 300K!!! My dad said that 30 years ago, it was not exceptional that the interest cost could grow up to 200% of the amount borrowed. Of course, in these conditions assets like real estate prices are decreasing. On the other side, nowadays nobody is trusting finance and economy anymore, and with gold, real estate remains a compelling investment, which makes real estate price increasing. With these two opposite trending playing against each other, today nobody can predict how assets or gold prices will evolve.

Another interesting graph is the monthly repayments vs. the loan term vs. total credit cost, below in yellow.

There is a balance here, between short term high monthly repayments and long term high total credit cost, choose one. Because of the potential future high inflation, my bet is that long term like 15 to 25 years are preferable. It is also preferable because this way you can borrow more and purchase more and bigger assets today.

So what?

Thanks for following my reasoning; it is now time to go back to cool coding activity. But make sure to free up some brain cycles to mull over all this, because no matter how hard you are working to make money and save money, if you don’t invest money properly today you are taking high risks. Putting money at the bank means that bank owes you money, and getting in debt means that you owe money to the bank.

I am not a financial expert but no expert can predict the future of finance, else the world wouldn’t be there. Please don’t take my advices for granted I might be well totally wrong. But it is certainly worth defining your own opinion and financial strategy based on facts, not based on what others say. Those who have been called finance expert didn’t predict the major crisis we are now facing for 3 years. Bother to listen to one advice only if you have a proof that one is applying the advice to himself.

We recently released the product JavaDepend. As its name suggest, this product is the java adaptation of NDepend. Including CppDepend for C++, we now have 3 products that share around 90% of the initial NDepend code base. Each product comes with its own analyzer layer to build the internal code model from .jar, .java, .dll, .exe files.
In case you are aware of XDepend, JavaDepend is a replacement for XDepend. A completely new product has been designed actually. The main and huge advantage of JavaDepend is that it is built over Mono because it works both on Windows and any Linux distribution. A JavaDepend Mac version is in the pipe.

I’d like to feedback here a few interesting notes on migrating a large legacy code base to Mono.

Before beginning any migration task, we needed to clearly evaluate the future pain points and have an idea of time and resources needed to achieve the migration. For these reasons we needed a tool to tell us which piece of code wasn’t properly managed by Mono.

The Mono Migration Analyzer (MoMA) tool did the job! This tool helps identify issues you may have when porting your .Net application to Mono. It helps pinpoint platform specific calls (P/Invoke) and areas that are not yet supported by the Mono project.

When we analyzed our binaries with MoMA , the main issues concerned our usage of the DevExpress DXperience Windows Form library. At this point we were confident that resolving this issue was the key for a successful migration.

Most of .NET professional program are based on some GUI libraries like the ones provided by DevExpress , Infragistics ,ComponentOne and so on. In NDepend we use DevExpress for the following benefits: Nice an Modern GUI components , Docking  support, Theme support, Ribbon.

We searched for an alternative working on Mono but none of the mainstream GUI lib did the job. All these libraries use P/Invoke and thus, no one is mono compatible.

To solve this problem we then choosed to use the standard .NET Components. But if we modify all our code consuming GUI, we will have two versions to maintain, one for windows and another for linux. To avoid this problem we choose to develop a wrapper with a contract similar than the DevExpress DXperience classes NDepend is consumming.

What about DevExpress components and features not present in the standard framework?

• Docking: Unfortunately there’s no docking features in the standard framework, and no docking component working on mono with the same features as DevExpress exist, the only interesting one that works on mono is the Dock Panel Suite. We used this component but we disabled the drag&drop feature , to let it work on Mono.  GTK# contains a docking container, but we can’t use it with standard winforms.
• Ribbon: We choosed to disable our look and feel using Ribbon, because no Ribbon component based on standard framework exist.
• Theme support: Same as Ribbon, we disabled changing theme feature, we didn’t find any interesting theme support.
• GDI+: NDepend relies massively on GDI+ for the Matrix,Treemap and Dependency graph views. Even if GDI+ is implemented on mono, we were not sure whether it was working as expected without any modifications. But to our positive surprise, the Mono implementation of GDI+ did the job! Bravo! I really have to congrat the Mono team here!
• P/Invoke: Fortunately, in JavaDepend code base we use rarely P/Invoke , and replacing them with a 100% managed code was not a difficult task.

Let’s mention 2 problematic Windows Form components not working properly on Mono:

• DataGridView/ListView: When working with these components on Mono, everything seems OK at first glance, but after some testing, many crashes appear. For all of them a System.ArgumentOutOfRangeException is thrown. There are many bugs opened concerning these issues, and we can’t afford waiting for a stable Mono release fixing them. For that we created our own components suited to our needs, based on the actual Mono source code. There, we see clearly the power of OSS!
• RichTextBox: When we want to use the Windows Form RichTextBox as a text editor for windows, many hacks are needed, and many of these hacks use P/Invoke. In the case of Mono, unfortunately there’s no way to hack to use the standard RichTextBox. The only way is to modify the Mono component code source. So we created our RichTextBox based on the existing code source, and like for the DataGridView, we adapted it to fulfill our needs.

All in all, this experience advocates for the fact that Mono has reached a level of maturity sufficient to run a professional application on it. The migration to JavaDepend took around 3 man months. As explained, there are still room for improvement, but still, Mono is an impressive project! I hope this feedback can be useful to you, dear reader, if you need to migrate a piece of .NET code to make it works outside of Windows. Good luck! … and long life to JavaDepend!