Category Archives: Code

Software Development

MVC Html.ActionLink() fails weirdly with routeValues parameter in Asp.Net

It seems simple. In an MVC view page you have an @Html.ActionLink with parameters for action, controller & route values:

@Html.ActionLink("Some text","Action","Controller", new {id=1})

but instead of rendering the text with a link to the action, it renders a link with some weird URL that isn’t what you want at all.

If you use intellisense to look at the overloads for ActionLink, you’ll see that the overload you’ve got is interpreting new {id=1} as html attributes not as route values. You need the overload with one more parameter, which can be null:

@Html.ActionLink("Some text","Action","Controller", new {id=1}, null)

And then it works.

.Net Assembly Binding Redirect doesn’t work – because you have an Uppercase/lowercase error in config

Thanks to Eran Stiller for spotting the fact that assembly binding redirect fails—with no appropriate error message or clue as to the reason for failure—if you used PascalCasing instead of camelCasing casing in your config.
This fails:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="Moq" Culture="neutral" PublicKeyToken="69f491c39445e920" />
        <bindingRedirect oldVersion="4.0.10827.0" newVersion="4.1.1309.1617" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

because of incorrect case in the attributes Culture and PublicKeyToken. Make them camelCase like so:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="Moq" culture="neutral" publicKeyToken="69f491c39445e920" />
        <bindingRedirect oldVersion="4.0.10827.0" newVersion="4.1.1309.1617" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

and now it works.

Improving the accuracy of software project estimates: multiply everything by 3

I found about 10 years ago that everything I delivered in software took me three times longer than I expected.

Eventually I realised that my ‘gut feel’ for estimating a coding task was ‘about how long will it take me to code this if I make no errors & get it right first go’. Which is a good starting point for an estimate, so long as you then go on to add testing, debugging, changing or misunderstanding requirements and time to release. So if you have stable requirements and a pushbutton deployment toolchain, then x3 is about right. If you haven’t, x5 is probably closer.

I note that others have found something similar. I’m please to find that multiplying by 3 puts me about 4.7% ahead of the curve – http://alistair.cockburn.us/The+magic+of+pi+for+project+managers.

Project Success vs Project Value

Somehow earlier this year I subscribed to the chaos report email. Given the significant criticism of chaos report’s measure of success – on time, on spec, on budget – I was amused by this week’s email which poses the question whether their success criteria are relevant. What the Standish group does have that most of us don’t, is access to a large number of (unpublished and hence unverifiable) examples.

From the email: “Which is more important project success or project value? It turns out the project success and project value is orthogonal or at right angles to each other. The harder you strive for perfect success the lower your project value. The harder you strive for greater values the lower the success rate.

We know this because we have coded each of the 50,000 projects within the CHAOS Database a success rate and value rate. Each rate has a score from 0 to 100. By grouping the projects by organization we can come up with a ranking by success and value. We then can compare the rankings. One of the items we discuss is another question Is the traditional triple Constraints (cost, time, and quality) measurement still appropriate?”

I’m surprised by the assertion that success and value are orthogonal. I’d have thought that there was at least some connection between time/cost/functionality and perceived value; if the value of your project is not in the spec, surely you wrote the wrong spec?