Peter Ritchie's MVP Blog

Book Review: WCF 4.0 multi-tier services development with LINQ-to-Entities

WCF 4.0 Multi-Tier services development with LINQ-to-Entities is about about using LINQ with Entity Framework to create a data layer in a WCF web service.  The book approaches the content from the point of view of a junior developer--one that is not necessarily familiar with Visual Studio.  The book generally approaches the topic from a useful lowest-level to highest-level evolution--starting with how to create a WCF service from scratch and working up to creating a WCF service with the built-in Visual Studio templates.  The book follows the important contract-first design model for web services.

I like the book's approach to layering, it's a refreshing change to see purposeful decoupling of layers and not something that simply pushes entity classes from the data layer all the way to the interface layer--each layer has it's own concept of the domain entity in use.  This is very important with web services because what can be implemented in a web service is a subset of what can be implemented in .NET; and to a certain extent, what can be modeled in the database and the data access layer is also a subset of what can be implemented in .NET.  So, it's important that the business logic layer be free to implement the domain entities how it needs to without being limited to what cannot be implemented in a web service message or in what cannot be implemented in a particular database.  That is, in the examples, the entities created by the Entity Framework are restricted to the Data Access Layer and they are not used in the web service's requests and responses.

The book generally shows a consistent example that evolves from single layer to multi-layer, starting with the service layer.  This form of description is useful for people who are not familiar with layering.  This also has a similar flow to Test-Driven Design (TDD).

This book covers, in detail, use of much of the new C# 4 syntax, including LINQ (really LINQ syntax, plus anything that LINQ depends on in the new C# syntax; which is most of it).  Two chapters are devoted to this new C# syntax.  This book also covers in detail how to create WCF services with and without the built-in Visual Studio templates.  For advanced developers, much of this book might be a bit beneath them--if you're already familiar with Visual Studio, layering, C# 4, and debugging in Visual Studio, you may find half the book details information you already know.  If you are already familiar with WCF and Entity Framework, you probably won't get much out of this book--as expected.

There are a few points that I find are slightly off in terms of correctness; but none that apply to LINQ to Entities or WCF.  Unfortunately, "multi-tier" really isn't detailed.  The examples are strictly multi-layer, not multi-tier (assuming the client to the web service must always be considered its own tier--i.e. I infer more than two tiers from "multi-tier services").  The implementation of the web service (the interface layer, the business logic layer, and the data access layer) is a single tier in every example.  The concepts of the book could easily be expanded to the business logic layer and the data access layer to wrap them in a WCF web service to truly implement a multi-tier service.  There are several examples of performing automated tests (coded tests) within the book.  I was a little disappointed that these weren't approached as unit tests and either implemented with Visual Studio testing framework or another common unit testing framework like NUnit.

The book uses a few well-known patterns in its implementations; but, doesn't go into too much detail other than their implementation.  For example, it uses the Data Access Object (DAO) pattern but doesn't use the term "Data Access Object".  This isn't unexpected, since the book isn't about patterns.  If you're the target audience of this book, I would suggest following up with some reading on patterns.  The book generally implements the patterns it uses correctly, but I find the choice of some of the patterns to be somewhat academic.  For example, the author chooses the typical Microsoft 3-layer architecture: interface layer (service layer), business logic layer, and data access layer.  The typical problems of mixing business logic within the business logic entities and outside these entities occurs.  I'll leave it as an exercise for the reader to research how to approach this problem.  (hint, check out my blog archive and keep reading my blog).
The book also doesn't really go into much detail about WCF configuration even with regard to web services.  There's no detail of switching bindings like from HTTP to HTTPS, to TCP, etc.  And there's no mention of SvcConfigEditor--an essential tool in the arsenal of every WCF developer.

If it wasn't obvious, I'd recommend this book to junior developers who need to get up to speed and be productive in WCF and Entity Framework in a short amount of time.

A sample chapter can be found at https://www.packtpub.com/sites/default/files/sample_chapters/wcf-multi-tier-services-development-with-linq-sample-chapter-5-implementing-a-wcf-service-in-the-real-world.pdf and the publisher's landing page for the book can be found here: https://www.packtpub.com/wcf-multi-tier-services-development-with-linq/book

Visual Studio 2010, Enhance your Jedi Skillz

I’ve blogged about becoming a Jedi in Visual Studio 2008 before.  Being a Jedi in Visual Studio means you focus more on adding value to the software you’re working with and less on the process of the IDE you’re doing your work in.

Visual Studio 2010 has some great features to allow you to do just that.  So much so, in fact, that I can’t possibly do them justice in a single post.  I’ll start with a few here and continue with a few posts on ways to get Visual Studio 2010 to let you write software faster.

All of what I’ve posted about VS 2010 still applies, like Auto Hide Solution Explorer, Toolbox, etc, single custom toolbar, etc.

Use multiple monitors.  VS 2010 has inherent support for multiple monitors.  You could previously get VS to display on multiple monitors; but now the tool windows in VS 2010 can be moved outside the main VS window, and dragged onto another monitor.  This is particularly handy (in my opinion) with debugging.  You can have your watch window on one monitor, the main editor on another monitor ( and if you’re lucky enough to have a 3rd monitor) the application you’re debugging on another monitor.

Use Navigate To.  I’ve been a user of Resharper for many years.  One of it’s features is the ability to Go To Declaration—which allows you to navigate to the declaration of a type (if it’s in your solution, metadata if it isn’t).  Now Visual Studio 2010 has a very similar feature: Navigate To.  This feature can be invoked with Ctrl+, and will pre-populate the form with the type at the caret.  The form lists all the project files and types within the solution that match the text, including config files, CS files, classes, interfaces, etc.  Previously you had to to perform a Find In Files and wade through the false-positives to go right to the declaration of a type.  For example, if I press Ctrl+, and type “Main”, I’ll see the following Navigate To form:

I can then simply press return to go to the declaration of the Main method.

If you are a TDD practitioner, switch to Suggestion Mode.  Pressing Ctrl+Alt+Space toggles between Suggestion mode and Completion mode.  Completion mode is the IntelliSense mode that was in version 2008 and prior.  2010 has a new Suggestion mode that doesn’t auto-complete types when you press space, period, semicolon, etc.  They same types show up in the IntelliSense drop-down; but you can still auto-complete the type it suggested by pressing the down arrow then space, period, semicolon, etc.  For example, if I’m typing test code to test a type named Text, in Completion mode it may auto-complete with “TextBox” when I press space.  In Suggestion mode it will simply accept what I typed when I press space and not auto complete.  What’s nice in 2010 is that IntelliSense now knows about “Text” as a type even though I haven’t declared it, so when I continue and type “text = new T”, “Text” now shows up in the IntelliSense drop-down.  I can have it complete it with “Text” by pressing down-arrow and continue typing.

Use Call Hierarchy to see what code is calling a particular method.  Call Hierarchy is new feature in Visual Studio 2010 that shows you in a tree structure what methods call a particular method as well as what methods a method calls.  For example, if I right-click a call to the UnityContainer constructor and select View Call Hierarchy, the Call Hierarchy form is displayed which shows what calls UnityContainer and what UnityContainer calls.  For each item in a node, you can expand to see what that method calls and what method calls it.  For example, InitializeContainer calls the UnityContainer constructor, if I expand the InitializeContainer entry in the tree I can see what it calls and where it is called from.  If I expand it’s Calls From ‘InitializeContainer’ I can see what other methods InitializeContainer calls.  For example:

Since I last blogged on improving your Visual Studio skills, Scott Cate and Steve Andrews have taken up the Visual Studio Tips and Tricks torch from Sara Ford and are hosting vstricks.com and vstips.com, respectively.

Best Practices

We had a fishbowl session at Prairie DevCon recently, titled “When and When Not to use Best Practices”.  The idea for the session came from a Twitter conversation between myself, D’Arcy Lussier and Shane Shouldice.  That Twitter exchange basically alluded to the sentiment that there is no such thing as a best practice.

Best Practices is not a term used solely in Software Development, and not a term coined by the Software Development community.  Wikipedia defines Best Practice as “…a technique, method, process, activity, incentive, or reward that is believed to be more effective at delivering a particular outcome than any other technique, method, process, etc. when applied to a particular condition or circumstance.” and goes on to detail that “[a] given best practice is only applicable to particular condition or circumstance…”

There were some great participants in the session, and the overall sentiment echoed that of the twitter exchange: people’s frustration with how “best practices” have been adopted by other members of the software development community.  The major issue is that developers blanketly implement best practices without putting any thought into the appropriateness of the practice in their context.  This, I think, stems partially from the source of the best practice and the adeptness of the consumer of the best practice.

While I don’t think we can really expect to get away from “Best Practices” as a term in our industry, I think we can go a long way to improve people’s understanding of what a “best practice” is.  Some important things when documenting Best Practices: there is a context in which they are appropriate, they are not fixed procedures.  And for consuming Best Practices: be sure you understand the context in which the practice is intended to be used.  Also, don’t be afraid to put some thought into your use of the practice; if it doesn’t quite fit in your circumstance change it or move on to another practice.

Using the dynamic Keyword in C# to Improve Object Orientation – A Follow-up

Based on some feedback, some clarification is warranted with regard to my previous post titled “Using the dynamic Keyword in C# to Improve Object Orientation”.

As Jarek Kowalski correctly pointed out, the example code that I provided could have used the Visitor pattern instead to get the same result.  My impetus for using the dynamic keyword the way I did was slightly different from how I described my example—which was meant to be easier to read.

I think it’s worthwhile describing the Visitor Pattern.  The Visitor pattern is a pattern used to separate the responsibility of an algorithm from the class that the algorithm should operate upon.  Essentially, a Visitor class is created to contain the algorithm that would be invoked through its Visit method and the classes that the algorithm operates upon some sort of method that accepts a reference to a Visitor object (which would simply invoke the Visit method).  The example that Jarek provided was very similar to:

 	public interface IShapeVisitor 

 	{

 		void Visit(Circle square);

 		void Visit(Rectangle square);

 	}

 	public class Circle : Shape 

 	{

 		public override void Accept(IShapeVisitor shapeVisitor)

 		{

 			shapeVisitor.Visit(this);

 		}

 		//... 

 	}

And an implementation of IShapeVisitor would be provided like this:

 	public  class  DrawingVisitor  : IShapeVisitor

 	{

 		public  void  Visit(Circle circle)

 		{

 			// draw circle here 

 		}

 		public  void  Visit(Rectangle rectangle)

 		{

 			// draw rectangle here 

 		}

 	}

In our case, the bodies of Visit methods would call a Draw method contained in another class like a View implementation.  For example:

 	public  class  DrawingVisitor  : IShapeVisitor 

 	{

 		private  IView  view;

 		public  DrawingVisitor(IView  view)

 		{

 			this.view = view;

 		}

 		public  void  Visit(Circle  circle)

 		{

 			view.Draw(circle);

 		}

 		public  void  Visit(Rectangle  rectangle)

 		{

 			view.Draw(rectangle);

 		}

 	}

Using the dynamic Keyword in C# to Improve Object-Orientation

With polymorphism, object-oriented languages allow "...different data types to be handled using a uniform interface".  Ad-hoc polymorphism is when you declare multiple methods of the same name but differ by the type of an argument.  For example:

 private  static  void  Draw(Circle  circle)

 {

 	//... 

 }

 private  static  void  Draw(Square  square)

 {

 	//... 

 }

These are usually referred to as method overloads or method overloading.  Which Draw method that gets invoked would be decided upon at compile-time based on the type of the parameter passed to it.

This is great, there are many situations where this is useful; but what about situations where you don't know the exact type of the object until run-time?  Many programmers instinctly lean towards using the GetType method available on all objects in .NET and perform a manual type comparison.  For example:

 public  void  ProcessShape(Shape  shape)

 {

 	Type  type = shape.GetType();

 	if  (type == typeof (Square ))

 	{

 		Draw((Square )shape);

 	}

 	else  if  (type == typeof (Circle ))

 	{

 		Draw((Circle )shape);

 	}

 	//... 

 }

There are other variants of this that make it a little harder to detect (and often gets around static code analysis warnings):

 public  void  ProcessShape(Shape  shape)

 {

 	Square  square = shape as  Square ;

 	if  (square != null )

 	{

 		Draw(square);

 		return ;

 	}

 	Circle  circle = shape as  Circle ;

 	if  (circle != null )

 	{

 		Draw(circle);

 		return ;

 	}

 	//... 

 }

This code is a problem because we lose the benefits of C#s polymorphism (this code is coupled to Circle and Shape, if either is removed, this code would have to be changed and re-tested.   If another Shape derivative were added, the code would again have to be changed and re-tested).  There are multiple circumstances where this might happen over and above the so-far specious examples above.  For example, deserializing an object from a Stream often results in not knowing the exact type of the object that has been deserialized.  This is common with type hierarchies.  For example:

 private  static  Shape  DeserializeShape(Stream  stream)

 {

 	IFormatter  formatter = new  BinaryFormatter ();

 	return  formatter.Deserialize(stream) as  Shape ;

 }

With the above code, we've re-hydrated either a Circle of a Square object into a Shape object (and ignored the appropriate checks to make sure a Shape object was loaded).  We're now unable to use all the other polymorphism features of C#: method overloading won't work, C# will always only use the overload with the Shape argument and generics suffers from the same problem, it will always resolve to the type parameter of type Shape.  For example, if we try to call one of our two Draw methods with our re-hydrated Shape object:

 			Draw(shape);

...we simply get a CS1502 warning because there is now Draw(Shape shape) method.

When programmers simply compare types, they're admitting that polymorphism has been circumvented and they have to resort to introducing the Conditional Complexity Code Smell or the Switch Statement Code Smell (C# doesn't support Type in a switch statement, so some programmers go ahead and create a integer type code--or even worse, use String in the switch statement)

So, what's a programmer to do to keep our code object-oriented and use polymorphism?

Well, if you read the title of this post, you've probably figured it out: use the dynamic keyword.  The dynamic keyword bypasses static (compile-time) type checking and performs the type-checking dynamically (at run-time).  So, for us to use our Draw overloads with our Shape object, we simply assign it to a dynamic object and use that object instead.  For example:

 			Shape  shape = DeserializeShape(stream);

 			dynamic  dynShape = shape;

 			Draw(dynShape);

Now the runtime will check to see the actual type of dynShape object and invoke the corresponding Draw overload.

In our example, we've used inheritance to derive our two shapes from a single base.  But, given our current use of Circle and Square objects, we don't need them to inherit from the same base class.  We could simply view these shapes as an Object when we want to use dynamic.  For example:

 private  static  Object  DeserializeShape(Stream  stream)

 {

 	IFormatter  formatter = new  BinaryFormatter ();

 	return  formatter.Deserialize(stream);

 }

 			//... 

 			dynamic  shape = DeserializeShape(stream);

 			Draw(shape);

With the above, we’d have the same result without deriving both Circle and Square from Shape.

Refactoring with Visual Studio 2010

While putting some finishing touches on the book, the publisher has put details about the book on their website.

https://www.packtpub.com/refactoring-with-microsoft-visual-studio-2010/book

From the overview:

Changes to design are an everyday task for many people involved in a software project. Refactoring recognizes this reality and systematizes the distinct process of modifying design and structure without affecting the external behavior of the system. As you consider the benefits of refactoring, you will need this complete guide to steer you through the process of refactoring your code for optimum results.

This book will show you how to make your code base more maintainable by detailing various refactorings. Visual Studio includes some basic refactorings that can be used independently or in conjunction to make complex refactorings easier and more approachable. This book will discuss large-scale code management, which typically calls for refactoring. To do this, we will use enterprise editions of Visual Studio, which incorporate features like Application Performance Explorer and Visual Studio Analyzer. These features make it simple to handle code and prove helpful for refactoring quickly.

This book introduces you to improving a software system's design through refactoring. It begins with simple refactoring and works its way through complex refactoring. You will learn how to change the design of your software system and how to prioritize refactorings—including how to use various Visual Studio features to focus and prioritize design changes. The book also covers how to ensure quality in the light of seemingly drastic changes to a software system. You will also be able to apply standard established principles and patterns as part of the refactoring effort with the help of this book. You will be able to support your evolving code base by refactoring architectural behavior. As an end result, you will have an adaptable system with improved code readability, maintainability, and navigability.

Scheduled to be available in September.

Layers in Visual Studio 2010

Visual Studio 2010 has a new featured called Layer Diagrams.  In the Ultimate edition you can create layer diagrams that model the logical layers in your software system.

What is a Layer?

I’m glad you asked what a layer is.  A layer is a logical grouping of types with similar external assembly dependencies.  Dependencies between layers occur only in one direction from a higher-level layer to a lower-level layer.  I.e. a higher-level layer can use types in a lower-level layer, but not vice versa. A canonical example is the Data Access Layer (or DAL).  The DAL contains all the types that directly use types responsible for data-access.

Using the Layer Diagram

Within the Layer Diagram user interface, it can be unclear what a layer is.  The Layer Diagram is really just a dependency diagram that allows creation of a logical layer that can be linked to physical artefacts.

Creating a layer diagram in Visual Studio Ultimate is easy, select New Diagram from the Architecture menu and the Add New Diagram dialog will be displayed.

In the Add New Diagram dialog, select the Layer Diagram entry and enter the name of the layer diagram file.

If your solution does not currently contain a Modeling project, one will be created automatically when you press OK as indicated by “Create a new modelling project…” in the Add to modeling project combo box.

Once the modeling project is created and the new layer diagram is added to that project, you will be presented with the Layer Diagram design surface.  You have many options to creating a layer in the diagram, you can use entries in the toolbox to create layers, dependencies, and comments:

Or, you can drag artefacts from the Solution Explorer or the Architecture Explorer to create layers in various ways.  Normal dragging of a single artefact onto the design service creates a new layer with a one-to-one mapping (a “link” in Layer Diagrams) from layer to artefact.  This is especially useful for projects from the solution explorer.  It’s not uncommon for logical layers to be implemented as tiers (or physical assemblies).  Or, you can create a one-to-many mapping from layer to artefacts by normal dragging of artefacts onto the design surface.  This is useful when you’re modeling layers but haven’t modeled them as tiers and multiple layers exist in a single assembly or project.  Via the Architecture Explorer and the Solution Explorer you can link assemblies (projects), types, namespaces, methods, properties, fields, and files to a layer.

Regardless of how the layer was created on the diagram, you can add links to it by dragging them from the Solution Explorer or Architecture Explorer onto a layer to create a link to it.  Oddly, although you can link to classes and namespaces, you can’t drag classes or namespaces from the Class View onto the Layer Diagram design surface.

The following diagram was created by dragging three projects from the Solution Explorer to the design surface and invoking Generate Dependencies on all three of the created layers:

Once a layer model has been defined, you can then ask Visual Studio to validate the solution against that logical architecture. Within the layer diagram you can have a one-to-one mapping of layer to links, or a one-to-many mapping.  i.e. a layer can consist of one or more links (at least in terms of validation—you can have zero links in a layer if you want; but then VS has no information with which to validate anything). If, for whatever reason, the current solution doesn’t follow the logical architecture, an error will result.   You can also configure the solution to automatically validate the solution against the layer diagram during a build.  This build-time validate can occur in both the Ultimate and Premiums editions of Visual Studio 2010.

Why is it really just a Dependency Diagram?

Another really good question!  The Layer Diagram is really just a dependency diagram because there’s no inherent recognition for layer levels.  Because there’s no way of defining a level, there’s no way to group layers within a specific level.  Layer diagrams also allow bi-directional dependencies; a definite no-no with two layers at different levels.  It’s also really difficult to really enforce only a particular layer having references to particular external references.  You can declare forbidden namespaces for a particular layer, but it’s a cumbersome method of enforcing references to particular components only occur in a certain layer.  For example, if I had a DAL and I wanted to make sure only data-access occurred in that layer, I could add “System.Data” to the Forbidden Namespace Dependencies for all layers expect the DAL and incur an error with Layer Validation should any types from System.Data be used in any of those Layers.  But, things like DataGridView in Windows Forms are used primarily with types in System.Data so it becomes difficult to manage these dependencies.

Principles of Software Development Productivity

There's been a few developer "Bill of Rights" lists that have floated around.  These lists generally include creature comforts like dual monitors or a fast PCs.  There's certainly a business case for fast PCs, and I've made more than my share of these business cases.  But, these things are mostly just goodies under the guise of productivity gains.
I'm all for productivity gains—I personally hate wasting time on something that I don't need to do and doesn’t add value.  But, software designers can't simply use productivity as an excuse to get toys.  If the productivity gains are impetus enough to get these things then we should always be focusing on how we can be productive in every aspect of our job.  To that end, I've started keeping track of things that should be vital to every software designer's ability to do their job effectively and efficiently, in no particular order:

Unfettered Access to the Internet

There's way too much technology information for one person to keep in their head.  I pride myself in being able to find almost anything on the Internet.  If I don't know how to do something, I know I can find it on the Internet, absorb it and implement it.  If I don't have access to the Internet, my productivity goes down.
This includes wholesale blocking of blog sites.  Sure, many blog sites are full of chaff; but they all have useful development information on them somewhere; If I can't get on them then I can't get that information and I’m wasting the client’s money.

Infrequent Non-development Meetings

I read somewhere that people who produce things (as opposed to people who manage other people) work in 4 hour chunks (people who manage people work in 1 hour chunks).  If a 4 hour chunk of time is interrupted by a meeting, the productivity of that whole chunk of time is severely diminished, if not entirely lost.  Having to attend a 1 hour meeting in the morning and a 1 hour meeting in the afternoon basically blows my productivity for the day out of the water.  It sounds like it's just a benign 2 hours of my day; but the cost is really 7.5-8 hours.  Not to mention, that's 2 hours I could be been doing something useful.

Meetings Must Have, and Abide By, an Agenda

It’s seems obvious: how is anyone going to be productive in a meeting if they don’t know the details and how to be prepared for the meeting?  Without an agenda, attendees can’t know what is out of scope.  More importantly, how do the attendees decide when the meeting is done?  They don’t.  Meetings without agendas go on and on and on.  Without an agenda, the attendees don’t know if they’ve discussed what needs to be discussed and they most certainly don’t know if the meeting was successful or not.

Meetings need to add value, they need to accomplish things.  The accomplishment of a meeting could be the fact that action items have been created to detail who, what, when, the priority, and possibly how, follow-up tasks need to be completed after the meeting.

Proactive Proliferation of Policy

Policies are great.  If I need to do something or not do something, I'm more than happy to oblige.  But, to inform me of those policies only after I've violated them does neither the organization nor me any good.  I need to know about these policies before I get intrenced in work for an organization, and be kept informed of any changes to those polices.  I can't take responsibility for abiding for them if I haven't been told about them or told how to read about them.
I once worked at a place that didn't give me a computer for the first week I was there.  "Fine", I thought, I'll just use my laptop and get some work done.  Well, there was a policy that no unauthorized computers could connect to the network.  The net effect was that I was chastised for trying to get work done (if you meet me in person, buy me a beer and I'll be happy to tell you the details of the defined consequences of violating that policy and my experience).

People will find ways to get their job done and do them.  If the ways they find to do their job violates some policy, they need to know so they don’t do it.

Clear and Available Policies

Policies need to be clear and continuously available.  If a policy is open for interpretation then it’s easy to violate that policy.  If it’s hard for people to know they’re violating policies, having the policy is pointless.  If policies are spread by word-of-mouth, the essence and success criteria of the policy will get lost.  Policies need to be documented and published somewhere where everyone can have immediate access to them.

Available and Responsive IT Support

We're designing and writing software for computers. These computers are connected to a network and to printers.  If the computer, the network, the mail server, the printer, the intranet, etc. doesn't work, I can't do my job.  I need to know who to talk to when I have a problem, and I need to to fix it as fast as possible.  Me sitting around on my butt does me no good, and does the client no good.

This goes for all levels of IT.  If the developers have to work with a SQL database but aren’t empowered to be the DBAs then the organization needs to provide them available and responsive DBAs to support them.  Having development work blocked waiting for a DBA to become available is not useful.

The corollary to this is that if an organization is going to schedule developers to work off-hours, they also need to schedule support for them in those time frames.  Most off-hour work is a fall-out of scheduling problems.  Having devs do work off-hours only for that work to be blocked because they can’t get support is a waste of everyone’s time and resources.

Clear, Complete, Unambiguous, Prioritized, and Verifiable Tasks.

Having to run around in circles frustrates me and produces nothing useful for the stakeholders and the client.  I need to know exactly what I’m needed to do.  If I don't know the whole story, I can't ensure I'm doing the right thing for what I do know about.  I'm doing work for someone, I need to know what their priority is.  If they don't tell me, I do it a random order or an order I feel is logical.  A client can't tell me I'm not working on something of highest priority if they haven't given me their priorities.  I also need to verify that I've done what was asked of me correctly.  If a client doesn't tell me their success criteria I can't be successful: I will fail.  That is, if I can’t verify I succeeded then the alternative is that I’ve failed.

Immediate Access to a Subject Matter Expert

Having clear, complete, unambiguous, prioritized and verifiable tasks are a must; but if a client tells me those are all the requirements I'm going to tell them they are wrong.  It's not possible for all requirements to be known up front.  Technology changes, perceptions change and get clarified, priorities change, etc.  Requirements change over time.  I need to have access to the people who live and breathe the requirements: the subject matter experts.  If requirements change, I need to talk to these people or I'm wasting client's money.

Clear and Approachable Requirements Engineering Process

Clear, complete, unambiguous, prioritized, and verifiable as possible.  Mistakes happen, clarity is attained over time, requirements need to change.  I need to know how to get those requirements changed and approved (telling me that there is no formal approval process is informing me of the requirements engineering process).  Changes in requirements are usually high priority.  If I have to waste my time trying to find out how to finalize or get approval for those changes, I'm wasting the organizations money.

Ownership of Schedule

This is a pet peeve of mine.  It's not useful for someone to be told that they have x number of days to complete a task.  They must be asked to estimate how long it will take for them to complete each task.  No two people will complete the same task in the same amount of time when it comes to software development and design.  There's two possible outcomes from telling someone how long they have to complete a task.  One is they complete it on time--which means they most likely could have done it in less time and that extra time was squandered.  Or two, they can't possibly complete it on time and everyone is setup for failure.

If schedules are being mandated on devs because they have a track record of poor estimates, then work with them to be better at estimating.  Estimating work correctly is a rare trait; most people need guidance and experience in doing is correctly.

And don’t pad estimates—that’s fraud in my books.  You need to account for all your time.

If you’re a developer, make sure your organization isn’t hindering your productivity by not realising these realities with you or your team.  If you’re managing or leading a team, be a good leader and empower you team members in these ways to make them more productive.

There's many more ways an organization can doom a software development process; but these are many basic errors that I've encountered.  Have some others?   Let me know in the comments.

Modify VS 2010 Template to Reference System.Configuration

Almost every project I create in Visual Studio, I invariably have to add System.Configuration to the references for that project.  As soon as I want to do much with app.config, I need to use something in System.Configuration.  Well, rather than continue to add that reference to future projects, I've decided to change the project template so I don't have to.  The following is a description of how to do that.

The project templates are located at C:\Program Files\Microsoft Visual Studio 10.0\Common7\ide\ProjectTemplates\ (replace "Program Files" with "Program Files (x86)" if you're using a 64-bit version of Windows).  For this example I'm going to change the C# Windows Forms Application template.  Each language has their own directory and each template is localized to multiple languages.  For me, my locale code is 1033, so the Windows Forms Application template is located in CSharp\Windows\1033\WindowsApplication.zip.  To modify anything in the template we need to extract the contents.  This is best done by copying the file to your Documents directory then extracting the contents (in Windows 7, you'll get lots of UAC prompts when you start editing files in Program Files, so this makes life a little easier).  Go ahead and make a backup of this file now.

For what we want to do, we want to edit the windowsapplication.csproj file, so open that in notepad.  We want to change references, so we need to edit the Reference elements, so search for "<Reference".  This will put you at a section of the file that looks like this:
    <ItemGroup>
        <Reference Include="System"/>
        $if$ ($targetframeworkversion$ >= 3.5)
        <Reference Include="System.Core"/>
        <Reference Include="System.Xml.Linq"/>
        <Reference Include="System.Data.DataSetExtensions"/>
        $endif$
        $if$ ($targetframeworkversion$ >= 4.0)
        <Reference Include="Microsoft.CSharp"/>
         $endif$
        <Reference Include="System.Data"/>
        <Reference Include="System.Deployment"/>
        <Reference Include="System.Drawing"/>
        <Reference Include="System.Windows.Forms"/>
        <Reference Include="System.Xml"/>
    </ItemGroup>

We want to add a reference to System.Configuration, so go ahead and add '<Reference Include="System.Data"/>' as the first item in the ItemGroup.  We also want to remove references to System.Xml and System.Xml.Linq.  Heck, while we're at it, let's also get rid of other references I don't use that much: System.Data.DataSetExtensions and Microsoft.CSharp.  This leaves us with something like:
    <ItemGroup>
        <Reference Include="System.Configuration"/>
        <Reference Include="System"/>
        $if$ ($targetframeworkversion$ >= 3.5)
        <Reference Include="System.Core"/>
        $endif$
        <Reference Include="System.Data"/>
        <Reference Include="System.Deployment"/>
        <Reference Include="System.Drawing"/>
        <Reference Include="System.Windows.Forms"/>
    </ItemGroup>

Now, save the file.

If you're removing other references (like System.Core) you'll have to also edit some of the .cs files in the template to make sure they're not referencing namespaces within the removed references (like System.Linq in form1.cs).  If you need to do that, go ahead and do that as well.

Now, we need to take all those files and re-zip them back into a file named WindowsApplication.zip.  Once we do that we can copy that back into c:\Program Files\Microsoft Visual Studio 10.0\Common7\ide\ProjectTemplates\CSharp\Windows\1033 directory.  Visual Studio also caches the files in the templates.  There's a way to get VS to reconstruct that cache, but, it's easier to simply copy the files from the WindowsApplication.zip file into the cache directory located at C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\ProjectTemplatesCache\CSharp\Windows\1033\WindowsApplication.zip.  This is actually a directory, not a ZIP file.  Go ahead and copy all the files (or at least the ones you've modified to this directory.

And we're done. Now, restart VS, and create a new Windows Forms Application project.  You’ll see that References in the Solution Explorer look something like this:

No more System.Xml.*, Microsoft.CSharp, System.Data.DataSetExtensions and System.Configuration is now there.

Enjoy!

Getting Started Unit Testing with nUnit

Getting started with unit testing with nUnit is easy.  First download and install the latest version of nUnit, which can be found here:  http://www.nunit.org/index.php?p=download

Next, you need to decide where you want your unit tests will live.  If you’re developing a shrink-wrapped system that will be deployed to multiple customers or clients, you’ll likely want to have an independent project to house your tests.  If you’re developing an enterprise system—and the software won’t be deployed outside your enterprise—then having the tests within an existing project (usually the highest-level project) is a valid option.

Note: The only configuration I've been able to get to work with Visual Studio 2010 compiled assemblies is to have my assemblies compile to x86 and use nunit-x86.exe to run the tests.

Wherever you decide to keep your unit tests, you need to add a reference to the nUnit assembly.  Add a reference to nunit.framework.dll.

Next, you can write some tests.  For example:

[TestFixture]
public class TestSomething
{
    [Test]
    public void FailingTest()
    {
        Assert.Fail("Fail description.");
    }
    [Test]
    public void PassingTest()
    {
        Assert.Pass();
    }
    [Test]
    public void InconclusiveTest()
    {
        Assert.Inconclusive("Reason for lack of conclusion.");
    }

}

Then, compile, and load your test assembly into nUnit.  Clicking the Run button should result in something like the following in nUnit.

You’re now ready for Red Green Refactor.

Yellow?

What about yellow?  Red means a test failure, Green means a test pass.  But, what about tests that don’t have underlying code to be tested.  Some may say that this is just another failing test.  But, early in your testing efforts you may end up being overwhelmed by red.  This could lead to missing a failed test actually is testing code.  The alternative is to use the Assert.Inconclusive().  This actually gives you a purple, not yellow, result in nUnit, but you get the idea.

Where to from Here?

Now we’ve got an external test runner and the unit tests for the runner to execute and inform you of red, green, and yellow; you may want to automate the testing process.  I would recommend looking at tools like TestDriven.NET, Resharper, and Continuous Integration tools like CruiseControl.NET

Of course, you’ve always got the option using the built-in automated testing tools in Visual Studio 2010 Professional, and the Continuous Integration abilities of Visual Studio Team System.

Flaws in the Microsoft Connect Process

The way Microsoft Connect works in terms of how a bug goes from being submitted to someone working on it (or closing it without working on it), is basically flawed.

From a customer's point of view, we post an "issue" that we've encountered and leave it up to Microsoft to fix the issue.  The problem is, most of the time, this isn't what happens.  For the most part, the issue has no merit unto itself.  It's a popularity game with Connect.  You have to campaign for people to vote for your issue if you think it should be fixed.

I'm not talking about suggestions here, I'm talking about bugs.  Suggestions are what they are.  Suggestions suffer the same problem as bugs: unless the suggestion you report is already on the roadmap, it has to get enough upvotes for it to get any attention.

This is inherently flawed because popularity is not directly related to importance, priority, or impact.  If I do manage to campaign successfully for a particular bug, that doesn’t make it an more important than another.

I only use Connect to post issues.  I don't browse around looking at other people’s issues.  I feel that the majority of people registered on Connect work with it in that way.  And therein lies the problem.  No one looks at bugs, so why would they arbitrarily upvote them?  The basic flaw in this usability means that many people have simply given up on Connect—which  leaves that much less potential people to upvote defects.

It's clear that if I feel a bug is worth fixing I have to campaign for people to upvote it.  So, I'm going to periodically pick a bug (maybe one of mine) and blog about it.

The first has to do with the way right-click menus work in Visual Studio 2010.  The issue was first raised in CTP; but, effectively if you bring up a right-click menu when your mouse is around the vertical centre of the screen, the menu either pops-up or pops-down from the current mouse position--with not enough space to display all menu items.  This results in a menu that takes up little more than half the screen that you have to scroll.  It’s fairly easy to duplicate, just open a C# file and right click near the vertical centre of the code window and you’ll likely see a scrollbar.  It's a departure from the way VS 2008 worked, and it's annoying all on it's own.  Now, there's a reason for it; but, that doesn't matter.  Having a menu that uses little more than half the potential real estate and scrolls is poor usability.

There may be more that one issue logged for this, but I'm picking this particular issue logged by Josip Medved: http://bit.ly/aeZCJh

Apple's New iPhone SDK Licensing Changes are a Potential Win for Microsoft.

Microsoft is poised to release Windows Phone 7 (WP7) this year.  The success of any platform is the ability for users to run the applications they want and need on it.  That's one of the selling features of the iPhone: the App Store.  The App Store has thousands of applications available for it.  It's not really the fact that there are some lousy apps in there, it's the fact that there's choice and that adds value to the iPhone.  The iPhone isn't just a phone that plays MP3s.  It can be much more than that.

To a certain extent the App Store is reaching saturation.  There's isn't much reason for new developers to get into the App Store.  There is way to much competition and if you release something now, you're likely not the first-to-market.  The new restrictions to deploying applications on the iPhone impact the speed and the cost to market of your application.  Given the profit margins of initial app deployment, this could make or break a developer.  Prior to the iPhone OS4 SDK launch, the scales were definately tilted far in Apple's advantage in terms of application developer support.  There were issues in terms of what you could deploy to the iPhone; but overall there was great developer flexibility.  If the wording correctly describes Apple's intention, they've effectively alienated two thirds of their potential developers: Flash and .Net Developers.  Without Flash-to-iPhone and MonoTouch, developers with experience in Flash, C#, and VB.Net are now forced to learn Objective-C and the XCode IDE.  They can use neither their familiar language nor their IDE.

So, what does this do for WP7?  Well, this doesn't put WP7 at an advantage over iPhone when it becomes available.  It means that people with experience in C# and VB.NET that want to write apps for a smart phone are limited to only one phone.  The energy that people have to develop will be pointed towards WP7--which is only a good thing for WP7.  It means there will likely be more apps available for WP7 when it’s launched—increasing its potential for success.

It's almost as if someone from Microsoft asked Steve Jobs: "Come on, throw us a bone" and this is what Apple came up with that didn't overtly look like Apple is trying to help Microsoft.

Platform Developer Creativity

Any platform that opens itself to 3rd party developers to develop software for requires that these developers be creative.  Without creativity the software that will be written for the platform will not promote it.  The platform will be viewed as second rate or not leading edge.  The quality of the software will end up being second-rate and the platform will end up being viewed as same.

What does it take to promote creativity.  Well, that's pretty subjective.  But, it's easy to detect what hinders creativity.  Development tools and methodology restrictions hinders creativity.  When a developer is unable to pick whatever programming language makes them the most productive and allows them do to what they want to do, or program how they want to program; they're creativity is hindered.  When they're unable to use translation layers or compatibility layers, they're creativity is hindered.

And what are the consequences of restricting creativity?  Well, the end-users suffer.  The platform doesn't get the applications the community really wants, it stagnates, and becomes second rate.

It's one thing to only provide development tools that support a subset programming languages or language; but it's another to actually restrict what language developers can develop in.  It serves no purpose other than to control.

The Add Reference Dialog is the Wrong Scenario

There’s been complaints, in some for or another, about the Visual Studio Add Reference dialog since it’s creation.  Some are very well founded.  Defaulting to the .NET tab then spending many seconds high-jacking the UI while it loads the list is not a good experience.  VS 2010 takes a step forward and puts the work to enumerate the assemblies on a background thread and changes the default tab.

But, there’s still complaints about the dialog and the .NET tab.  Some complain that assemblies aren’t added in alphabetical order so it’s difficult to do anything until the list is entirely loaded.  Others complain that the list “jumps around” making it hard to read.  Some of these complaints might be solved by not sorting the list.

But, I believe, no matter how “good” anyone makes this dialog, a scenario that includes an Add Reference dialog to resolve a type that’s contained in a GAC assembly, or in another project in the current solution is inherently flawed in terms of a user experience.

The GAC is essentially a database of assemblies, and an assembly is partially a database of types.  Ergo, the GAC is a potential database of types.  I shouldn’t need to tell Visual Studio what assembly to use for types within the GAC, it should just look it up.  I don’t care what assembly contains the type, there’s no value to me having that knowledge or finding it out, I simply want to use that type.

I propose, rather than spending many resources on the Add Reference dialog, that Visual Studio attempt to automatically find the assembly that hosts types that it doesn’t have an assembly reference for.  This doesn’t have to be automatic; it could be an option for unknown type errors, like a “Find and add reference” smart tag item.  When I select that item I would then enumerate types in assemblies in the GAC that apply to the target framework for the project I’m trying to use the type within.  If the assembly is found in the GAC or in the current solution, add a reference to it the assembly or the project.  This data could be cached (either in memory or on disk) to make subsequence searches faster.  If the type can’t be found, bring up a browse dialog to browse for the file. 

Essentially, the fact that a type is contained within an assembly is simply an implementation detail that I shouldn’t need to deal with to write software in .NET.

MEF is not An IoC container; but MEF uses IoC

Somehow I got on the conversion of MEF while chatting with Glenn Block.  IoC came up in that conversion.  I believe, at some point, I said something along the lines of MEF is not an IoC container; but MEF uses IoC.  Someone else asked me to clarify that after the conversation.  It’s a common misconception that MEF *is an* IoC container.  I thought it might be useful to summarize those conversations for others.

Part of what gives MEF the ability to do what it does is most certainly IoC.  Traditional dependencies (control) are inverted so that something (the host) doesn’t depend on a concretion (the extension, in the case of MEF) but an abstraction.  The abstraction with MEF and IoC is an interface.

MEF manages extensions—dependencies—that may or may not exist at run-time but are rarely known/exist at compile-time.  This needs to occur because you want 3rd parties to extend your application (of course, conceivably you must produce and publish your application before a 3rd party can even conceive of extending it).  For any one dependency, MEF may be managing multiple extensions.

The difference with an IoC container is that it’s managing static dependencies: dependencies that must exist at compile-time in order for the application to correctly run at run-time.  The impetus of IoC is different than MEF in that you don’t want to offer the ability to “extend” your application, but ensure that a particular class doesn’t have a direct coupling (or dependency) on another class.  IoC doesn’t remove the dependency entirely, it just means the code can evolve independently.  For the application to run correctly when deployed, it depends on ClassA being injected into ClassB at some point for that to happen.  But, ClassA can compile without ClassB.  This is always a one-to-one dependency.

If MEF were truly an IoC container then you’d expect be able to use an IoC container to extend an application at runtime—which is not the case.

Women in High Tech

I know a lot of really good people in software development from around the world.  I’m fortunate to have spent face-to-face time with many of these people.  These people bring great value to our industry.

One thing that was apparent again at the MVP Summit is the heavy male attendance on the software development side.

The point was made a couple of times and some tweets flowed about it a few times.  Is it a good-old-boy’s network?  Are software development leaders dominated by the “Alpha Male”.  Are women simply not willing to put up with any of us?  I personally don’t know.

What I do know is that, as a community, we’re not better off for it.  Women bring a sense of communication that is lacking by many men in the software development industry.  MVPs are generally exceptional in this respect; but they’re not immune.

I have a couple of challenges of my readers.  I challenge my readers to foster and mentor more women in software development.  I also challenge my readers to help point out women in software that should be

If you know a woman in high-tech that you believe should be recognized just as much as any “Alpha Male”; please point them out.  Use this blog if you like, or call them out on your own blog—detail why you think they’re leaders in our industry and deserve recognition.

What is Data-Driven Design

Data-Driven Design is a process of designing software structure and functionality.  Data-Driven Design infers functionality mainly from the information that the software is meant to maintain.  The functionality of the system focuses on having to create, view, and update that information.

Data-Driven Design is useful for designing data models and designing database schemas.  The definition of data and the structure of a database is solely focused on the data it models or contains.

Data-Driven Design differs in focus from Structured Design, which focuses mainly on what logic needs to be performed by defined how the logic changes program state.

Nourishing Technology and product communities.

Software technology and products have had a fairly unique attribute until recently: communities.  Software technologies and products have had this seemingly innate ability to have a group of people rally together about the product.  This community is a positive thing for the product: it provides technical (an sometimes emotional) support for the product and promotes and evangelizes the product.

With the maturity of online social “platforms”, many non-software products are trying to build their own communities to reap the benefits that software product communities have gains for so many years.  This trend simply validates the importance of product communities.

So, how can a company nourish and maximize the benefits of a product community?

First of all, we’ve touched on some of the benefits of these communities; let’s detail some other benefits:

• Free technical support personnel—users helping users
• Free promotion—comfort of real-world users to potential customers
• Highly focused and vetted feedback—users-helping-users point out documentation/usability short-comings
• Free Quality Control—users-helping-users point out flaws and workarounds.
• Product developers feel empowered and more like contributors.

Some of the side-effects of the benefits include:

• Increase sales
• Reduced support costs
• Increased quality
• High ROI for product development because it’s more focused to user need.
• Reduced product development costs.
• Improved employee morale.

Clearly an established community  is positive to the bottom line.

Knowing what some of the benefits are, we can focus efforts on maximizing those benefits.  Without some way for a community to gather and communicate there’s no way for the community to provide any sort of support for fellow members.  The ability to community members to gather provides the ability for the community to openly discuss the benefits of the product and the different ways to use the product to solve problems.  This positive community communication promotes the product by providing potential customers with real-world solutions to their existing problems and details how to use the product to realize those solutions.  A positive community also puts a human face onto the product and company that potential customers can associate with.  Recognizing community leaders categorizes and prioritizes users and their communications.  Community communication provides tangible feedback about the product and company that can be mined at any time and vetted by category.  Employee involvement means the company is more personal and provides employees with a sense of belonging and empowerment because they see the human factor of their work.  Employee work into the product is of higher quality because employees see the human impact of what they are working on and have a sense of belonging.

Nourishing Community Guidelines

• Community is not a replacement for technical support.
• Provide an identity for your community.
• Provide an presence for your community.
• Provide top-notch technical support.
• Be open about the future.
• Provide a positive feedback collection mechanism.
• Organize, prioritize, and cultivate feedback.
• Treat your community efforts as a product.  They need technical support, to be user-focused, high-quality, reliable, robust, easy-to-use, and provide a positive experience.
• Provide recognition for community super-stars.
• Rapidly improve product to promote positive community communication.
• Employees should be tasked with and regularly communicate with the community.

The weather outside is frightful

With news and Twitter reports of snow coming to the mid and eastern parts of North America, I’m reminded of when my family moved (temporarily) from Canada to St. Louis Mo. (okay, really a suburb of St. Louis).

St. Louis is a Midwestern city in the United States.  As such, it gets a “different” amount of snow than we were used to.  Sure enough, the first few months we were there it snowed.  Nothing major in our books.  About 6 inches, if memory serves.

Well, if our neighbours hadn’t thought this was some sort of natural disaster!  At the time, St. Louis (or at least he municipality we were in) didn’t have snow ploughs.  Well, as you can imagine, if there’s no way to get rid of 6 inches of snow (and no one really gets winter tires) everyone was at a standstill.  As I recall, we still had snow tires on our Cutlass Sierra; so, we proceeded to drive around to do whatever we needed to do.  Going to the grocery store was a bit of a waste of time because the shelves were bare.  With news of several inches of snow, everyone bought whatever they could get.

We took it in stride and strapped on our cross-country skies and skied around the neighbourhood.  I found out later that people were looking at us out their windows wondering why these crazy people were outside risking their lives!

Of course, schools were closed and businesses were shut down until the snow could be removed.  I think it was a full two weeks before they procured some ploughs to stick on the front of garbage trucks to motor around the roads getting snow off them.  We had to spend an extra 20 minutes a day in class to make up for the lost time at school.

Returning to Canada (Ottawa), I can only remember once when schools were closed due to the cold weather.  And it was due to the temperature being –40 C.  I can’t begin to count how many times we’ve received over a foot of snow, simply shovelled/ploughed it out of the way and gone on with life.

Anyway, good luck to those areas of North America that can’t handle a significant amount of snow.  Believe me, it’s survivable.

The Difference between an Anti-Pattern and a Code Smell

I think the term “Anti-Pattern” is being over used.  There’s various definitions for Anti-Pattern like “obvious but wrong, solutions to recurring problems” and “common approaches to solving recurring problems that prove to be ineffective”.  All definitions have a common thread: they’re recognizable solutions (pattern) that don’t work in at least one way and should never be used.

This means that anything that does work, when used correctly, isn’t an Anti-Pattern.  Transitively, that doesn’t make incorrectly used Patterns Anti-Patterns.

Code Smells, on the other hand, are defined as “…a hint that something might be wrong, not a certainty.”.

I’ve seen the term Anti-Pattern used in a couple of places lately that describe scenarios where patterns are used incorrectly.  Each and every pattern has a time and a place (a context).  Outside of that context, it is not an anti-pattern.

The term Code Smell is much better to describe inappropriate uses of patterns.

For example, Mark Seemann recently blogged that Service Locator is an Anti-Pattern.  I disagree.  I argue that there is a time and a place for Service Locator.  Incorrect use of Service Locator is definitely a code smell—it’s an indication (a hint, not a certainty) that there’s something wrong with the design.  The fact that you’re using Service Locator instead of Dependency Injection is, indeed, a design issue.  But, dependency injection may not be possible.  WebForms, for example.  I can’t inject dependencies into a web form because I have no control over it’s construction.  I’m forced to either use a Service Locator or a Factory to aid in my decoupling efforts.