The problem with the rule of doubling is that it compounds. When I told someone how long a feature would take, they doubled it. Then, when that person told someone the date, the next person doubled it. What’s even crazier is the rule of doubling actual yields pretty good results. So as an organization gets larger, the rule of doubling is really the root cause of why projects take longer to get out the door.

I know what you are thinking, I am crazy but it is true. The rule of doubling is a real thing! Why?

There are two main reasons. Developer estimates have very little to do with releasing software and because you never take the time to make the rule of doubling not true.

Developer estimates have very little to do with releasing software because coding is not the only variable involved with releasing software. A great example of this is an article published 7 years ago entitled, How many Microsoft employees does it take to change a light bulb? Microsoft is definitely an extreme case, but I still experience a very similar reality. To release a new feature, the following parties are usually involved.

• Developer codes something
• Designers help if UI changes are involved
• Writers help if text changes are involved
• One or two team members review the code
• One or two team members help to QA the changes
• Project manager works on including information about the change in an upcoming release
• Support and Ops teams discuss upcoming release with Project Manager and Software Development Managers
• Ops and Development team deploy and verify changes for a release

It seems like a lot, but at Rackspace we take Fanatical Support seriously, and what that means from our software development teams is a lot of time spent to release a quality product. I honestly wouldn’t get rid of a single part of this process. All of it makes our software better and hopefully our customers happier.

This is why story points are more accurate. They measure relative size of different pieces of work and then apply past history to estimate for the future. Don’t forget that story points mean absolutely nothing to organizations or customers. If you can’t use story points to give relatively accurate delivery dates, they are worthless.

Because you never take the time to make the rule of doubling not true means that the inefficiencies that slow development teams accumulate over time rarely get fixed. Developers can easily miss the forest for the trees, working slowly on features instead of fixing inefficiencies to work faster on those features. Bad build scripts, lack of testing automation, crappy development environment, and repetitive manual processes are all build ups of technical debt that need to get resolved at some point.

The solution is good Software Development Managers. Managers need to understand the true cost of developing software, both from an initial implementation standpoint and a future maintenance cost perspective. All to often, managers don’t understand software development and hinder a teams success by setting up unrealistic expectations.

As a manager, you need to be able to set realistic expectations around timelines and also make decisions on what technical debt really needs to get resolved and what can wait. Neither of these are easy and I have made my share of mistakes in these two areas over the years. But, as a manager, I need to constantly remind myself of two questions.

Are my teams regularly meeting my expectations around releasing software (and note that if they aren’t, that is probably a managerial problem, not a team problem)?

What roadblocks do I need eliminate to help my teams meet more of my expecations?

• Gems - Having a package manager to to handle dependencies rocks. In contrast, every single .NET library includes all its dependencies because there is no package manager to make it easy. Hopefully nu can start to fill this void.
• Generators - Generators save your team time because they aren’t spending time typing out common patterns in a project. Many frameworks like .NET have code generation, but the barrier to entry seems high. Maybe I just haven’t spent enough time out it, but in a few years of programming .NET, I haven’t generated a single class.
• Conventions - Developers shouldn’t have to ask, Where should this class go?. Conventions should define that, otherwise teams are forced to define their own (which usually leads to a lack thereof except in experienced teams).
• Database management – In nearly every app I have worked with, schema gen, creation, migration, and testing integration are a pain point. Many libraries like NHibernate have the capability of doing all these tasks, but there is no instruction manual for setting it up. Therefore, most projects don’t manage their database very well.
• The build, the build, the build – Dependencies, database migrations, multiple environments, testing…need I say more? Having an out of the box build that does more than plain old compilation is a must in any solid framework. Like everything else, tools like MSBuild can do all this but the team is forced to start from scratch.

Where does Rails succeed where many applications and frameworks like ASP.NET MVC fail? Rails succeeds at allowing developers to focus on the application, not the plumbing.

nu aims to provide this for .NET.

I checked it out tonight. Here is my experience.

First step is to install it, and ruby is the only pre-req. The following commands show how to install and use it.

> gem install nu
> mkdir test
> cd test
> nu install nunit
> nu install nhibernate

Wow, that was easy. nu downloaded nhibernate and nunit, and placed them in the lib folder (including all of NHibernate’s dependencies). By the way, it literally took less than 30s for me to do this.

So what do I think?

• It is an easy and fast delivery tool.
• Using Ruby isn’t that big of a deal, but I think that is my opinion, not the community opinion.
• It is new, so it has a ways to go in terms of functionality in discovery. I can’t hate because at least they have released something and I have just dreamed about releasing something.
• Build integration (and probably Visual Studio) is going to be key. And by build, I don’t just mean NAnt and UppercuT, but MSbuild too.
• The biggest hurdle is building a “gem” community in .NET. For some reason, creating a .NET gem seems kind of awkward (even though it isn’t that hard).

class LocationTest < ActiveSupport::TestCase
 
  def setup
    @location = Location.new
  end
 
  {:empty => '', :nil => nil}.each do |key, value|
    test "address can't be " + key  do
      @location.address = value
 
      assert !@location.valid?
    end
  end
end

NUnit has the ability to do the same thing, but attributes and reflection just aren’t as elegant.

• Modifying the build feels like you are mucking in the internals of Visual Studio
• There is no convention based approaches for how to handle custom bulid targets

Now, you could go the way of NAnt, and have complete independence from Visual Studio. I think this is a mistake as well. Visual Studio, while being a royal pain much of the time, is still a very very very powerful tool. I believe we should embrace it, while using MSBuild plus conventions to achieve ultimate flexibility.

The proposal

It’s actually quite simple. Each assembly/project already has its own *.csproj file, which is in essence a partial MSBuild file. The problem is editing it is weird and scary at times, because it is auto-generated by Visual Studio.

Just add the following to any or all your csproj files.

<Project>
  ... All the visual studio muck ...
  <Import Project="$(MSBuildProjectName).targets" Condition="Exists('$(MSBuildProjectName).targets')" />
</Project>

Then add a file with that name. If your projects name is Reference.Web, then add a file named Reference.Web.targets and include it in the project. The content could contain something like the following.

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
 
  <ItemGroup>
    <Files Include="$(SolutionDir)\configuration\$(Configuration)\$(AssemblyName).*.config" />
    <Files Include="$(SolutionDir)\configuration\$(Configuration)\Common.*"/>
  </ItemGroup>
 
  <Target Name="InstallConfiguration">    
    <Copy SourceFiles="@(Files)" DestinationFolder="$(OutputPath)" />
  </Target>
 
  <!-- Override the AfterBuild target -->
  <Target Name="AfterBuild" DependsOnTargets="InstallConfiguration" />
 
</Project>

Now you have a build file separate from the project that is really easy setup and use, straight for Visual Studio.

The only gotcha is Visual Studio won’t automatically notice the build file changes, so you still have to relad the assembly after you make a build file change.

UPDATE – More robust Import statement

Via @sayedihashimi

Even better would be a conditional import, and you should use the MSBuildProjectName property instead of AssemblyName.

Enough with the chit-chat, lets get it up and running on Windows in no time.

Install

Install – Done.

Configure – Server side

This is the confusing part. I will take you through the GUI, which doesn’t exist for the Mac or Linux as far as I could tell.

Start Synergy and select the Share this computer’s keyboard and mouse (server) option. Then click Configure.

From there, the next step is adding the screens, which represent the different computers you want connected. Click the + to get going.

First, enter your local computer information. Seems weird that it didn’t add it by default, but it doesn’t. Basically, all you need to enter is your computers name (which can be found/changed on the Synergy Info button on the main configuration screen).

Next, enter in the client computer’s names that you will be connecting.

From there you need to create links. Links tell Synergy how one screen should be linked to another (seems obvious huh). In our example we have two screens, so we need two links. One link will connect Screen 1 to Screen 2, while the other does the reverse.

Configuring the link is a mind trip, so much so that I can’t even describe how to do it. I suggest ignoring the size percentages, and create a sentence like left of Screen 1 of Screen 2. Then click +. After this, it becomes more obvious what you did (just trust me please).

Then the reverse.

Now just Start the server and your server config is basically done.

Configure – Client

The client really doesn’t require any configuration. Just select the Use another computer’s keyboard and mouse (client) option, then enter the server name and click Start

And now for my super sweet home-made video.

Next Steps

Read through the Synergy wiki, which will help you on more complicated setups on Mac and Linux.

I also noticed a couple things that didn’t work too well.

• Mouse is sometimes laggy – I think this may be because my server is actually my oldest computer. The lagginess isn’t bad enough for me to not use it however.
• Print Screen didn’t work too well, which made the capturing of the above screen shots a little cumbersome
• If your computer locks automatically after a certain time and it isn’t the server, synergy can’t be used to unlock it.

• Eclipse – Android and Java tinkering
• Firefox – To test, not to use.
• Chrome – Best browser out there, I promise!
• JungleDisk Desktop – Backups and synchronization are a must for any computer.
• Skype – To see people far away in real time.
• Adium – To chat to people far away or across the room, while also being able to ignore them.
• CoRD – I still need to get on Windows boxes.
• Quicksilver – App launchers are my hidden productivity tools.
• Growl – Makes Adium have cool sounds I guess.
• TextMate – The most recommended Mac editor. Not sold yet, vim is the bomb.
• Open Office – Because it is free, and good enough (maybe?)
• Tweetie – My new favorite twitter client. Warning, not for twitteraholics, but for casual users like myself.
• Git – Git is a MUST if you develop software. Even if your team uses SVN, you can still use git and should!
• MySQL – You always need a database on hand.
• RVM – Nifty way to manage multiple Ruby versions.
• Virtual Box – Because you still might need to run a little Windows stuff here and there.
• CyberDuck – Move files all over the place.
• Windows 7 on Bootcamp – Just in case

Whew!

• Promoters – Mac owners are promoters. When I asked the Twitterverse what I should do, all but one response was “Get a Mac!”. Maybe I am hopping on the bandwagon, but people love Macs for a reason.
• I missed my Linux roots. If you go back far enough in my blog, you will see I used to be a PHP developer whose work, home, and school computers were running Ubuntu.
• Windows – I can still run Windows on a VM and on Bootcamp.

So far, I am pretty darn happy with the Mac. There are some oddities, but overall it is a crisp, clean machine.

Now, enjoy the beauty that is my mac! (Ignore the Logitech nano dongle. I need my ergonomic mouse so give me a break)