Can a Fish Use a Bicycle?

 Can a Fish Use a Bicycle?

This post will appear in the Jan/Dec issue of CODE Magazine….

A few months ago, my friend and CODE Magazine contributor Ted Neward posted a statement on Twitter repeating something said by Billy Hollis: “Agile is treating the symptoms, not the disease”. This flame bait drew a number of responses that Ted later replied to on his blog (

From Ted’s blog we learned the origins of Billy’s statement. Billy was lamenting the complexities of the “stack” of tools we use when developing applications in .NET today. The number of technologies we use is staggering: SQL, MVC, EF, LINQ, WPF, WCF, MEF… and so on. I agree-whole heartedly that the stack of tools is complex and very difficult for developers to keep a handle on.

The blog post described how Microsoft and other companies moved from selling to “long tail” i.e., small development shops, into the “enterprise” space. This shift from small to large has left small shops in a difficult situation. Ted mentions in his blog post that not long ago, it was possible to build software with one or two developers. He asks “What chance do these developers have today?” Then he throws out the non sequitur (and I paraphrase at a distance here) “Agile development does not solve this problem.” And you know what? He is right. Agile does not solve this problem because agile has nothing to do with it. This statement in its radical context shift made me think of this statement:

“A woman needs a man like a fish needs a bicycle.”

This is a statement made by Irina Dunn and popularized by Gloria Steinem during the women’s movement; basically, it means that women are not dependant on men. Just like women and men, agile development and toolsets are unrelated processes.

I am going to illustrate this point with the basic values of the Agile Manifesto (

· Individuals and interactions over processes and tools

· Working software over comprehensive documentation

· Customer collaboration over contract negotiation

· Responding to change over following a plan

Where do you see any mention of specific tools? In fact, the first line states individuals and interactions OVER processes and tools.

Agile is all about customer collaboration and building software not toolsets or specific techniques. If you drill down into the principles, you will see things like this:

· Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

· Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

· The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

· At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

These are just four of twelve principles. You will not see any details about specific tools or techniques. It is all about philosophy and how development teams interact with customers and each other and how they strive to build quality software. I will continue with some of my own questions to further illustrate my point:

· Can I do Agile development using Access?

· Can I do Agile development using FileMaker Pro?

· Can I do Agile development using SharePoint?

· Can I do Agile development using Visual FoxPro?

· Can I do Agile development using an assembly language?

The answer to all of these questions is YES. You can do agile development in any tool you choose because it does not pre-suppose any specific tool or technique. Another very valid point that Billy makes is that there are a lot of agile zealots that say if you are not doing/using “insert nouveau idea here” you are not doing “it” right. Simply put, those zealots need to learn and implement a little pragmatism in their discussions of agile. Are some tools or techniques better suited to the agile style of development? Yes, there are better tools, but your definition of better may be radically different than mine.

In summary, agile does nothing to address the complexity of today’s modern toolset. We will always be faced with an ever-growing list of tools and techniques we use. Agile is a process, plain and simple. In my next editorial, I will illustrate some ideas you can use to make your life simpler in tackling the “stack.”

Posted in Uncategorized | Leave a comment

Comments Suspended

Because of spam bot whackness I have turned off comments.

Posted in Uncategorized | Leave a comment

Move The Chair


Last Sunday I took my family to Red Robin (a family style restaurant) after church. I requested a table with a high chair for my  3.5 yr old son. Upon bringing this high chair the hostess simply moved an adult chair to the side and put the high chair in its place. (See Image)

This is where the fun began…

For the next hour or so I watched countless customers, servers and managers limbo their way between these two chairs. A lot of them did it repeatedly, some even carrying trays full of drinks and/or food. Finally I provided evidence to to my family that I am 100% full on geek. I got excited about the insight that this little experience game me (to the point of taking pictures)

I was simply amazed that people would allow this “friction to continue” It was a simple problem in this case. Move the chair!

I find it interesting that it’s built into our DNA incur friction in our lives without really addressing it. In real life its called denial. I know the chair was not that big a deal but it did open my eyes to our basic nature. Our basic nature follows through to software development as well.

The example of the misplaced chair provides some interesting parallels when it comes to technical debt (which is a cause of software development friction) We all have technical debt in our applications and it’s in our nature to shimmy, shuffle, limbo, mambo, and shake around these issues  whenever possible. It takes a constant vigilance to address technical debt. We must be active in our quest to remove technical debt. We must take the time to do two things:

  •     Recognize the debt. In our case: The chair.
  •     Remove the debt: In our case: Move the chair.

That’s it for this blog post. Just a simple observation brought to you by the staff and management of Red Robin :)

Posted in Uncategorized | 8 Comments

Silverlight Frankenstein

Frank2 For the last 6 months I have been working on a massive call center application that uses JavaScript heavily to provide a rich client experience. While working on this application a feature request was made that threw me for a loop. The requirement was that should the users browser die or lock up their session state would need to be recoverable, meaning when the browser was restarted  we would need to recover state. With a little head scratching and soul searching I came up with this idea:

“Why not user Silverlight, Jquery, JSON and .NET Isolated Storage to persist client information on the browser. It’s Alive!!!!”

I then went to work to create this monster.

Constructing a Monster

1. Create a new Silverlight Application with the test site included.  Initially this application will have a visual representation. You will be changing this application to a  “headless” version later.

2. Add a new class to your application. Lets  call that class Frank.

3. Add a reference (and appropriate using statement) to System.Windows.Browser to your Silverlight Application. System.Windows.Browser is the assembly used to integrate Silverlight with its host application.

4. Now add a function called wakeUp to your Frank class. Decorate wakeUp with the [ScriptableMember] attribute.

public string wakeUp(string input)
return input + System.Guid.NewGuid().ToString();

5. The next step is to expose your Frank class to your browser by registering it it with the Silverlight plugin. Registering classes is done in the Page.xaml.cs file.

6. Open the Page.xaml.cs file and add a reference (and appropriate using statement) to the System.Windows.Browser assembly.

7. Modify the constructor of the Page class adding the following code:

public Page()
HtmlPage.RegisterScriptableObject("frank",new Frank());

 8. Now your Silverlight Frankenstein is exposed to your browser’s scripting code. Now lets go to the browser and wake up the monster.


Waking Up the Monster



Our preferred method of working with the DOM and JavaScript is to use jQuery. jQuery found at is a very useful library that takes the pain away from working with client side applications.

Along with jQuery we use the JSON library to serialize and de-serialize JavaScript objects. the JSON library can be found at

Now lets go to work and call our monster from our JavaScript application.

Important Step:

Before you begin this exercise modify the <object> tag in the HTML page created when you started the silverlight application. You need to add an ID attribute to that tag. Your Silverlight tag should look like:

<object id="frank" data="data:application/x-silverlight-2," type="application/x-silverlight-2" width="100%" height="100%">
<param name="source" value="ClientBin/SilverlightFrankenstein.xap"/>
<param name="onerror" value="onSilverlightError" />
<param name="background" value="blue" />
<param name="minRuntimeVersion" value="2.0.31005.0" />
<param name="autoUpgrade" value="true" />
<a href="" style="text-decoration: none;">
<img src="" alt="Get Microsoft Silverlight" style="border-style: none"/>

 Now you can proceed to add the code to talk to your Silverlight application.

1. Add the latest and greatest version of jQuery to your web application.

2. Add the latest and greatest version of JSON to your web application.

3. Add a new Jscript file to your application. call it Frank.main.js. This file will contain your custom JavaScript code.

4. In the .html page generated for your Silverlight application add script references to jQuery, JSON and your Frank.main.js files.

5. Add a script tag to your html page to launch your jQuery application. Your code should look like the following snippet:

<script src="Scripts/jquery-1.2.6.js" type="text/javascript"></script>
<script src="Scripts/json2.js" type="text/javascript"></script>
<script src="Scripts/Frank.Main.js" type="text/javascript"></script>
<script type="text/javascript">

5. Add a function called main to the Frank.main.js file.

6. Now you can add code to call your Frank class. The first step is to create a function that will return a reference to your referenced frank class. The following JavaScript function does just that:

function getFrank() {
var returnValue = document.getElementById("frank").content.frank;
return returnValue;

7. You need to carefully examine that function. It does the following:

  a) Grabs a handle to the Silverlight control via document.getElementByID(“frank”)

  b) Bores into the Silverlight control’s content property and grabs a reference to  

     the frank variable you referenced in the first exercise.

8. Now you can call your wakeUp() method as follows:



Now For Something Useful

Now that you have a basic understanding of how to call C# code from your web pages you can open up your horizons and do something useful.


Using the Visual Studio Debugger

One of the more interesting things I came up with was integrating the Visual Studio debugger into my JavaScript applications. Rather than debugging variables via the good old alert() function why not spit information to the debugger?


The following code blocks show how you can spit data from your JavaScript application into the Visual Studio debugger.

public void writeline(string output)


function debuggerTest() {
for (i=0; i<100; i++) {


Calculating Ages

Lets face it JavaScript date support,especially when it comes to date calculations sucks.Date support in the .NET framework is much better. Especially when you use the “wrapped up” code found in the Microsoft.VisualBasic namespace.

The following code calculates a person’s age (in years) using the DateDiff() function found in the Microsoft.VisualBasic assembly. To use this code add a reference to the Microsoft.VisualBasic assembly to your Silverlight Application.

The following code snippets show how to calculate an age from a given date:

public long getAge(string inputDate)
long returnValue = -1;
var dateValue = System.Convert.ToDateTime(inputDate);
returnValue = Microsoft.VisualBasic.DateAndTime.DateDiff(Microsoft.VisualBasic.DateInterval.Year,
catch (Exception)
returnValue = -2;
return returnValue;






Final Frankenstein

The original purpose of this exercise is to be able to save and restore form state from a client browser session. This is where a good plan comes together. Saving state involves a number of moving parts.

0. Create a simple HTML form with some fields.

1. Create an array of the objects representing the data from a set of web input fields.

2. Serialize the array into a string using JSON (JavaScript Object Notation)

3. Pass that string to Silverlight and save it to disk using Silverlight’s Isolated storage mechanism.

4. Retrieve the JSON data from Isolated Storage and de-serialize it back to an array.

5. Re-populate the controls on the form from the array.


Simple HTML

This code is about the simplest HTML form you could create. Two text fields and two buttons. The two buttons will be used to save and restore state (we save and restore state via a timer).

<label>Last Name</label><input type="text" id="txtLastname"/><br />
<label>First Name</label><input type="text" id="txtFirstName"/><br />

<input id="cmdSaveState" type="button" value="Save State" />
<input id="cmdRestoreState" type="button" value="Restore State" />

The following code wires up the buttons to functions to save and restore state:


Gathering and Restoring Data

The next set of code creates an array of objects representing page content. It also serializes the content to a JSON string using the JSON library added to your project earlier.

function getContentAsJSON() {
var inputControls = $(":input").not(":button").not(".ignorestate");
var controlData = Array();
for (i = 0; i < inputControls.length; i++) {
controlData.push({ ID: inputControls[i].id, Value: inputControls[i].value, Type: inputControls[i].type });
var jsondata = JSON.stringify(controlData);
return jsondata;

 Note: this code gathers up data for all controls except for buttons and ones that have the .ignorestate style attached to them.

The next set of code is the converse of the prior. It takes a JSON string and de-serializes it back to an array and repopulates control values based on its content.

function restoreControlState(controlDataString) {
if (controlDataString.length > 0) {
var controlData = JSON.parse(controlDataString);
for (i = 0; i < controlData.length; i++) {
$("#" + controlData[i].ID).val(controlData[i].Value);


Saving and Restoring State

Now you need a mechanism for storing and retrieving the data to client workstation. To do this, you will use the Isolated Storage mechanisms contained in the Silverlight framework. Isolated storage is a data storage mechanism available in both standard .NET and Silverlight applications. Isolated storage is a set of APIs used to read and write files to a virtual file system managed by the .NET framework. Silverlight applications have a default 1MB (yes 1MB) of storage available to them for reading and writing files.  To use the following code examples import System.IO and System.IO.IsolatedStorage to your applications:

 The first is used to preserve state. It  does the following:

1.  Opens the “virtual file system” presented by IsolatedStorage

2. Checks to see if the “sessioncontents.txt”  file exists  . If so it deletes it.

3. Creates a file stream to write content to.

4. Uses a standard StreamWriter to push content to the file.

5. Flushes the buffer and closes the file handle

public void saveState(string stateString)
//yes this is a MAGIC string for a demo
var contentFileName = "sessionContents.txt";
var userStore = IsolatedStorageFile.GetUserStoreForApplication();

//whack the file if it exists
if (userStore.FileExists(contentFileName))
var file = userStore.CreateFile(contentFileName);
var writer = new StreamWriter(file);

The next step is to return the data from IsolatedStorage. It does the converse:

1.  Opens the “virtual file system” presented by IsolatedStorage

2. Checks to see if the “sessioncontents.txt”  file exists  . If so it opens it.

3. Creates a file stream to read content from.

4. Uses a standard StreamReader to read content from the file.

5. Closes the file handle

6 Returns the string to the caller.

public string getState()
var returnValue = "";
//yes this is a MAGIC string for a demo
var contentFileName = "sessionContents.txt";
var userStore = IsolatedStorageFile.GetUserStoreForApplication();

//whack the file if it exists
if (userStore.FileExists(contentFileName))
var file = userStore.OpenFile(contentFileName,FileMode.Open,FileAccess.Read );
var reader = new StreamReader(file);
returnValue = reader.ReadToEnd();

return returnValue;


Now all you need is the small glue code to put it all together:

function saveState() {

function restoreState() {


That’s all you need to save and restore state from a HTML form


Removing the Head


 Finally you can go “remove the head” from your Silverlight application. this is rather simple. To remove the head from your Silverlight application you simply go to the Page.xaml file and change the size attributes to zero. Now you have a “headless” frankenstein for your fun and enjoyment.

<UserControl x:Class="SilverlightFrankenstein.Page"
Width="0" Height="0">
<Grid x:Name="LayoutRoot" Background="White">



 I hope you have enjoyed this post. You can find this code at

Posted in Uncategorized | 9 Comments

10,000 Hours to Graceland

Lets take a look at some old code:


I know what you may be thinking. Why the heck are we looking at 20 yr old procedural code. Well…what you just witnessed was the first paid code written by a greenhorn application developer. For the curious that code was written in  dBaseIII+ hosted on a PC Limited (now Dell) server running Novell 2.0a.

When you take a look at that code and the application in its entirety you will find an application riddled with poor coding constructs, amateurish coding principles (use of publics for example) and an application that misses fundamental features available to it from its core language (xBase). Basically what you will find code written by a wet behind the ears application developer, fresh out of college, and unleashed on a property management company to write an application to be known as : “The Hot Tub Management System”.

When looking at that code you will see the type of code written by a junior application developer. That junior developer started his career with  with 1.5 years of college education and a burning desire to write code for a living. 

The learning didn’t stop there. The programmer that wrote that code went on to gain more education and more importantly more application development experience. That programmer moved from the property management company to a large hotel/resort where he was applied his craft for 18 months as an application developer/network admin. Eventually that programmer left small town Bend, Oregon for the bright lights and big city life in Seattle, Washington.

It’s in Seattle where that developer went from being the lone wolf developer  in a small company to to being a member of a team of developers in a somewhat larger company. When he was hired the developer told he would be joining a group of the best FoxPro developers assembled in the Seattle area and would need to rise to the challenge. That is exactly what he did.

It was at that company that the developer really came into his own. The developers on that team were a competitive and very talented group of developers. The primary concern of that group of developers was to create the correct solutions for the company and do it right the 1st time.  By the time the developer left that company he was writing some of the best code of his life, creating high performance and feature rich applications and finally re-caught the writing bug and was drafting articles for the magazine Data Based Advisor.  At that point the developer had been writing code (including college) for nearly 5 years. Which leads me back to the title of my post: 10,000 hours to Graceland.

The normal employee works approximately 2,000 hours a year (40 hours * 50 weeks). When you factor in 5 years of work that comes out to 10,000 hours. This is the minimum amount of time it takes to master a craft. 

This epiphany didn’t come straight from my gray matter it came from a book I picked up earlier this month called Outliers, by Malcolm Gladwell. In general I am not a big fan of overhyped books like Outliers. I couldn’t have been more wrong about this book. I found that this book was much like Freakanomics which challenged basic assumptions we have as a society.

Malcolm starts this book with an analysis of a championship team  of young Canadian hockey players. People were attempting to figure out why some hockey players seem to excel while others to not. When analyzed a startling conclusion was made: Kids with birth dates falling in a specific range seemed to play better than the others.  As Mars Blackmon would say “Gotta be the stars!” People born under a specific sign are better hockey players right ? Nope… Basically it boiled down to this. The kids falling in a certain birthday range were allowed to start playing hockey earlier than the other kids. Basically they got a head start by 6months to a year. Now these kids did have talent…but talent nurtured earlier has a better chance of success right?

This was making sense. It got clearer as the book progressed. Gladwell wrote about two of the most regarded software developers of our day. The two Bills. Bill Gates and Bill Joy. One thing that Bill Gates and Bill Joy share was the fact that they had access to computers at a very early age and spent countless waking hours working on these machines. By the time real opportunities presented themselves in there 20’s both of these me had the requisite 10,000 hours under there belts and were able to apply their craft to great advantage. Once again it was not just the amount of time they spent, they did have talent by the truck load, but that talent was nurtured from an early age to yield some some real talent.

With all the talk of Software Craftsmanship these days we must never forget that it takes a lot of time to master new skills. I moved from Visual FoxPro to Visual Studio .NET in 2001 it took me a few years to really master a  new way of development. It didn’t take me quite 10,000 hours, as I had a lot of experience in object oriented code and frameworks, but it did take a certain amount of time in the trenhes to master this new set of concepts.

What is true in Software Craftsmanship is true life’s  other endeavors as well.  There is an old saying in poker:

“It takes 15 minutes to learn the game and a lifetime to master”

I completely relate to this statement. Around 10 years ago I sat down for my first real poker game in a casino. I was scared out of my wits but I held my own. I lost of course but I had caught the poker bug. I spent literally hundreds of hours grinding learning how to play this game effectively.  Do I consider myself a master? Heck now I am no Daniel Negraneu. But I can definitely hold my own with the best of em in the casinos in Vegas. I feel this way now when it comes to Agile and XP development processes.

In 2000 I found a book called Extreme Programming Explained. This book seemed to be what I had been looking for when it came to developing software. At its core it talked about working directly with customers to develop exactly what they wanted correctly the 1st time. Kinda like that team I was on early in my career. Over the ensuing years I spent time attempting to implement these with customers and in my own practices. It seemed to me like I had started over once again as a web behind the ears programmer.  I didn’t have a lot of luck  getting clients to adopt these principles but I did keep growing my own personal knowledge. Flash forward to October 2007 in Austin Texas. I attended my first ALT NET Conference it was here that I spent time learning more about implementing agile practices in my company and with my clients. I was going to master this if it killed me. Over the last year and a half I have been putting in my time towards my 10,000 hours to Graceland. I have been fortunate that I have the opportunity to be mentored by, dialog with and become friends with a number of agile developers I respect. It’s this dialog that has been most important to my mastery of this stuff. Like poker I am not a master but I am beginning to “hold my own” with these folks. I am glad they have spent the time sharing their 10,000 hours to Graceland with me.

One other thing that did for me was to give me another level of perspective when dealing with people new to agile development practices. I am an agile teacher and need to take into account that it takes a number of hours practicing thus stuff before you can see the real benefit. A lot of developers will take a surface glance at a subject like Test Driven Design and rule it out as a a waste  of time. We all have heard the question “Why do I need to waste my time with this?”. We need to address these questions with patience and understanding. We need to relate back to ourselves as greenhorn wet behind the ears developers. We need to remember that it took us 10,000 hours to get here and it will take people new to agile 10,000 hours to find their Graceland.

Posted in Uncategorized | 3 Comments