I love to Grunt & Gulp

Task Runners – like Grunt & Gulp are such time-savers!

Reason: Automation!!!
Remove the “grunt work” by making tasks repeatable & standardize build/deploy scenarios, win-win!

Now, I am sure many of the savvy techies in you would have already checked out Grunt/Gulp and using them in your own ways. Task Runners have been in the wild for some time now, with excellent tutorials to get you started & so I will not delve into the details of how/what/why of these items.

The point of this article is for an interesting thought I had:

  • Is there any real need for such a framework(s) in your code in the first place?
  • Aren’t we introducing additional components + complexity into our code by having such items?

Is there an alternative to get the automation benefits of Task Runners, without the need for additional complexity and/or bloat of adding such frameworks into your code?

When this thought occurred to me late last night (yes, during a New Year’s Eve Party & yes – I am THAT kind of nerd!), I just could not wait to get started & give it a twirl in the NPM world & see where I get to.

More specifically, I was thinking of code along the lines of:

// code in package.json
scripts: {
"build": "npm build:script && npm build:css && npm:deploy",
"build:script": "browserify src/index.js -o dist/lib.js",
"build:css": "less"

As soon as I started along these lines, a small voice in my head went:
did someone think of such a solution before & if yes, what does that code look like?
Answer: Google says someone already has got there first.

As I tip my hat to the master, I also realize that I have been 2 months 1 day slower in coming up with this thought & 23 days slower in publishing a solution


I would strongly recommend to read through his material before continuing.

My personal opinion is that he is on to something here & I do see all the benefits in the solution.

Question: will I use the proposed solution in my own code-base?
Answer: While I really like the solution, is it worth the cost of readability for someone to “get” what it really stands for? I don’t know.

I will let this one simmer for a while & eventually wean off Grunting/Gulping.

I am too much in habit at this point in time.

Happy 2015!

Code Craftsmanship, is dying

A gloomy title, no doubt, but reality is Code Craftsmanship is indeed dying.

The Lament

Gone are the days when a developer would come in to work & not worry about going home till the code works, code comments meant something, the unit tests were written & passed.

Gone are the days when developers knew what code they had written & could recite it backwards if needed.

Gone are the days when the developer read other developer’s code like you would read the latest thriller novel.

Gone are the days when there were these “Coding Oracles” who knew everything about how to code & you stood in awe in front of them eager to learn & see how the genius went about doing his magic.

The Commercialization of Coding

Coding is now a commercial activity. Developers are the “machines” which are expected to churn out code faster & faster to meet the every demanding & insatiable appetite of the new “digital world”. Where is the time for deeper thought, reflection & impact analysis?

Commercial (a.k.a $$) interests is the name of the song & coding purity is just a wrong note which needs to be avoided for the symphony to be complete.

How many times have you heard a developer say: “I could not finish unit testing/review/documentation/commenting as I had to do (blah blah)”.

Sure, we can blame the developer for being lazy/late or the $$ being more important or the market timing being the more important factor etc. etc. for missing out one of the core components of any development activity.

Sure, we will also feel GREAT for the arguments we present for NOT doing something.

But, have you ever gone back to the original project plan & saw the contents of the plan?

In my recollection, I have NEVER seen a project plan without time being allocated for analysis, unit tests, reviews, documentation – all the fine things which make code complete.

Then why is it that the usual end product of the the effort is lacking these aspects? Where is the time, promised in the plan,  lost?

This is what I term as the “commercialization of coding” where developers & their leads, project managers, product owners – tend to think software (especially modern software) as having reached a level of maturity where these basic items can be missed & yet you will end up with a stable finished product.

No – it cannot be & it will not be, at least not till we define “Professionalism” in coding.

Professionalism in Coding

Traditional crafts like: plumbing, carpentry, masonry, architecture & construction, the auto industry have had a huge head start over IT.

While these industries are mature in the sense of their basic guidelines & principles, IT & consequently coding is still an evolving field where we are still learning new ways of doing things. Better processors, dual/multi-core processors are forcing us to think of new ways of writing our code to harness the powers unleashed.

But, unlike the traditional crafts where the apprentice has time to gain experience & expertise before he is given the immense responsibility of moving up the ranks, it is relatively easy in the Coding world to move up – especially if you are one of the so called: “knows the latest technologies”.

Unlike traditional industries where an building Architect will get sued for even a small design flaw in the construction of a building, Software Architects file everything under the guise of a “bug” & set priorities & release dates of when the bug will be fixed.

Don’t get me wrong – software development is an extremely “intellectual” activity with perceived easy of fixing issues and/or changing designs as compared to a physical building, but if we really look at the vast majority of implementations, it is painfully obvious that “Professionalism” is missing.

Professionalism – is the ability to be true to your craft & take all the steps necessary to know it to the best of your abilities & nurture, practice & hone your techniques over & over again before doing it on a real project.

Come to think of it – how many of you would feel confident if you were the very first patient of a dentist who passed out of college recently? Apply that to software – how many of the software architects today are designing highly complex systems on a completely new technology for the very first time as a “new & challenging opportunity”?


Commercial interests will continue to rule (& fund) projects, make no mistake.

But, what can you do so that even if you are part of that mill – you are being true to the business? Practice, practice & more practice is the only way IMO. Make your mistakes when you practice & reserve your flawless performances when you code in real life – the commercial interests expect it.

Before I sign off, please browse the following which echo some of the same sentiments:

Software Craftsmanship & Code Retreats with Corey Haines

Software Craftsmanship

Jeff Atwood in his indomitable style:

Prediction is very difficult…

Prediction is very difficult, especially if it’s about the future – Niels Bohr

I was reading an extremely interesting article about the Theory of Disruptive Innovation. Needless to say, Steve Jobs features prominently when we look up any material in this area.

Let me point to one such article which talks about how Steve Jobs solved the Innovator’s Dilemma.

I am not your typical iFanBoy, but you need to respect what the man achieved in his lifetime. The impact of the iPhone/iPad/iMac has been so profound that any literature about disruptive innovation is quite incomplete without understanding the workings of the mind of Steve Jobs.

At this point, I want you, my dear blog-reader, to read an interview of the person who “influenced” Steve Jobs & may I ask you to pay close attention to the last 3 questions in the article – which brings us back to the real purpose of this article, enjoy :)

Technical Debt – time for payback!

The US economic outlook is looking bleak & the markets are going flip-flop everyday since the S&P credit-rating downgrade – all of this in response to the US Nation Debt of over $14 trillion & counting!

Do you know, as developers, what is the Technical Debt in your code-base?

Have you been able to estimate, measure, track & payback this debt before it becomes a burden & you too face a credit-rating downgrade by your customers?

Surely, the popular Project Management tools like – TFS, Jira, MS Project etc., should be able to tell you these metrics?

No? Think again

What is Technical Debt

This article will not focus on the definition of Technical Debt, there are tons of well-written articles out there with more details than I can ever hope to cover. Some of the most useful links I have referred to while writing this article are:

Technical Debt – a basic primer from Wikipedia

Technical Debt – the different kinds of debts & more depth in understanding

Technical Debt Quadrant – by Martin Fowler, prepares the kind of mindset needed to address this topic

Paying down your Technical Debt – by Jeff Atwood, a good article to understand why paying down is so important

Is Technical Debt still a useful metaphor? – interesting read. I think the term is even more relevant today than before, but this article has an interestingly different view point.

With the education out of way, my focus for this article is to put forth some practical steps & techniques I have used in my previous projects to pay down Technical Debt.

Robert McIlree has proposed a method to measure Technical Debt. But like the author mentions – some of the parts are based on approximations & we need a more solid method to estimate & project the costs.

Raj Anantharaman mentions another technique using TFS for the measurement & graphical representations.

The technique I am putting forth below is a mix of both Robert & Raj’s work – but generalized to work with any Agile or non-Agile process you might be using & independent of any tools.

To bell the cat

Let us consider a project (Agile/non-Agile does not matter) which has a list of business requirements.

This list can be called a Product Backlog (Agile) or a Business Requirements Document (non-Agile). For simplicity of explanation, let us use the common terminology of Product Backlog to mean both the Agile & non-Agile description of this list.

Along with the Product Backlog, create another list called the Technical Debt Backlog – which, at the start of the project, might be a list of the Technical Debt inherited to the team like: existing services or code-base being used as part of the project, existing schema’s etc. If you are lucky enough to start from scratch, this Backlog will be empty.

Now, for every Sprint/Release/Iteration, record all the items which are termed as Technical Debt as line items in the Technical Debt Backlog.

Estimate & prioritize the Technical Debt Backlog the same way as you would any of your Product Backlog items & you are on your way to Technical Debt freedom!

For the Mathematically-minded

Here are some interesting metrics which can be generated from the Technical Debt Backlog

Table 1: Technical Debt Metrics
Metric Description Units
Debt per release The measure of Technical Debt items introduced into the code-base per release number
Debt per resource The measure of Technical Debt items introduced into the code-base per resource number
Debt Reduction Velocity The measure of Technical Debt items closed/released per release number
Debt Aging The measure of how long the Technical Debt item was sitting in the Technical Debt Backlog before it was taken up in a release Days
Debt Cost The measure of how much the debt costs Man days

These calculations are simple & straight way of looking at the Technical Debt in your project by listing out the items explicitly, estimating & prioritizing them & having your team work on these items.

Technical Debt – like all debt items – can be a very powerful tool to meet your short-term deliveries.

Similarly like all debt items, the longer you have Technical Debt in your code-base, the more interest it gains & the more expensive it is to payback what you owe.

Beware & take care!

It’s all in the mind of a pig!

Having worked with Agile teams starting back in 2002, my personal experience is that, the mindset of the pigs on the team is a key differentiation between the success or failure of the project.

It does not matter if you have a local co-located Agile team or a global, multicultural, team spread across multiple time-zones Distributed Agile team – it is as simple as the mindset of the members in the team which can be the difference between successful delivery or failure at every step.

The Agile Manifesto values:

Individuals and interactions over processes and tools

I think the authors got this spot-on for the succinctness of the statement & the fact that it is the very first value of the Manifesto!

Individuals & interactions – especially within the Agile team (the Pigs) are the key.

So, what needs to be in the mind of the pig & why does it matter, given that its commitment to the endeavor is bacon?

The Mind of a Pig

For me – if every individual on the Agile team knows his area of contribution & contributes to the best of his ability on that, constitutes the ideal Agile team.

This expectation includes:

  • Understanding the role that individual is performing
  • Understanding the deliveries for that role
  • Understanding the measurement of “done”
  • Understanding how this role impacts the other roles & their deliveries

If an individual contributor can come into an Agile team with the above understanding very clear in his mind, it is of immense help & an major contribution in itself.

Sometime, the understanding of the role in the grand scheme of things can be rather humbling, other times tad disconcerting – but all-in-all extremely vital mindset for the success of the project.

One might argue, that having individuals with this mindset, is an asset to any project & is not dependent on the execution methodology used & indeed will be a success in Agile & non-agile project.

But like I started – it’s all in the mind of a Pig!

Using MEF with Common Service Locator

“The Managed Extensibility Framework (MEF) simplifies the creation of extensible applications. MEF offers discovery and composition abilities that you can leverage to load application extensions.” – (mef.codeplex.com)

“The common service locator library contains a shared interface for service location which application and framework developers can reference”  – (commonservicelocator.codeplex.com)


How to get them both working together, is as below.

NOTE: I am assuming that the reader is aware of Dependency Injection pattern & the Common Service Locator.

The Steps:

  1. Download the CommonServiceLocator_MefAdapter.4.0.zip file & extract the MefServiceLocator class written by Glen Block
  2. Create a new ASP.Net MVC 2.0 Web Application Project
  3. Include the MefServiceLocator class into this project
  4. Open the Global.asax.cs file
  5. Make the following code change in the Application_Start event:
    protected void Application_Start(){     

  6. Write the RegisterDIContainer method as:
    protected void RegisterDIContainer(){
        var catalog = new AggregateCatalog(     
            new AssemblyCatalog(Assembly.GetExecutingAssembly()),     
            new DirectoryCatalog(Server.MapPath(“~/Plugins”))
        var composition = new CompositionContainer(catalog); 
        var mef = new MefServiceLocator(composition);
        ServiceLocator.SetLocatorProvider(() => mef);


  7. With this in place, you are now good to do:  

    var controllers = ServiceLocator.Current

Code on…

Extending ASP.Net Memberships with Access Points – Part 2

In part 1 of this series, we described a way to simplify our code to abstract some of the role-based implementation which the ASP.Net Memberships & Roles gives us.

In this part, we will explore the extensions needed in the SQL Server database to have additional table which will help store the data needed to implement this concept.

The Data Model Changes

Access Point Data Model

The above diagram shows the extension needed to the data model to support the additional functionality.

Table Name Purpose
aspnet_AccessPoints This is a master table of all the access points defined in the application (by ApplicationId). The “Value” column can store any value associated with that Access Point.
We will see the use of this field in a future article where we will explore some of the advanced techniques of Access Points
aspnet_RoleHavingAccessPoints This is a simple Role to Access Point mapping table. Using this table we will be able to link a Role to one or more Access Points.
The “Value” column is present here to override the default value in the aspnet_AccessPoints table with a different value for a specified Role
aspnet_UserHavingAccessPoints This is a table which maps the users to Access Points. We will use this table to grant special permissions to a single user.
For example: Consider a situation where all users in role “Editor” should be able to edit articles on your blog, but for use John Doe, who is in the Editor role, also need permission to approve comments.
Usually, we will create a different role for this & assign John Doe to that role.
But in the Access Point implementation, we will use this table & have an entry to map John to that Access Point.
The “Value” column in this table is used to override those of the aspnet_AccessPoints and aspnet_RoleHavingAccessPoints table values. In effect, you can give specific values to Access Points at a user, role or Access Point level with the same order of priority.

With these changes in place, we are now ready to start writing some code to expose this functionality & start seeing some benefits of this technique. We will cover this in part 3 of this series.

Happy Coding!

All articles of this series:

  • Part 1 – an introduction to the Access Point concept
  • Part 2 – database changes needed to enable Access Points
  • Part 3 – code to enhance the ASP.Net Memberships and Roles
  • Part 4 – some common usage patterns and advantages
  • Part 5 – a simple UI implementation to show use of Access Points
  • Part 6 – an admin console to manage Access Points