Tuesday, September 09, 2014

Visual Studio 2014 CTP - first impressions

I’ve installed the latest VS2014 CTP3 on my aging I3 home machine – because why use a VM when I can always re-install windows.
And so far I’m impressed! this is a low end I3/4GB machine and it loaded fast and works without any noticeable performance issues – I might be mistaken but it seems the performance is so much better then previous versions.
I’ve stated by creating a new project and when I’ve tried to rename Class1 to the less generic MyClass I was surprised to see a new dialog opening up – it’s no Resharper but looks like VS refactoring is heading in the right direction:
Also – preview changes – just in case you want to check what exactly a “trivial” rename has in store for you:
Just to make sure I’ve checked the “Refactor” menu (what do you mean – what refactor menu???) and it has the same options we has in VS2013 but I did find two new options available – Quick fixes (whatever that is) and Organize Usings which I miss whenever I’m forced to use “plain vanilla” VS.
It’s not much but I can only speculate that with Roslyn inside we’ll see a many more Refactorings options (and inspections) real fast real soon - both by Microsoft and the “Community”.
After tinkering with the IDE for a while I was ready to try some cool C# 6 features.
I’ve added a Primary Constructor since I wanted to try the new Read-Only Properties feature when VS politely informed me that the feature is only available in “experimental” language version.
By the way – notice how much information I got just by hovering over the code – and it got to me as fast as my cursor moved.
After a quick trip to Google and back I found that in order to use the new C# 6 features all I need to do is update the project file (.csproj).
And so I’ve opened the project file using XML editor and added the required magic:
And the error went away –  and I got to compile this:
How cool is this – I have a Primary Constructor (after the class) and I can use the values passed to initialize fields and properties – read-only  properties!

So far it seems that the old(er) VS2013 on my machine was not affected and it’s still working just like before the installation – but I haven't done extensive development on this machine (because it’s slow) and so I won’t install it on my main machine (yet).

But so far so good…

Sunday, August 31, 2014

A few days ago a colleague of mine asked me to help with strange errors his C++ project kept throwing at him.
Since it was a C++ project we had more than 200 compilation errors but as the  C++ veterans that we are we’ve ignored most of them and scrolled up until we’ve found the patient zero of the issue – inside an header file that looked something like this:
class MyClassWP8

    MyClassWP8& operator=(const MyClassWP8&) = delete;
    MyClassWP8(const MyClassWP8&) = delete;
    MyClassWP8(MyClassWP8&&) = delete;

Do you see the problem? – me neither.

If you’re not familiar with delete/default keyword (for a method), it’s a (relatively) new functionality added as part of C++ 11.
In C++11, defaulted and deleted functions give you explicit control over whether the special member functions are automatically generated. Deleted functions also give you simple language to prevent problematic type promotions from occurring in arguments to functions of all types—special member functions, as well as normal member functions and non-member functions—which would otherwise cause an unwanted function call.
Back in the days of VS2012 this functionality was not supported but since we were using VS2013 there was no apparent reason for it not to work.
We’ve verified that VS2013 support default/delete in desktop, WP8.1 and even Windows Phone Silverlght 8.1 applications. However when using the good old Windows Phone 8.0 application the code refused to compile.
After enabling verbose build  (Properties –> C/C++ –> General –> Suppress startup logo == No) I found the reason for the issue - while all of the projects used the newest C/C++ compiler

Windows Phone 8.0 projects used and older compiler version that do not support some of C++11 features including explicitly deleted functions.

this is both logical and annoying at the same time - I guess that’s one more reason to upgrade to WP8.1.

Happy coding…

Monday, August 25, 2014

Unit testing – you’re measuring it wrong

I’ve been having this problem ever since I’ve started teaching (and preaching) about SCRUM, clean code, unit testing and TDD and any other software development practice.
When implementing a change - how do you measure its success?
For that matter – how can you measure a developer productivity?
Faccia is watching by Our Hero, on Flickr
Creative Commons Creative Commons Attribution-Noncommercial-Share Alike 2.0 Generic License   by Our Hero

A few years ago I worked with a “brilliant” manager who tried to measure developer’s productivity by counting the number of bugs a developer fixed on a given day. Being my argumentative old self I’ve explained that no two bugs are created equal and besides we should aspire not to write these bugs in the first place.
My comment was not well received – I was branded a subversive element – he felt that I wanted to prevent him from assessing developer’s work (which I didn’t).
Over the years several attempts has been made to calculate developer’s productivity – with similar result such as counting lines of code:
“Measuring programming progress by lines of code is like measuring aircraft building progress by weight.”
- Bill Gates
And it only get’s trickier when faced with the need to measure unit testing efforts.

How to measure unit testing effectiveness

The problem is that it’s impossible to measure both how much time was saved and how many bugs were prevented. The only viable way is to have two developers write the same feature and compare the results – and I’m yet to find a company willing to throw money down the drain.
A few years ago I found a research (which I use all the time) that did something similar: two teams working at the same same projects, one using TDD and one not were timed coding time and bug density was checked afterwards (guess who had less bugs). Unfortunately I cannot reproduce that experiment on every single company I work with in order to show that unit testing/TDD improved the way they are doing things.
There are two “matrices” that seem to interest managers when unit testing are concerned:
  1. Test count (i.e. how many tests we have)
  2. Test coverage (i.e. what percentage of the code was tested)
Both are inherently flawed.
Test count does not tell me anything about the project’s state and it’s impossible to provide a number of tests per feature developed - how many tests are “enough”? 10, 100, 1000 or maybe a million?
As for code coverage it’s a tool, a very effective tool that helps me daily to find code I need to test and help me understand how healthy my unit testing suite is – to put it in the words of one of a former boss of mine:
What do you mean 20% code coverage? we had 75% three months ago…
I know that I need an excellent reason to have less then 50% code coverage for a component, but how much coverage is enough coverage? 80%, 95% or 100%?
And just like any other tool code coverage can be gamed and easily abused to show good results for very bad code and tests.

Both code coverage and test count are good at showing quantity not quality and can be used to measure progress (to some extent- we had 100 tests a week ago and 50% coverage and now we have 1000 tests and 85% coverage), and both should be handled with care.

Why do you want to know?

There’s always a reason behind the need to measure or predict success. Usually when asked about measuring unit tests it’s due to a need to estimate future effort (which we still don’t know how to do). Someone up the food chain needs to fill reports, Gantt-charts  and approve expenses and needs to know what would be changed in the next X days/weeks/months. Perhaps the guy who wanted to start using unit tests needs to explain it to his superior or investors.
The problem is that any metric given would be inaccurate – I can show you two different projects with roughly the same amount of unit tests and 90% code coverage -one would be a success and one an utter and complete failure.
From time to time I’m forced to provide these guesstimates – since people need to be able to know where they heading and how much work is planned. When doing this I do my best to explain that these are educated guesses and the real benefits are more then these numbers but hard to predict and quantify – but no one ever listens…
It all comes back to the fact that I cannot show time saved nor bugs which were not created due to the change – the two factors that I find most interesting.

Success is measurable – in retrospective

I promise you one thing – after a short while the team would feel the change – for better or worse (usually for the better). Adding features would be a breeze, less bugs introduced with each new feature, shipping a working product would be easier and faster and developers tends to be more effective in their work (and usually happier)
Success by aloshbennett, on Flickr
Creative Commons Creative Commons Attribution 2.0 Generic License   by aloshbennett

I usually use nDepend to show the current code complexity and how various coding violations disappeared after a few tests were written an refactoring were made.
Looking back after a few weeks I can show real tangible improvement that I couldn’t possible predict with an accurate number.
And so I keep collecting these numbers with hope that someday when asked to predict or set measureable targets for developments I’ll have  a good answer…

Thursday, July 24, 2014

Designing with Tests talk at IASA

Last week I had the pleasure of presenting at the local IASA (International Association of  Software Architects). I talked about how to use unit tests to design software and the role of the architect when using TDD.

It was a good talk with a lot of good questions from the audience. We’ve discussed when to use TDD and its limits and I got to show a full demo of developing a real application using TDD from scratch.

Afterwards I’ve attended a panel with Gil Zilberfeld and Lior Israel where we talked about TDD, BDD, how the architect can use those methodologies as part of his architecture handout to the development team and answered questions from the audience.

The session was recorded and published on YouTube (in Hebrew)

I’d like to thank IASA for this opportunity - I enjoyed giving this talk and I hope I get more opportunities to discuss it in the future.

Monday, June 30, 2014

TDD != Unit Tests (and vise versa)

It’s been a busy week that started somewhere three months ago and I’ve missed most of the whole “TDD is dead” argument.

I finally had some time to sit and watch the discussions on the topic between Kent Beck, Martin fowler and David Heinemeier Hansson.

If you’re interested in unit testing and TDD (and you should be) - this is a great opportunity to listen to great minds and learn what they think of the subject – I know I learnt a lot and plan to continue watching till the end (there’s .

Although I only got as far as the 2nd part–  I can see a pattern emerging – it seems that every argument for or against TDD is actually about unit testing.

It seems that the discussion is not about “why TDD is good/bad” but a discussion about whether or not use unit tests (use!), the unnecessary layers of abstraction they might introduce (the dreaded design for testability) and how people completely miss the point by tying themselves to implementation by over mocking their application.


A quick search in the internet showed me why at least one of the participants think so:


DHH has a good point – obviously how you write unit tests effects directly the way you practice TDD.

But there’s more to TDD than just writing unit tests just like there’s more to software development than writing code. I always argue that the unit tests are a byproduct of TDD and not the other way around – we use unit test to drive our code design, and at the end of the process we’re left with a pretty decent test coverage that can prevent regression but we’re also left with a very specific design – which is the objective of the whole process.

Knowing how to write good unit tests is crucial in order for TDD to succeed – but you also need to have good coding practices, know how to refactor your code and a thing or two on software design in order to be successful.

Because TDD is not about writing unit tests – it’s about design. The tests are there to help with that and theoretically can be deleted as soon as you’re done writing your code – although I’m yet to find someone who would give up the benefit of having the unit tests.

I hope that the next 3 parts of the hangout would concentrate on TDD as a design methodology and leave the unit testing discussion behind.

Thursday, June 26, 2014

My DevGeekWeek sessions

I’ve had fun today at DevGeekWeek where I got to talk about writing clean code and unit testing best practices.

I’d like to thank the participants of today’s seminar – you were a great audience and I enjoyed speaking with you and learning about your experience with Agile, unit testing and writing code.

Just in case you weren’t there today – here are the slides:

Monday, June 09, 2014

DevGeekWeek 2014

Those you know me (or read my blog) know that I’m passionate (with a capital P) about software development, clean code and of course unit testing.

And I’m happy to be given the opportunity to talk about these topics as part of The DevGeekWeek 2014 conference.DGW_addmails_down

The DevGeekWeek is a week of all things software development and is scheduled for the 22-26 of June and will be held in the Daniel Hotel in Hertzelia (Israel).

CodeValue is responsible for the Extreme .NET with C# track with great speakers including yours truly.


I’ll be delivering two sessions on the last day at the Code Quality, Testing & Automation with Visual Studio & TFS seminar:

We’ll start with a session by Alon Fliess about Architecting Code For Quality, then my colleague Haim Kabesa with Building Coded UI Tests with Visual Studio and Test Manager and after launch I get to present two of my favorite topics:

  • Writing Clean Code in C# and .NET
  • Building Unit Tests correctly with Visual Studio 2013

I’ll talk about code and readability, avoiding stupid bugs and unit testing for the .NET developer – using Visual Studio to make it all happen.


See you there!

Related Posts Plugin for WordPress, Blogger...