The latest news from .Net world (September 2009)

On the very last meeting of Poznan .Net User Group I had a great pleasure to give 15 minutes talk about the latest news from .Net world. Picking the most interesting news isn't a trivial task. In the end I've decided to mention about following three topics:

Visual Studio 2010 and .Net 4

This was quite straightforward choice, new versions of VS and .Net Framework affects everyone so it's good to know what new features will are about to arrive. Probably the best source of information from this field is ScootGu's blog. Recently he posted series of post about VS 2010 and .Net 4.

Just to quickly name a few the most notable:

• .Net Framework 4 and VS 2010 can be installed side by side with older versions.
• a bunch of language improvements (C#) like: dynamic keyword, named and optional parameters, covariance, better COM support. Named and optional parameters is a long awaited feature, unfortunately it has some limitations - basically you can't assign to a parameter default value which is not compile-time constant.
• web.config files will be greatly simplified
• VS 2010 will have much more project templates available. It will be possible to start with completely clean project but also with simple application having the most basic features included (master page, forms authentication pages, JQuery etc.). Interesting is that new sample project are already using
  • clean client side Id (no more Ids like: ctl00_topLevelNavigation_rptMenu_ctl02_rptNextLevelMenu_ctl02_liTag!)
  • build-in controls are using CSS based rendering
• Improved Multi-targeting support - Problem with VS 2008 is that Intellisense always shows the types and members from .Net 3.5 (regardless of targeted version of .Net). This issue has been sorted with VS 2010.
• ASP.Net, HTML and JS Snippet support - finally! :) For people working a lot with the view this is great news. I was writing tags and controls like Repeater from scratch so many times that I'm sick of it. With VS 2010 it can be automated.
• Auto-Start ASP.Net Applications - Currently web applications are initialized with first request. This is a bit unfortunate because during the initialization sometimes it's required to perform number of heavy operations. That's why the first response is so delayed. There are of course number of ways to workaround this problem but with .Net 4 we will get dedicated means to auto-start our applications and perform initialization before the first request.

Git

Git is a distributed version control system which is getting more and more popular in .Net world. In outside world it is used by a big, very well-known projects like:

• Linux Kernel,
• Perl,
• Ruby on Rails,
• Gnome,
• Andriod,
• Fedora,
• Debian,
• X.org

I think the above list provides evidence that this system works well (especially for OSS projects).

Also in .Net world there are projects which decided to dump popular version control systems like SVN and are moving to Git:

• Fluent NHibernate,
• Rhino Mocks,
• S#arp Architecture

Justification for those decision is worth reading:

• Why Git?
  
• S#arp Architecture has Moved to GitHub

CodePlex foundation (CodePlex.org)

And finally last topic which I want to mention about is CodePlex foundation. It has been created by Microsoft "to help commercial software developers use Open Source software" and which "ultimately aiming to bring open source and commercial software developers together in a place where they can collaborate".

It's well known that big commercial software development companies are not really keen to use OSS. I think that this approach is changing with time and CodePlex foundation's main goal to help with that. In general all of that sounds really good but for number of different reasons this initiative mostly wasn't well received by the community. Still I think it's worth keeping an eye on it :)

Here you can find a few related links:

• Microsoft creates the CodePlex Foundation
• CodePlex Foundation
• Some quick thoughts about the new Codeplex OSS initiative
• Open Source development model
• Analysis: CodePlex Foundation - The Terms of Mutual Surrender
• Why It's Called the CodePlex Foundation
  

Coding buddy - Interesting approach to Code Review

How often do you ask your peers to review your code? If not very often then here is an idea for you - find a coding buddy! The buddy system can be implemented in 2 simple steps. But firstly, here is the idea behind the buddy system:

Individuals can do great things, but two highly motivated peers can accomplish even more when they work together. Surely there's at least one programmer you work with who you admire or at least respect enough to adopt the buddy system with.

So step 1 is to find a person meeting the above criteria, he will be a second "half of an awesome part-time coding dynamic duo". It has been proven, that this approach really works - there are lots of well-known dynamic duos like:

• Batman and Robin
• Tango and Cash
• Mario and Luigi
• Starsky and Hutch
• Crockett and Tubbs
• Bert and Ernie
• Cheap and Dale
• Laurel and Hardy

Your duo can join this small hall of fame! ;)

Now it's time to move to step 2 - peer review. Let me start with clarifying what kind of peer review I'm thinking about. Peer review can have multiple variations. For sure, with you coding buddy you don't want to do very formal, systematic and rigorous reviews (inspection) you should be much more flexible and more into quick and informal meetings (peer deskcheck).


I think informal nature of peer deskcheck is the factor that makes is so effective. You can comfortably chat with your buddy and explain to him what is the business objective for given piece of code and what was your approach to the problem. It's a great way to make sure that your idea makes sense and you are on the right course.

Those are only direct benefits, indirect benefits include:

• improved team work - reviews help people to "accustom" to helping each other
• increased familiarity of code base - sharing knowledge is always important, reviews give developers a chance to teach others about their piece of code
• prevent individuals from going dark
• increased quality - "reviews motivate us to practice superior craftsmanship because we know our co-workers will closely examine our work. In this indirect way, peer reviews lead to higher quality."
  

And that would be it, try to implement those two relatively simple steps and check on your own if it improves your code, check if other people understand your design and learn from it.

What are the next steps? (assuming that it buddy system works)

• find more coding buddies as it means more ideas, more views which afterwards should lead to even better code and even better knowledge sharing
• learn about different types of peer reviews, other types can be also useful. (chapter 3 of Peer Reviews in Software: A Practical Guide)
  
• try to change your company's software engineering culture to include peer reviews as a part of the process which you follow, every one can benefit from it (chapter 2 of Peer Reviews in Software: A Practical Guide)

Finally, I couldn't stop myself from posting this cartoon:


Last words ...

• This post was inspired by Jeff Atwood's post "Who's your coding buddy". I know Jeff that you don't read such a obscure blogs like this one but thank you for your post!
• Quotations and images used in this post are from Jeff Atwood's post and from Karl Wiegers' Peer Reviews in Software: A Practical Guide
  

One Blog - One Major Topic

What makes any blog popular and successful?

High quality posts, interesting comments, frequent updates ... those are obvious qualities which finally, with time, will pay off. But is it that enough to attract people to subscribe your blog? One good post is usually not enough to convince people to your blog - you need more then that and for some blogs that is a problem. People keep posting about way too many different topics on one blog. What I found surprising is that, as you can find in State of the Blogosphere, the average number of topics blogged about is five.

Is five topics per blog to much?

If topics are related to each other then it is fine ... if your blog is about more general things like building web applications then it makes sense to write about JQuery, Domain Driven Design and NHibernate. Those are different topics but all related to building web applications. Personally, I like blogs talking about wide spectrum of things, it is easier to see the big picture. Problem with very specialized blogs is that you have a feeling that you read a product(s) specification ... it can be useful on many occasions, it can help you to solve some problems but it's no longer fun and it's not though-provoking.

On the other hand, if you find a blog which is a total mix of random, completely unrelated stuff like ASP.NET MVC and pictures from someone's trip to Africa then you start to think if filtering out those less interesting post is worth your time. Two or three unrelated topics might be enough to forget about the blog.

So my advice is to clearly define what is your blog about and stick to it! It's a simple rule - if you write about building web application then avoid posting videos from your holidays. Don't confuse your subscribers unless you write your blog only for your personal satisfaction and other things don't matter.

The best IT blog of 2008

End of each year is a great moment for all sort of reviews, people tend to publish various different rankings like "The Best of ..." in all possible categories. This year I will add my 2 cents in a category which I find the most interesting: "The best IT blog of 2008".

I follow a few blogs as well as sites aggregating articles in some particular area (Agile Development, .Net, EPiServer). During this year I found lots of interesting and usefull posts there so choosing the best blog was difficult. My intention was to avoid nominating blog talking about one particular area or product. Main reason behind that decision was that people move from one project to another, from one job to another, I wanted to find a blog which can be relevant for us all the time.

Okey, let's move to the point ... in my opinion the best IT blog of 2008 is Jeff Atwood's Coding Horror!

There are a few reasons:

1. New posts every 2-3 days
2. Vast number of comments, Jeff's posts are just a start for a discussion.
   
3. And at last but not least .. lots of great, thought-provoking posts ... my personal top 5:
• Programmers Don't Read Books -- But You Should
• Don't Go Dark
• Coding Without Comments
• Dealing With Bad Apples
• Alpha, Beta, and Sometimes Gamma

Which blog is your "The best of 2008" ?

Don't go dark!

Recently I found very interesting post of Jeff Atwood regarding developers and bad practice of going dark. It was so thought-provoking that I decided to write a few my opinions how it looks like within Cognifide. By going dark we should understand situation where developer is "locked in his room" for a long period of time implementing some piece of functionality until job is done. Definition of 'long period of time' will vary across different organisations. In our case, in ASP.NET team we try to manage granularity of tasks in way that new modules can be implemented in days. If implementation of some module is going to take 1 week then it's considered as a big task. So going dark for us would mean that some developer is "locked" for longer then 1 week working on some gigantic feature. What's wrong with that?

Actually dropping such code-bomb can potentially create many problems:

• if there was any bad design decision made then whole new feature can be rejected as it may not fit to main project design. Please note that while developer is in the dark working on his feature, main project keeps changing,
• it's hard for other team members to understand and maintain new code
• it's almost impossible to do code review

Fortunately for us, we use SCRUM to manage ongoing work. Daily meetings significantly reduce risk of going dark, so good for us! But is that enough to be happy about the process? Jeff pointed out two things:

"The brilliant developer must be capable of performing on a team,
making his work visible in modest increments and subjecting it to
scrutiny as it matures."

and

"Hiding your code until it's "done" may feel safer, but it isn't.
Sharing your ongoing code with your coworkers is scary, much less the
world -- but it also results in feedback and communication that will
improve your code and draw you closer to the project you're working on."

I would like to highlight this part: "feedback and communication will improve your code and draw you closer to the project".

Why is that important for me? From my perspective it doesn't matter so much if you are working on one huge project for a long time or on a few smaller, at some point you have your habits, your ways of dealing with tasks. After some time you have already solved most of the problems which means that implementing yet another class/module/feature will not give me much in terms of new skills, my code won't get better, in fact I'm quite sure that it will stay exactly the same.

Few ideas how to change it, how to encourage people to talk about code quality and good patterns and this way learn new things:

1. pair programing when implementing bigger features. Main point is to avoid situation when there is only one person working on the feature and in the end this is the only person which is capable of maintaining it. I'm not saying that people should all the time sit together and do proper XP, work in parallel as much as you can. Important is that working with someone enforces communication and design discussions which in the end prevent from going dark.
   
   
2. code reviews, that seems to be the most obvious way of improving my code, I need feedback from other people! Of course it would be great to see senior developers taking active part in code reviews, that would be the best way to share knowledge. But also it's worth to know what less experience people think, fresh approach is also important! :) As I see it, code reviews makes the most sense in the early stages of each project. But also it would be nice to have a 'code review' session once a month to point out some fresh ideas (people don't necessary need to show bad habits ... good practices should be also presented!). Important is to take notes, find consensus and write it down!
   
   
3. internal demo after each iteration, it's vital to keep everyone up-to-date, it's also important to reuse similar approach designing all modules. That is another chance to communicate with peers, to get others people opinion. And additionally, it makes much more sense for end user when delivered project works and acts as a coherently designed system.

In the end, one last point ... I believe that none of us would like to end up doing one-man projects all the time. It usually means very small progress or no progress at all. We have lots of smart and clever guys around, we have opportunities which people in one-man project don't have so let's make a use of it. Don't be anti-social, communicate and improve your code!