1. Formulate a hypothesis AKA have a testable opinion. I am nothing if not opinionated.
2. Design a test. ie. Let's move this thing here, and that then there. List independent variables, dependent variables, covariates, expected benefits AKA $BLING$ Make an assumption that a certain segment of my customer base is representative (enough) of my full customer base.
3. Code up something that only works for that segment... maybe it even only half works. Fuck any kind of automated testing unless it makes this step faster.
4. Test what's been written and decide if it's "Good Enough" to get us reliable results.
5. Release the test to production
6. Once the test is over, delete all the code from production.

• Only run this on non-mobile browsers
• Only run in Safari
• Only run if this user came from page "http://fookyou.com/fookme"

1. Your test is probably too damn big and testing more than isolated changes. (Notice the italics. #GuidelinesNotSteadfastRules)
2. Remember step three? You wrote that code in a shitty unsustainable manner... BUT. You'll be able to rationalize taking the time to refactor after this. Lemme tell you why.

1. Red- Think about what you're doing enough to understand how you can test it.
2. Green- Find out it makes you money and delete the code.
3. Refactor- Write the code well and in a disciplined manner knowing that you've proven it's worth the time.

• A data model that integrates logging- I step through exactly what my user did.
• Optimizations become views of data- Is calculating your users state too slow? Need SQL? No problem. Run through all of the events and store them in OR tables for fast querying. Think of it as a cache. When a new event is added that invalidates the cache, play that event against your SQL tables as well and you're good to go.
• Migrations maybe easier(?)- Your conceptual or data model change? No problem, blow away those SQL tables and build new ones based off of the events.
• A data model that can handle multiple changes to the same data at the same time and no information loss. Because we're just collecting events, the UI may not show the data, but it's still in the system and able to be retrieved if need be.
• Undo supported by default- Make a change but want to take it back? Go back to a previous moment in time demarcated by... EVENTS. :)

• I wanted to understand Javascript and just didn't see how using a "simpler version" (my own thoughts) would make my life easier in the long run.
• If I DID use an intermediate language, I wanted to be able to dump it at any time and not feel like I was forced to continue using it.
• Putting one more thing with bugs in between myself and my code seemed fool hardy.

• It's less verbose Javascript, not a different or simplified language.
• A couple of shortcuts that enable you to use list comprehensions rather than error prone for statements.
• CoffeeScript compiles to pretty awesome Javascript. I wouldn't have any concern dumping CoffeeScript at any time because of this. It would also have put some great conventions in my Javascript that I could follow.
• Eli Thompson is always right. (You should read his blog. He's smart: http://eli.eliandlyndi.com/)

• Heated arguments at work regarding how much TDD is enough and how little is too little. How do we find common ground?
• An acknowledgement of technical debt and a confusion about how to leverage it. How much debt is too much?
• Being labeled as pedantic and a zealot. Is a Zero-Defect Mindset ever worthwhile? When?
• Learning exercise in how we can gain concrete insights using our intuition in a methodical fashion. How can I communicate abstract ideas without concrete evidence in a rigorous manner?

This article represents my lessons learned from this exploration.

Making the Abstract Concrete

It was a normal day at work, myself and another co-worker were strongly and passionately arguing for the benefits of strict, pure, clean TDD against a couple of other equally passionate co-workers who were sold on the idea of everything in moderation. Having just completed a four month full time Agile immersion with an amazing albeit very idealistic consultant, his ideas about a zero-defect mindset and the idea that it was practically achievable were seductive. I had entertained my own idealistic fantasies for a while never really thinking they could or should be taken so seriously.

It was liberating. 

Also, it was isolating. Having these thoughts, and that excitement placed me on one extreme side of a continuum with many of my other teammates on the other side or somewhere in the middle, nearer to the side of limiting TDD in the name of practicality. Conversation after conversation, debate after debate, we ended in the same place, perhaps even galvanized a bit by the disagreement and a bit further from finding common ground.

I finally came to understand that regardless of what I knew to be right, everyone on my team had their own perception and their own knowledge of what was right as well. That's not sarcasm. In social interactions there are multiple realities and all of them need to be appreciated and considered valid enough to be worth understanding. 

How could I model my perception of reality in some sort of a concrete way that would enable me to make rigorous (albeit somewhat subjective) predictions? How could I ensure my mental model was at least self-consistent and work-able? Like self-respecting geek, I decided the best way to model uncertainty was to run thousands of simulations and projections of reality to see what lessons could be gleaned.

Finding Common Ground in a Common Purpose

The first decision I had to make was figuring out the underlying metric I would use to compare the two development methodologies. Having been just recently introduced to systems thinking and the Theory of Constraints, I thought a great start would be to use the value throughput of the companies. 

But what is value? When we speak of delivering value to our business customers what is it we are actually delivering? In discussions with my team, we decided that business value is best seen as the present day value of your company were it to be valued by an external party. For the purposes of the simulation, I assume the value delivered by completed stories to be equivalent to some randomly assigned numbers provided by a value distribution and assigned without regard for feature size. That's right, it means a feature that takes next to nothing to develop may create an enormous amount of value for the company.

For further assumptions and specifics of my model, read on.

• User Story- In this simulation, a User Story is the smallest unit of work that the Product Development Team can work on that provides the slightest bit of business value. They also have an associated size.
• Business Customers- Generates a random set of randomly sized (to a discrete distribution) stories each iteration. Their value and size are also randomly assigned upon creation.
• Product Backlog- Repository for all stories. New stories are all added as a top priority in the order delivered. Bugs are randomly dispersed into the Product Backlog when they are received. 
• Product Development Team- Anyone and everyone responsible for getting the release out the door. This includes programmers, testers, technical writers, etc., etc. The Product Development Team iterates over the Product Backlog and works to complete stories. They also are the ones deciding the cost of the various stories. Over time the speed of their work can go up if a range (minimum velocity and maximum velocity) > 1 is specified on construction. The function which controls the team's performance improvement is an "Experience Curve" as documented here: http://en.wikipedia.org/wiki/Experience_curve_effects Without getting too into it, this experience curve essentially models the decreasing cost of development over time.
• End Users- Who the Product Development Team releases to. Because the Product Development Team includes *everyone* needed to release the software, the End User may receive the software immediately afterwards. End Users discover bugs in the software. This is currently set to a constant rate per story per iteration. So if the defect rate is 1%, then a team with a hundred stories complete can expect to have, give or take, one story per iteration reenter the Product Backlog as a new Bug Story. The size of the Bug Story is randomly determined based upon a discrete bug size distribution. 
• Bug Story- A Bug Story is a story that is focused on fixing a defect in the software. These stories are unlike normal stories in that they have no real value for the team and thus don't improve throughput. A Bug Story actually represents more of an opportunity cost as valuable work could be done in its place if the Bug Story hadn't needed to be written.
• Support Team- Who the bugs are reported to. Currently only really used to track the total bug count. Could be used in the future to eliminate bugs due to "user error".

• Lowering the defect rate, even at the cost of reduced performance, results in higher value throughput in the long term. Lowering the defect rate in the short term however is hardly ever optimal.
• A higher defect rate results in a much higher spread of possible value throughput... in other words there's a higher variance in what you can expect in terms of value output from a product development team.
• Every development team has a point where the highest possible testing and quality rigor begins to outperform the less rigorous teams. The trick is identifying where this begins to happen for your particular company or project.

• How do we find common ground? Share our assumptions and make them explicit. Codify them so that they can't be conveniently shifted when the arguments get uncomfortable.
• How much debt is too much? I didn't model technical debt in terms of needed refactoring... just in terms of defect likelihood. Too much debt is so much that you spend most time paying maintenance costs than delivering value.
• Is a Zero-Defect Mindset ever worthwhile? When? Yes it is, when you have set a goal of a sufficiently large life time for your product.
• How can I communicate abstract ideas without concrete evidence in a rigorous manner? Hopefully I just did.

1. You know what an IoC container is.
2. You only use an IoC container to clean up your dependency injection.
3. You aren't writing prototypical, throw away code.
4. The system under question is not an ideal of perfection. It's just a realistic system where I can concretely show the product of applying this abstract idea.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

namespace Unite.UI
{
    /// <summary>
    /// Interaction logic for App.xaml
    /// </summary>
    public partial class App : Application
    {
        public App()
        {
            Startup += App_Startup;
        }

        void App_Startup(object sender, StartupEventArgs e)
        {
            var pluginFinder = new PluginFinder();
            var serviceProvider = new ServiceProvider(pluginFinder);
            var credentialCache = new CredentialCache(serviceProvider);
            var jobRunner = new AsyncJobRunner(this.Dispatcher);
            var gui = new GuiInteractionContext(credentialCache, jobRunner);
            var messagingService = new ServicesManager(serviceProvider);
            var contactRepository = new ContactRepository();
            var contactManager = new ContactManager(messagingService, contactRepository);
            var messageRepository = new MessageRepository();
            var codePaste = new CodePaste();
            var messageFormatter = new MessageFormatter(codePaste);

            var credentialManager = new CredentialManager(messagingService, gui);

            var messageManager = new MessageManager(messagingService, messageRepository, messageFormatter, jobRunner);

            var viewModel = new ViewModels.MainView(gui, contactManager, messageManager);
            var view = new Views.MainView(viewModel);
            view.Show();
        }
    }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

namespace Unite.UI
{
    /// <summary>
    /// Interaction logic for App.xaml
    /// </summary>
    public partial class App : Application
    {
        public App()
        {
            Startup += App_Startup;
        }

        void App_Startup(object sender, StartupEventArgs e)
        {
            var messagingPluginFinder = new MessagingPluginFinder();
            var messagingPlugInRepository = new MessagingPlugInRepository(messagingPluginFinder);
            var appropriatePlugInDetection = new DetectPlugInToUseBasedOnRecipientAddress(messagingPlugInRepository);
            var unifiedMessenger = new UnifiedMessenger(messagingPlugInRepository, appropriatePlugInDetection);
            
            var contactRepository = new ContactRepository();
            var contactQuery = new ContactQuery(unifiedMessenger, contactRepository);

            var messagingFiber = new AsyncFiber(this.Dispatcher);
            var credentialRepository = new MessagingAccountCredentialRepository(messagingPlugInRepository);
            var securityDialogService = new SecurityDialogService(credentialRepository, messagingFiber);

            var credentialManager = new CredentialAuthorizationController(unifiedMessenger, securityDialogService);

            var codePasteToUrlService = new CodePasteToUrlService();
            var automaticMessageFormatting = new AutoFormatCodePastesAsUrls(codePasteToUrlService);

            var messageRepository = new MessageRepository();
            var unifiedMessagingController = new UnifiedMessagingController(unifiedMessenger, messageRepository, automaticMessageFormatting, messagingFiber);

            var messagingViewModel = new MessagingViewModel(securityDialogService, contactQuery, unifiedMessagingController);
            var messagingWindow = new MessagingWindow(messagingViewModel);
           
            messagingWindow.Show();
        }
    }
}

"I believe that the time is ripe for significantly better documentation of programs, and that we can best achieve this by considering programs to be works of literature...

Let us change our traditional attitude to the construction of programs: Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do.

The practitioner of literate programming can be regarded as an essayist, whose main concern is with exposition and excellence of style. Such an author, with thesaurus in hand, chooses the names of variables carefully and explains what each variable means. He or she strives for a program that is comprehensible because its concepts have been introduced in an order that is best for human understanding, using a mixture of formal and informal methods that reinforce each other."

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

public static void BootstrapStructureMap()
        {
            // Initialize the static ObjectFactory container
            ObjectFactory.Initialize(x =>
            {
                var fiber = new AsyncFiber(Dispatcher.CurrentDispatcher);

                x.ForRequestedType<Views.MessagingWindow>().TheDefaultIsConcreteType<Views.MessagingWindow>();
                x.ForRequestedType<IUnifiedMessagingService>().CacheBy(InstanceScope.Singleton).TheDefaultIsConcreteType<UnifiedMessenger>();
                x.ForRequestedType<IContactService>().CacheBy(InstanceScope.Singleton).TheDefaultIsConcreteType<UnifiedMessenger>();
                x.ForRequestedType<IServiceProvider>().TheDefaultIsConcreteType<ServiceProvider>();
                x.ForRequestedType<IPluginFinder>().TheDefaultIsConcreteType<PluginFinder>();
                x.ForRequestedType<ICodePaste>().TheDefaultIsConcreteType<CodePasteToUrlService>();
                x.ForRequestedType<ICredentialCache>().CacheBy(InstanceScope.Singleton).TheDefaultIsConcreteType<MessagingAccountCredentialRepository>();
                x.ForRequestedType<IInteractionContext>().TheDefaultIsConcreteType<SecurityDialogService>();
                x.ForRequestedType<IMessageFormatter>().TheDefaultIsConcreteType<AutoFormatCodePastesAsUrls>();
                x.ForRequestedType<IFiber>().TheDefault.IsThis(fiber);
            });
        }

• The next(value) message that is passed the value that the user entered.
• The _learn_from_new_information(previous_value, current_value) method that trains our markov chain.
• The _make_best_guess(value) method that utilizes our trained markov chain to make an educated guess about the user's next entry.
• Last but not least, a simple set_guess_channel_to(channel) message that we can use to publish what we guessed and what the right guess actually was.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

var scoreboard_actor = function()
{
  this._values_entered_count = 0;
  this._correctly_guessed_value_count = 0;
};
scoreboard_actor.prototype.set_display_channel_to = function(channel)
{
  this._display_channel = channel;
};
scoreboard_actor.prototype.guessed = function(my_guess, correct_guess)
{
  this._values_entered_count = this._values_entered_count + 1;
  
  if(my_guess == correct_guess)
  {
    this._correctly_guessed_value_count = this._correctly_guessed_value_count + 1;
  }
  
  this._display_channel.accuracy_updated(this._correctly_guessed_value_count / this._values_entered_count);
  this._display_channel.previously_guessed_value_updated(my_guess);
};

1
2
3
4
5
6
7
8
9
10

var computer_guess_display = $('#computer_guess');
var computer_guess_accuracy_display = $('#computer_guess_accuracy');

my_user = new user_actor(computer_guess_display, computer_guess_accuracy_display);
var my_learner = new learning_actor();
var my_scoreboard = new scoreboard_actor();

my_user.send_guesses_to(my_learner);
my_learner.set_guess_channel_to(my_scoreboard);
my_scoreboard.set_display_channel_to(my_user);