By Chris R. Chapman at December 20, 2010 23:54
Filed Under: agile, better practices, software development

In today’s Globe & Mail business section a topical column asks:  Having an app developed: What to expect?  The author offers two ways to go:  Full-on custom (with either a firm or “two guys in a garage”) or go with a template solution.  As with everything in the world of IT he also cautions that “with size and experience comes cost”.

It’s difficult to generalize about the cost of app development, since there are so many different kinds of apps, but custom projects with bigger firms usually start in the tens of thousands of dollars. Where multiple platforms are involved, development, maintenance, and updating can easily run past $50,000 for a mid-size project. Hiring a large developer for more complicated projects, like e-commerce, can push into the hundreds of thousands of dollars.

Frequently, a monthly retainer is involved, and in most – but not all – cases, the app’s intellectual property remains with the client, should they move to a different developer.

While experience, cost and intellectual property rights are important factors to consider before embarking on a software project, there’s a larger question that the author unfortunately doesn’t address: How do you ensure that you’re getting value for your dollar and controlling your risk exposure?

Ask the more important question:  Waterfall or Agile/Iterative/Incremental SDLC…

The choice of software development life cycle (SDLC) can literally make or break the success of your project. 

SDLCs largely fall into two camps:  Single-pass/phased delivery (aka ‘waterfall’) where activities are done in sequence like an assembly line, and iterative/incremental delivery (aka ‘agile’) where activities are done within short, cyclical periods called iterations.  The former exposes your investment to significant risks in cost, schedule and scope and keep you out of the app development until the very end; the latter protects your investment with frequent inspect/adapt checkpoints that involve you throughout the app development, and consequently reducing your risk exposure.

As illustrated in the graph below, the return-on-investment (ROI) for waterfall projects is a long tail that almost always exceeds the agreed upon up-front budget.  You can expect delays and disappointments as your supposedly in-the-can app begins to wander off schedule within the first two weeks of development.  In contrast, the ROI for agile projects is realized much more quickly by breaking development into working increments delivered on a regular basis, eg. every 1–2 weeks.  Schedules, features and costs are continually negotiated throughout the project, giving you much more control over what goes into the final product.

(In upcoming posts I will distill the reasons why waterfall projects are almost always prone to failures)

 Agile_waterfall_roi

Irrespective of whether you go with a firm that’s customizing a 60% done app or going completely from scratch, you should give preference to a team that delivers working, testable increments of your app every 1–2 weeks.  Additionally, you should expect to work closely with your contractor, helping to set plans and priorities for the features you want to go into your app and to give approval to each increment before starting the next.

Your contractor, if they are truly capable to work this way, should only bill you for increments that you have approved, and those increments should be fully tested.  For most apps, expect to pay for 3–4 iterations minimum to get a basic application together – that’s 3–8 weeks.

Get your project assessed by a professional…

Custom software development can be a very risky proposition:  Not all firms apply discipline and rigor to their delivery practices which can delay your app and significantly impair your time-to-market.  When in doubt, consider getting professional guidance from a consultant who understands iterative/incremental software delivery and the best practices required on a developer team to make it happen.  There’s more that goes unseen when choosing a vendor that you need to be aware of to make an informed decision on who to award a contract.

To meet this need, I am currently developing an offering to provide customers who are pursuing custom application development an independent assessment of their prospective vendor’s practices and how it aligns with risk exposure and opportunity for success, along with suitability of the customer to work in a manner that will increase and optimize the return on their investment.  Armed with cost-effective knowledge, business owners and managers can make an informed decision about the suitability of a firm to meet their needs and time-to-market.

If this sounds interesting to you or someone you know, please don’t hesitate to reach out to me via my blog.  I will be providing more information on this offering as it is completed for the New Year.

By Chris R. Chapman at October 06, 2010 22:01
Filed Under: software development, better practices, asp.net

Wow – I saw this tweet on my feed today:

Scottgu_nupack

And immediately hopped over to ScottGu’s blog for this:  Announcing NuPack, ASP.NET MVC 3 Beta, and WebMatrix Beta 2

So much good stuff all in one post!  NuPack, the OSS project for integrating 3rd party libraries into your code, the Model View Controller update for ASP.NET and the WebMatrix deployment utility.  We are finally entering a golden era for building and deploying web applications without the arduous hassles we’ve had to contend with for so long.  But how cool is it that NuPack is going to ship with Visual Studio?  WOW!

Check out Scott’s blog for details and his links to Hanselman’s, Simser’s, Haack’s and Ebbo’s posts.  A goldmine of information to take your projects to the next level.

By Chris R. Chapman at December 01, 2009 03:35
Filed Under: agile, better practices, book reviews, scrum, skills, software development

I recently came across a Nov. 25/09 post on Davy Brion’s blog, The Inquisitive Coder, that enumerates his recommended reading list for software developers who are wanting to step up their game.  This is a common theme on coding blogs, and there have been literally a galaxy of postings with some great and not so great recommendations guaranteed to perplex and flummox the average coder.

The implied line with all of these articles is that you ignore these tomes at your peril – you just won’t get to the “A” levels without them.

I like how Brion has broken his recommendations into three strata according to developer experience:  newbie, sophomore and grizzled veteran.  Well, sort of.  I mean, learning agile/iterative/lean software development really should occur at the start of your career as you’re going to have to unlearn the BDUF/waterfall crap that was loaded into your head by your CS/SoftEng profs who last “delivered” software (if at all) when 8–bit CPUs were da bomb.

What I don’t like is the complexity of some of the volumes that Brion shows – some of them are just so dense as to be inaccessible and not immediately applicable, eg. Eric Evans’ Domain-Driven Design.

Read/Master These Books First

If you want to get immediate benefits, try this shorter reading list:

  1. The Pragmatic Programmer:  From Journeyman to Master (Hunt & Thomas)
  2. Pragmatic Unit Testing in Java/C# (Hunt & Thomas)
  3. Refactoring:  Improving the Design of Existing Code (Fowler)
  4. Practices of an Agile Developer (Subramaniam & Hunt)
  5. Agile Software Development with Scrum (Schwaber & Beedle)

These books will help you begin to develop good habits – and in some places, possibly fired for wanting to implement.  That’s ok, because you don’t want to waste your life there, anyway. ;-)  It should take you 6–12 months to get through these and really internalize the practices and make them second nature.  I’ve recommended #5 because, as I mention above, you should get exposure to agile practices like Scrum sooner rather than later.

Read/Master These Books Next

You’ve got a couple of years under your belt and have seen the good, the bad and the ugly in the industry.  You’ve likely been on some bad projects and you’re beginning to question the wisdom of your chosen career path.  Take solace in these books to notch your game up further:

  1. Design Patterns (Gang of Four – Gamma, Helm, Johnson, Vlissides) – Alternatively, any book that explains patterns in your language of choice will help you “grok” them.
  2. Clean Code: A Handbook of Agile Software Craftsmanship (Robert “Uncle Bob” C. Martin)
  3. Agile Estimating and Planning (Cohn)

By the time you get through these (another 6–12 months) you will be truly cynical about the state of the industry, as well you should.  But you’re not wanting to be a “mort” or a “501” kinda coder – you’re wanting more.  So, you should supplement the above list with these titles:

  1. Death March 2nd Edition (Yourdon)
  2. The Mythical Man-Month (Brooks Jr.)
  3. Agile Project Management with Scrum (Schwaber)

These titles will give you the intellectual “legs” to position your strategies and arguments (yes, arguments) for implementing best practices with peers and managers.

Ongoing Professional Development

After you’ve reached your fifth or sixth year in the industry, you should have a pretty good idea about who you are professionally and where you think you’re headed:  Leadership, Consulting, Management.  Depending on your path, different books will influence your thinking.  You will likely be wanting to show what you’re capable of – perhaps in a new role or firm.  Some of these titles will help:

  1. Fearless Change:  Patterns for Introducing New Ideas (Manns & Rising)
  2. Agile & Iterative Development:  A Manager’s Guide (Larman)
  3. Implementing Lean Software Development:  From Concept to Cash (Poppendieck)

Conclusion:  Just Do It

In my experience, not very many folks who have a lot of “paper” experience have actually ready many of these books.  They’ve heard of them, but never read them or applied their lessons.  I’ve come across consultants who are really smart and with scads of experience who have yet to write a single unit test – or worse, think that a tool can do it all for them.  Common sense ain’t so common.

If you master 60% of the above list, you will be a better coder and professional than 3/4 of the people you’ll come across over your career.  It will take time, some personal commitment and in some cases risk – but it will be immediately worth it.  Follow the advice of Ken Schwaber (co-creator of Scrum) who urged attendees at a conference to actively begin improving their software delivery experience by implementing agile techniques by getting out there and doing it:  “Don’t procrastinate; do something – no matter how small.” 

 

By Chris R. Chapman at November 11, 2009 14:42
Filed Under: .net, asp.net, better practices, moss, sharepoint, software development

A quick reminder:  Say you have a SharePoint Survey List in a site that you want to populate using a console application.  Further, say that said Survey List has an Event Receiver attached to it that needs to pick up settings from the web.config file for the host web app – let’s say a connection string.

You run your console application and notice that nothing is happening – well, something is happening, just not what you intended.  A quick look in the Event Log reveals a bizarre error indicating that an object reference isn’t instantiated and it appears to be originating several lines of code before you make a call to the ConfigurationManager thus:

_connectionString = ConfigurationManager.ConnectionStrings[SQL_CONNECTION_STRING_NAME].ConnectionString;

The line that that is generating the error has nothing whatsoever to do with this line.  It is a puzzling sort of puzzle.

You decide to check first principles and see if you can trigger the event receiver by hitting the list in the browser.  Yup:  Works fine.  So what gives?

Then you remember:  Your console app isn’t running in the same context as the browser app.  Of course it can’t find the <connectionStrings> element – it doesn’t exist as far as it’s concerned.  The called code in the Event Receiver is running blind!

<foreheadSlap> Simply add a {nameOfConsoleApp}.exe.config file local to the console .exe file and stash the configuration settings from the web.config that the called code needs to find. </foreheadSlap>

I knew this, you know.  I was just not thinking clearly while debugging.

By Chris R. Chapman at October 22, 2009 06:05
Filed Under: hacks, moss, software development, wss30

Earlier today, I was working on a custom survey list event receiver that ports results into a SQL database table when I noticed some peculiar behaviour:  Every time I added an entry to the survey, two duplicate rows were added to the SQL table.

Poking around the web, I see that this is indeed a common issue – David Birin captured the problem (and a solution) quite succintly on his blog in his January 2009 entry.  As he notes, the root of the problem is that if you have your event receiver deployed as a Feature (I did) and then create a template of a targeted list (you bet I did that) then the event receiver registrations are “baked in” to the template definition.

Now, when you create a list based on this template in a site that has the same event receiver Features enabled, you now are running each event handler twice.  As you repeat this process, you register more event receivers and things get out of hand geometrically.

NOT GOOD.

A Hack for a Solution

David’s solution is to add in some custom code that loops through the event receivers and deletes them individually.  While this is robust for future-proofing, I wanted an easier way so that I could get back to coding.  Here’s what I did:

  1. First, I went to the List Template Gallery for my Site Collection and saved the offending list template to my C:\ drive and renamed the extension from “.stp” to “.cab”
  2. Next, I opened up the .cab file and extracted the manifest.xml file within and tossed it into Visual Studio where I cleaned it up with an Edit -> Advanced -> Format Document
  3. I located the <Receivers> element and removed each <Receiver> child element.
  4. I changed the <TemplateTitle> to reflect the new version, eg. “My Survey V4”
  5. I made similar changes to the <Form> and <WebPart> element URL attributes, eg. “Lists/My Survey V4/DispForm.aspx”
  6. Next, I saved this file and then used MAKECAB.EXE to package it up (comes with the Windows SDK) and renamed the extension from “.cab” to “.stp”
  7. I opened up a browser on my test server, navigated to the List Template Gallery and uploaded my revised template and created a list from it.
  8. Presto!  The ItemAdded event was only firing once as it should.

Hope this helps anyone encountering the same issue – it’s a quick-fix which helps avoid the ground-zero for the issue which is building a template of a list while the event receiver feature that targets that list is enabled.

About Me

I am a Toronto-based software consultant specializing in SharePoint, .NET technologies and agile/iterative/lean software project management practices.

I am also a former Microsoft Consulting Services (MCS) Consultant with experience providing enterprise customers with subject matter expertise for planning and deploying SharePoint as well as .NET application development best practices.  I am MCAD certified (2006) and earned my Professional Scrum Master I certification in late September 2010, having previously earned my Certified Scrum Master certification in 2006. (What's the difference?)