Category Archives: Code

Software Development

An Asp.Net MVC HtmlHelper.RadioButtonsFor helper

These overloads will do the hopefully-obvious thing with a Model => Model.Property and a List of SelectListItems (or a single SelectListItem)

Use the RadioButtonLabelLayout setting to control whether you nest the radio button inside its label, or lay them out as siblings; and whether you like text before button or vice versa.

    public static class HtmlHelperRadioButtonExtensions
        /// <summary>
        /// Returns radio buttons for the property in the object represented by the specified expression.
        /// A radio button is rendered for each item in <paramref name="listOfValues"/>.
        /// Use <paramref name="labelLayout"/> to control whether each label contains its button, or is a sibling, 
        /// and whether button precedes text or vice versa.
        /// <list type="bullet">
        /// <item>
        ///     <term>Example result for the default labelLayout= RadioButtonLabelLayout.LabelTagContainsButtonThenText:</term>
        ///     <description>
        ///     &lt;label for="Object_Property_Red"&gt;&lt;input id="Object_Property_Red" name="Object.Property" type="radio" value="Red" /&gt; Red&lt;/label&gt; 
        ///     &lt;label for="Object_Property_Blue"&gt;&lt;input id="Object_Property_Blue" name="Object.Property" type="radio" value="Blue" /&gt; Blue&lt;/label&gt; 
        ///     </description>
        /// </item>
        /// <item>
        ///     <term>Example result for labelLayout= RadioButtonLabelLayout.SiblingBeforeButton:</term>
        ///     <description>
        ///     &lt;label for="Object_Property_Red"&gt;Red&lt;/label&gt; &lt;input id="Object_Property_Red" name="Object.Property" type="radio" value="Red" /&gt;
        ///     &lt;label for="Object_Property_Blue"&gt; Blue&lt;/label&gt; &lt;input id="Object_Property_Blue" name="Object.Property" type="radio" value="Blue" /&gt;
        ///     </description>
        /// </item>
        /// </list>
        /// </summary>
        /// <param name="listOfValues">Used to generate the Value and the Label Text for each radio button</param>
        /// <param name="labelLayout">One <see cref="RadioButtonLabelLayout"/> to control the layout of the rendered button and its label.</param>
        /// <returns>
        /// An MvcHtmlString for the required buttons 
        /// </returns>
        public static MvcHtmlString 
            RadioButtonsFor<TModel, TProperty>(this HtmlHelper<TModel> htmlHelper,
                                                    Expression<Func<TModel, TProperty>> expression,
                                                    IEnumerable<SelectListItem> listOfValues,
                                                    RadioButtonLabelLayout labelLayout = RadioButtonLabelLayout.LabelTagContainsButtonThenText)
            if (listOfValues == null) { return null; }
            var buttons= listOfValues.Select(item => RadioButtonFor(htmlHelper, expression, item, labelLayout));
            return MvcHtmlString.Create(buttons.Aggregate(new StringBuilder(), (sb, o) => sb.Append(o), sb => sb.ToString()));

        /// <summary> Create an <see cref="IEnumerable{T}"/> list of radio buttons ready for individual processing before rendering</summary>
        public static IEnumerable<MvcHtmlString> RadioButtonListFor<TModel, TProperty>(
                    this HtmlHelper<TModel> htmlHelper,
                    Expression<Func<TModel, TProperty>> expression,
                    IEnumerable<SelectListItem> listOfValues,
                    RadioButtonLabelLayout labelLayout)
            if (listOfValues == null) { return new MvcHtmlString[0]; }
            return listOfValues.Select( item =>  RadioButtonFor(htmlHelper, expression, item, labelLayout) );

        public static MvcHtmlString RadioButtonFor<TModel, TProperty>(
                                HtmlHelper<TModel> htmlHelper, 
                                Expression<Func<TModel, TProperty>> expression, 
                                SelectListItem item, 
                                RadioButtonLabelLayout labelLayout)
            var id = htmlHelper.IdFor(expression) + " " + item.Value;
            var radio = htmlHelper.RadioButtonFor(expression, item.Value, new {id}).ToHtmlString();
            var labelText = HttpUtility.HtmlEncode(item.Text);
            TagBuilder nestingLabel = null;
            switch (labelLayout)
                case RadioButtonLabelLayout.LabelTagContainsTextThenButton:
                    nestingLabel = new TagBuilder("label") {InnerHtml = labelText + " " + radio};
                    return MvcHtmlString.Create(nestingLabel.ToString());
                case RadioButtonLabelLayout.LabelTagContainsButtonThenText:
                    nestingLabel = new TagBuilder("label") {InnerHtml = radio + " " + labelText};
                    return MvcHtmlString.Create(nestingLabel.ToString());
                case RadioButtonLabelLayout.SiblingBeforeButton:
                    return MvcHtmlString.Create(radio + " " + htmlHelper.Label(id, labelText));
                case RadioButtonLabelLayout.SiblingAfterButton:
                    return MvcHtmlString.Create(htmlHelper.Label(id, labelText) + " " + radio);
                    throw new ArgumentOutOfRangeException("labelLayout", labelLayout, 
                                "This is not a valid RadioButtonLayoutStyle for rendering a radio button");

    public enum RadioButtonLabelLayout
        LabelTagContainsButtonThenText = 0,
        LabelTagContainsTextThenButton = 1,
        SiblingBeforeButton = 2,
        SiblingAfterButton = 3,

IIS Express GUI

Looking for a admin GUI so I can start/stop IISExpress websites I quickly found iisexpressgui on codeplex/ which is by Matteo Tontini and iis express manager. They both do pretty much the same thing. They also both only pick up only the first binding for a site, so if you’ve got two — for instance one for http and one for https — then you might need to edit your %Documents%\IISExpress\config\applicationhost.config to choose the one you want to use.

The Yes, The No and the Painful: using, and failing to use, estimates for a no-go decision

@AgileKateOneal recently asked for examples of effective estimate use in medium/long-term planning, and making a no-go decision sprang instantly to mind.

Many such decisions are casual and quickly forgotten: the back of an envelope calculation which says that an idea is well beyond what we can afford; and the conversation moves on. An NoEstimator might object that one could profitably try out something rather than nothing, such is sometimes true but creative thinkers in commerce & IT can always generate a hundred more ideas than a team can try out; you can’t try out everything.

But a couple of more specific examples from recent work:

Example 1: Small UK charity looking at CRM options

in November last year I worked with a small UK charity, who were badly in need of some kind of CRM software to keep in touch with supporters and project partners. They were running largely on spreadsheets built from downloaded reports from / etc. They also had an Access database with a fair amount of donor & similar data in it.

Question: Is it better to pay for a CRM solution — typical charity starting price £10,000 going up to easily £100k – or get someone to do enough work on the Access database to make it a usable solution?
My Answer: I first spent some time discovering and documenting their main use-cases (to clarify: their ‘business’ use cases, that is the things the charity had to do whether manually or with IT). I gave that picture to the CRM providers so that they could give us a sensible proposal. And I worked out an estimate for extending/developing the Access database. Based on that, we could see that a CRM consultancy/solution looked like £10-£20k (5 year cost) and the DIY-option about 200-400 developer days.

Even with this level of accuracy it was good enough to see that DIY should be a no-go. I did not expect this. I thought that the charity’s actual requirements were sufficiently small that we could do something useful for a few thousand pounds. But two hours spend going through their use-cases on my estimating spreadsheet showed me that I was wrong. So, I recommended the best value CRM option.

This, I think, is planning 101: a couple of hours working through the detail on paper is a lot cheaper than running the experiment; but can be enough to make a probably-good decision.

Example 2: Provide a system to automate a small team’s manual processes for a capped price

This was for a financial services company in 2013. The team were working on PPI claims for an insolvency practitioner (obliged to pursue potential claims that might bring in some money for their clients’ accounts) and had about ten thousand potential claims with hundreds per month being added. They had been working manually on spreadsheets for over a year.

I spent 4 days on analysis and listed a set of use-cases that covered the processes end-to-end; and I estimated that a suitable system could be done for about 40 days development work. The estimate cost about 3 or 4 hours on top of the analysis.

The contract to provide was capped-price. The customer was not open to a no-estimates approach. And I accepted being bargained down to below my estimate (Doh! I hear you say. Quite so). The actual cost came out close to (but above) my original estimate, but could have used another week’s work to make it user-friendlier.

The better course would have been to use the estimate/budget mismatch to declare a no-go rather than accept a reduced budget. This might have resulted in the client agreeing to go ahead anyway (which might in turn have led to a no-estimates approach to the work). Or it might have led to no contract. Either way would have been less painful and more controlled than over-running the budget.

The Known Unknowns Matrix

I’m sure that I.T. is not the only industry to have gratefully latched onto the the former Secretary of State’s famous phrase, “The unknown unknowns”. It’s a useful phrase to ponder if you’re responsible for planning or estimating anything. A recent slideshare by Danni Mannes on Agile Architecture pointed out to me that one should really consider the full matrix:

Known Not Known
Knowns Things we know, and we know we know them Things we know but don’t realise we know them; tacit knowledge that we take for granted. Become a problem if we are responsible, and fail, to communicate them to people who don’t know. Also a problem when we start work in a new context and don’t realise that what we ‘know’ is no longer valid, so they become unknown unknowns.
Unknowns Things we know that we don’t know. We can record the risk, and estimate a cost for investigation & discovery Things we don’t know that we don’t know. This is the quadrant most likely to shipwreck plans.

My personal takeaway from this is that I will try using this quadrant when listing risks. Just having a space for the possibility of unknown knowns & unknowns can be an impetus to do a little risk-storming & consultation, to help you discover the as-yet-unknowns.


I’ve just read the brief and brilliant

Coplien & Bjørnvig : Lean Architecture For Agile Developers. A Review

Four years after this book came out, Agile Architecture has at last become a Thing. But as the nuance of its title hints, this book is not fad-driven. It is a carefully-thought out exposition of what architects can learn from lean and agile ideas, and what they can do better as a result.

Well. It’s partly that. If you are a practising architect, it is actually four must-read books in one.

If you are not, you might dismiss this book for two reasons. The first, that judging by other reviews & my own experience, the homespun style of the first half does not suit a bullet-pointed gimme-the-headlines-now generation. The second is that if you have not experienced the pitfalls of architecting and doing software in a real organisation with actual people in it, then Coplien & Bjørnvig’s pearls of wisdom may impress you much as the agile manifesto might impress a cattle rancher.

It is not a beginner’s book. It is the mature distillation of the sweat-soaked notebooks of a fellow-traveller who has stumbled over rocky terrain, been through the tarpits and has some hard-bloody-earned (and, academically researched) wisdom to share as a result.

I said four must-reads in one. They are:

1) The (literally) decades of experience of a leading practitioner & thinker in the field.

2) A thought-through answer to the questions, what can we learn from lean & agile. Whilst value-chains and some technique feature, the authors’ secret conviction is surely that Technology Is All About Human Beings. “Everybody, all together, from early on” is their Lean Secret. “Deferring interaction with stakeholders [users, the business, customers, domain experts, developers], or deferring decisions beyond the responsible moment slows progress, raises cost and increases frustration. A team acts like a team from the start.”

3) Which leads to that which for me, as a more techy-focused reader, was the marvel of the book. Clements et al in “Software Architecture in Practise” offered attribute-driven design, a partitioning of the system based on a priority ordering of, primarily, technical quality requirements. Coplien & Bjørnvig all but deduce a partitioning based on the priority ordering of people: Users first, Development team next.

“The end-users’ mental model” is the refrain on which they start early and never stop hammering. From this they suggest that the first partitioning is What the System Is from What the System Does. I am tempted to paraphrase as, Domain Model from Use Cases. But their point is partly that this also neatly matches the primary partition by rate of change, because the last thing to change in a business is, the business of the business. If you’re in retail, you might change what and how and where you sell, but your business is still Selling Stuff. And at lower levels inside the organisation too: an accounting department, though there has been five thousand years of technology change, still does accounting. The users know this. They understand their domain and if the fundamental form of your software system matches the end user mental model then it can survive–nay, enable!–change and stay fundamentally fit for purpose.

Second, don’t fight Conway’s law. “Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations”. The deduction for agile teams is, partition so as to maximise the long-term autonomy of your self-organising teams. Even when the team divisions are imposed for non-technical reasons–geography, politics, whatever–still allow that fact to trump more ‘technical’ considerations. This may not match your vision of technical perfection, but it will still be the best way. Ruth Malan recently paraphrased Conway’s law as, “if the architecture of the system and the architecture of the organization are at odds, the architecture of the organization wins”. Don’t be a loser.

These points seem to me obvious in hindsight, yet they turn traditional approaches to high-level designs on their head. After considering People, yes we can considering rates of change, quality attributes, technology areas. But it’s always People First.

4) And finally. This is the first book-sized exposition of DCI architecture, which I would describe as an architectural pattern for systems that have users. Having separated What the System Is from What the System Does, DCI provides the design pattern for how What the System Does (the Use Cases) marshals the elements of the What the System Is. There are at least three notable outcomes.

Firstly that use cases are mapped closely to specific pieces of code; in the best case each use case can be encapsulated in its own component.

Secondly, that the relationship between Domain elements and Use Cases are expressed as “In Use Case X Domain element Y plays the Role of Z”. This brings significant clarity to both, and is part of the key to ‘componentising’ use cases; the Roles needed for a use case become, in the code, its public dependencies. In UML-speak, the Required Interfaces for such a UseCaseComponent are the roles needed to ‘play’ the use case, and those roles are Interfaces which are Implemented by Classes in the Domain Model. Coupling is reduced, cohesion is gained, clarity abounds.

Thirdly, the simpleness of the mapping from business architecture to code is greatly increased. Suddenly one can draw simple straight lines between corresponding elements of architecture and code.

The authors say of their work, “This book is about a Lean approach to domain architecture that lays a foundation for agile software change”. To my mind, this hits the agile architecture nail on the head. Agile software development always only ever succeeded at scale because the people doing it either knew, or had given to them, enough architecture to make it work. Software Agility, just like every other software Ility, must either be supported by the architecture or it ain’t gonna happen.

But the best thing I got from this book was the proof, before my very eyes, that correct technical design flows from knowing how to put the human beings central.

Where to Buy


ebay (UK): Lean Architecture for Agile Software Development

Amazon (UK): Lean Architecture for Agile Software Development


Amazon (USA): Lean Architecture for Agile Software Development