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\  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:
        <Reference Include="System"/>
        $if$ ($targetframeworkversion$ >= 3.5)
        <Reference Include="System.Core"/>
        <Reference Include="System.Xml.Linq"/>
        <Reference Include="System.Data.DataSetExtensions"/>
        $if$ ($targetframeworkversion$ >= 4.0)
        <Reference Include="Microsoft.CSharp"/>
        <Reference Include="System.Data"/>
        <Reference Include="System.Deployment"/>
        <Reference Include="System.Drawing"/>
        <Reference Include="System.Windows.Forms"/>
        <Reference Include="System.Xml"/>

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:
        <Reference Include="System.Configuration"/>
        <Reference Include="System"/>
        $if$ ($targetframeworkversion$ >= 3.5)
        <Reference Include="System.Core"/>
        <Reference Include="System.Data"/>
        <Reference Include="System.Deployment"/>
        <Reference Include="System.Drawing"/>
        <Reference Include="System.Windows.Forms"/>

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  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 file into the cache directory located at C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\ProjectTemplatesCache\CSharp\Windows\1033\  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:

project references

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


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:

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:

public class TestSomething
    public void FailingTest()
        Assert.Fail(“Fail description.”);
    public void PassingTest()
    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.


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:

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.