Jonathan Starr's Blog

Scrum / Agile Development: A Renaissance of Culture Through the Eyes of Levi-Strauss

Jonathan Starr — Sat, 19 Jul 2008 23:47:38 GMT

On weekends, I tend to go off tangent, and this weekend is no exception. I started to read some of the works of Levi-Strauss, the structural anthropologist, and it occurred to me that many of the positive changes from Agile Development are not merely the result of greater business focus. Agile also develops culture in a field that is generally devoid of culture.

This can be a stabilizing factor for companies by

- Reducing turnover by empowering team members.
- Creating rituals, taboos, and totems that increase the significance of work.
- Increasing communication through these rituals to increase trust between team members.

Rituals of Agile Development

Stand Up Meetings (or Scrum Meeting)

In order to make the initial meeting for the day a bit of fun, the meeting is time-boxed to fifteen (15) minutes. And to emphasize the importance of keeping this meeting short, attendees stand for the meeting (like a football huddle?). To show attendance is important, team members cannot allow another member attend the meetings by proxy for them. Finally, to make the Stand Up as much of a ritual as possible, it is generally done at the same time and same place every day.

There are many other rituals that are sometimes adopted during Stand Up meetings. Some teams rotate the facilitator role for Stand Up. Likewise, some teams have a special time keeper role to keep the meetings short. I suspect the richer the traditions for stand up, the more effective they may be for team building and enculturation.

A few other thoughts from an anthropology perspective: Stand Up meetings are conducted around back log charts/ blockage charts that are highly visible charts with information about the project posted on 3 x 5 index cards prioritized. It reminded of the Code of Hammurabi - the best way to may things important is by making them highly visible.

For more information, you may want to consult Martin Fowler's take here.

Red Light - Green Light - Refactor

When pair programming is used in Agile, typically a game of "Red Light - Green Light - Refactor" is played. That is, one member of the pair fashions a test that specifies a requirement for the user story the pair is working on. When a satisfactory test is fashioned and it fails, the Red Light part of the game is complete. Then the other member of the pair will write the code to make the test pass. This is the "Green Light" part of the game. Finally, to make the code work with accepted architecture requirements, or to make the card more maintainable or more performant, the first member refactors the code so that it still passes unit tests. This is the final phase of this round game, and the members switch roles for the next round.

This game is not the zero sum game we Westerners normally engage in. Instead, because the game has no losers, and only winners, it is ,according to Levi-Strauss, a ritual.

Personally, I have paired with four different individuals over the past six months, and I developed special relationships with each one partly because of the ritual nature of this practice. It has been very satisfying, and not just on an intellectual level to do so (and many times illuminating as I have had some 'perfectionist' coding partners).

Agile Planning Games

When it is difficult to estimate the scope of new requirements (or user stories) the Scrum team will sometimes play a game to perform the estimate. Cards with Fibonacci numbers of hours (1, 2, 3, 5, 8 , 13, 21, etc.) are distributed to each team member. Each member uses one of these cards to indicate the number of required hours to complete the requirement, and when there is disagreement, members justify their estimations with specific reasoning so that a general estimate can be made.

This is another game that is, by its cooperative nature, another ritual of Agile Development.

Taboos of Agile Development

While many parts of agile development are flexible there are some parts that are absolutely fixed.

The taboos of Agile Development are in my mind:

1. Thou shall not miss stand up and iteration planning.

If these meetings are skipped, then work is not done in the proper order, and the team does not properly communicate progress to management.

2. Thou shall not write code without unit tests.

While agile teams have some control over length of iteration and scope of requirements for iterations, quality requirements are fixed. All code components require covering unit tests so that code changes are justified, and coding errors can be easily located and fixed.

This taboo has many positive consequences for the business - the largest being the minimization of re-work, which is very expensive.

A side benefit is when interdisciplinary teams work together, and they publish unit tests with their work, it makes integration easier. Consumers of services know how to use services provided, as examples are given. And they have ways to test the code, so they can easily communicate problems.

Finally, when integration is made easier, diverse teams increase trust and harmony.

3. Thou shall not disrespect other team members.

Agile development is development based on a self-organizing team. If team members are disrespected the whole team suffers. Mutual respect is the cornerstone of Agile in my opinion as much as the failing test is the cornerstone of Test Driven Development.

4. YAGNI

While it's not a formal taboo in Agile Development, I hear it so often during my work, that I decided to give this concept some space.

"YAGNI" stands for "You Ain't Gonna Need It", and Agile generally provides the simplest solution for requirements. While the more complex solution may be more powerful and provide features developers imagine may be needed, the truth is that most of the time that is not the case.

"YAGNI" is a controversial topic for most programmers. But agile developers generally lean towards the KISS (Keep It Simple Stupid) solutions whenever possible.

Totemism in Agile Development

According to Levi-Strauss, "totemism is a code, a symbolic language whose purpose is to signify social differences. It is an instrument used by primitive populations for classification of social groups."

Agile development speaks generally of pigs and chickens.

A chicken and a pig are together when the chicken says, "Let's start a restaurant!".
The pig thinks it over and says, "What would we call this restaurant?".
The chicken says, "Ham n' Eggs!".
The pig says, "No thanks, I'd be committed, but you'd only be involved!".

[Schwaber and Beedle, 2001]

In agile development, most of the rituals are performed by pigs (the self organized team of developers and testers) without the chickens (that is without the product owner). This totemism is not a formal as it is in primitive cultures, but the social consequences are enforced.

Agile vs. Traditional Development, and Hot vs. Cold Cultures

According to Levi-Strauss, "hot" cultures are based on writing. They produce a great deal of work, but like hot steam engines, they produce a great deal of waste and entropy. Furthermore, the 'writers' in hot cultures tend to be higher in the social hierarchy than the non-writers.

Cold cultures are preliterate, and they tend to rely on rituals, taboo, and totemism to preserve order.

I think that traditional development is like most typical hot cultures. Decision making is made by a few individuals at the top of the social hierarchy. They do most of the record keeping, so they can easily justify their decisions whether or not they are correct.

Agile development, while it may be a hotter culture than traditional development in the sense that there may be more record keeping on the development process, spreads the management of the process to all of the team members. And its greater use of rituals, taboo, and totemism may be homeostatic functions that makes these teams more stable. I think it's more of a tepid culture (hot and cold) based on its mix of practices.

The Future Of Agile Development

Based on this analysis, I have the following questions... And I would love hear responses from you, the reader!

Question 1: Agile requires a structured meeting for the beginning of the work day, and for the start/end of iterations. Would providing an end of day work meeting serve any purpose? Or would that just be overkill?

Question 2: Are the rituals for Agile generally burdensome to you (if you are practicing it right now), or do they make your work more meaningful / enjoyable? Which rituals do you appreciate, and which ones serve little or no purpose to you?

Question 3: Do you think pair programming is a good idea? If you pair program, how often do you switch partners? What do you think is an ideal switch rate per year? What do you do if you find your coding partner less than ideal?

Question 4: What rituals do you think enable teams to learn the most during iterations? Are there more rituals you know about that may facilitate more learning? Perhaps a lessons learned section should be added to tear downs for iteration planning?

Question 5: Does your organization have a ritual to facilitate code reviews? I am struggling with this question, as most team members I know are somewhat defensive when it comes to sharing their code, even when it is produced by pair programming.

Happy coding! And thanks for reading,

Jonathan Starr

Hint for today - Install SQL Server 2008

Jonathan Starr — Wed, 25 Jun 2008 17:07:33 GMT

Even if your databases are from prior versions of SQL Server, you should download the new CTP for SQL Server 2008.

https://connect.microsoft.com/SQLServer/content/content.aspx?ContentID=5395

The new version's SQL Server Management Studio will connect to older versions of SQL Server databases and give you intellisense (almost as good as Red Gate's Sql Prompt!).

Hope this saves you some time,

Jonathan

Code Redundancy is NOT Bad - Part 2

Jonathan Starr — Mon, 23 Jun 2008 23:26:22 GMT

I got some responses from a post I made on Saturday, that troubled me. I really think it is important to code to an interface whenever possible - not only to give your application to flexibilty, but to give it testability as well. So I thought I might give you an example.

Say I have a class that depends on two other classes I have. In this example, Partitioner depends on SystemIOAdapter and MerchantRecordCounter.

using Interfaces;

namespace Program

{

public class Partitioner : IPartitioner

{

public void PartitionMerchants(ISystemIOAdapter io, IMerchantRecordCounter counter, string mappedPath, string partitionPath, int maximumCount)

{

// implementation details.

}

If the method PartitionMerchants had been written using class declarations instead of interfaces, than any test I would write for this method would be an integration test, not a unit test... Because the failure could be in one of the dependent classes, not in the class that is under test in my unit test!

Integration tests are useful as smoke tests to identify that a problem exists. But they don't help me quickly identify the root cause of problems when they arise.

The following shows a unit test for a Partitioner class that depends on a SystemIOAdapter (so dependencies on a specific IO is removed), and a MerchantrecordCounter class. You may notice that the only way to mock these out are by creating classes that implement the same interfaces used in the PartitionMerchants method. (In this case I am using Rhono Mocks to do this quickly).

using Project.Interfaces;

using NUnit.Framework;

using Rhino.Mocks;

namespace Tests

{

[TestFixture]

public class Partitioner_UT

{

private MockRepository mocks;

private string mappedpath = "mappedpath";

private string partitionedpath = "partitionedPath";

private ISystemIOAdapter io;

[SetUp]

public void SetUp()

{

mocks = new MockRepository();

io = mocks.CreateMock<ISystemIOAdapter>();

}

[Test]

public void PartitionDirectory_OnlyOneMerchantFound()

{

IMerchantRecordCounter counter = mocks.CreateMock<IMerchantRecordCounter>();

using (mocks.Record())

{

// set up call expectations here

}

using (mocks.Playback())

{

IPartitioner partitioner = new Partitioner();

partitioner.PartitionMerchants(io, counter, mappedpath, partitionedpath, 0);

// Add assertions here

}

I hope this clears up why it is so important to write code using interfaces whenever possible!

Jonathan Starr

Code Redundancy Is NOT Necessarily Bad

Jonathan Starr — Sat, 21 Jun 2008 22:43:37 GMT

I was just reading Jeff Atwood's recent blog article Department of Declaration Redundancy Department

He makes the case that writing code without static typing is easier to read, and "Anything that removes redundancy from our code should be aggressively pursued -- up to and including switching languages."

My take is "maybe".

Say I have a class named Example that implements two interfaces, IFoo and IBar. When I instantiate I have several options when dong so statically.

Example example1 = new Example();
IFoo example2 = new Example();
IBar example3 = new Example();

In the second case I am ensuring that example2 implements a certain interface, and I can swap this out with an instantiation of a different object that implements IFoo. This strategy pattern is fundamental to object oriented programming, and 'getting in the habit of writing code using var' can provide inflexible suboptimal design. Additionally, if you are coding using TDD (Test Driven Development) you won't be able to write unit tests that remove all dependencies for your class unless you write your dependencies as interfaces.

The way the compiler in C# 3.5 automatically converts LINQ queries to IEnumerable objects is nice. But the following statement

var reader = new StreamReader(fileName);

is cast to the child static type, not to the its abstract parent (as I think it should be).

Interested in your thoughts.

Jonathan

Hillary as Darth

Jonathan Starr — Sun, 04 May 2008 18:14:55 GMT

I try not to get too political in this blog, but I could not resist the Star Wars references!

Enjoy,

Jon

Who Is An Average Developer?

Jonathan Starr — Sat, 03 May 2008 00:24:12 GMT

Every blogger I read claims to have superior coding skills, and every place I have worked claims only to hire superior developers. In my current position and in my prior one, my employers say they interviewed more than twenty candidates to fill each position.

If that's so, where are the average coders?

I heard one theory - they are all unemployed! And they keep trying to get jobs but they can't. So interviewers have a skewed sampling of coders.

I will confirm that in my current and previous position i have worked with much better developers than I had previously.

But I wonder. I have learned so much in the last year (WCF, TDD, LINQ, PLINQ, Ruby, statistical modeling techniques with third party tools, Dundas charting, advanced NAnt builds, Webparts development, Appistry fabric development, Map-Reduce algorithms, etc.) - perhaps if I were to meet my former self from a year ago I would consider myself an average programmer.

My sense is that all coders are improving by leaps and bounds each year.

And that most of us have an inflated opinion of our own coding skills.

What do you think?

Interested in your thoughts,

Jonathan

Cats - From An Engineer's Perspective

Jonathan Starr — Sun, 13 Apr 2008 04:02:26 GMT

Admittedly I don't own any cats - I personally favor parrots.

But this video tickled my fancy anyway (loved the corporal cuddling - as if there were more than one kind!)

Enjoy

Jonathan

See the music

Jonathan Starr — Sat, 12 Apr 2008 01:37:51 GMT

From the Zurich Chamber Orchestra

Quantum Mental Health Break

Jonathan Starr — Sat, 12 Apr 2008 00:59:49 GMT

It's better than MC Rove (but not by much)

Beta Risk

Jonathan Starr — Sat, 29 Mar 2008 00:29:28 GMT

A friend at work recently asked me to look at some of the equities he holds in his portfolio. While I am a developer, I also have an MBA in Finance; I enjoy evaluating stocks and readily agreed.

One of my friend's holdings is Wal-Mart (WMT), and I was a bit surprised to see that finance.yahoo.com listed WMT's Beta, which is a measure of a stock's risk relative to the market, as -0.14. It is uncommon to find stocks with negative Betas. Generally this means that the stock moves in the opposite direction as the market. And the low Beta value, i.e. | Beta | < 1, indicates that the stock is less risky than the S&P500.

So I performed a few calculations, and measured the Beta for WMT using closing month prices for WMT and the S&P500 for the last five years, and reproduced the number listed on Yahoo! But I retried the calculation going all the way back to 1972, and got a Beta measurement of 1.23. And then again i measured beta for WMT only using the last 24 months of data and got a measurement of -0.31. (See graphs below for details).

WMT Calculation Beta - Last 60 Months (through March 2008)

WMT Calculation Beta - Data 1972 through March, 2008

WMT Calculation Beta - Last Two Years

So, given all of the variation in Beta measurements, what is a good way for estimating future Beta for a stock? This really is an important question, as Beta dominates the function to determine the Weighted Cost of Capital for a stock. (WACC = D/C ( Kd) + E/C ( Beta x Market Rate of Return). And if you are doing Beta arbitrage (buying baskets of low Beta stocks and short selling Beta stocks), this would be crucial. (Here's an interesting article on the subject... )

I suspect that modelers should make adjustments for changing legal environments, capital structurres, dynamics between companies and their customers, suppliers, and competitors... But which changes dominate Beta changes. Can the past Beta measurements be used at all to forecast future Beta?

Any ideas out there?

Interested in your thoughts,

Jonathan Starr

Flood

Jonathan Starr — Mon, 24 Mar 2008 23:49:39 GMT

Some friends and relatives have been asking about the flood conditions in Fenton, MO (outside Saint Louis) so I thought I should post some pics of the affected areas. My home has not been harmed (knock on wood!), but the area around me certainly has been.

I think this is a pic of a trailer park about three miles from my house.

Another pic..

There are a few bars, a public swimming pool and a soccer field affected by the rains as well.

Tueday, Wednesday and Thursday we are expecting more rain as well (Today is Monday...)

Local stations are saying the water levels should go down fast, however.

Jonathan

HttpModule Question

Jonathan Starr — Wed, 05 Mar 2008 03:21:41 GMT

I recently implemented an HttpModule in a web project (.NET 2.0 Framework on Windows XP), and noticed some anomolous behavior... The Init method for the HttpModule does not always fire (sometimes it did however) after the web application started. I used an obvious workaround, and took advantage of the event model exposed in global.asax. But I am disturbed from what I saw.

Has anyone else noticed this anomaly? Is this something that can be fixed?

Thanks for the help!

Jonathan Starr

Saint Louis Microsoft Technology Calendar Updated...

Jonathan Starr — Mon, 03 Mar 2008 05:19:53 GMT

improve my => 'code'

I have updated the unified Saint Louis Microsoft Technology calendar here.

Here is a quick summary:

St. Louis C# User Group 3/10/2008 6:00pm
Our guest, live from France, will be Patrick Smacchia, creator of NDepend and author of Practical C# 2 and .NET 2.

Sharepoint meeting 3/11/2008 8:30am

St Louis Sql Server User Group 3/11/2008 1:00pm
Writing better T-SQL Queries, Avoid Cursors and Dynamic SQL

CRM User Group Meeting 3/27/2008 8:30am

NET User Group Meeting 3/31/2008 5:30pm
Denny Boynton “Software as a Service”

All events take place at Three City Place Drive, Suite 1100, Creve Coeur, MO 63141

Hope to see you there!

Jonathan

Buddhabrot

Jonathan Starr — Fri, 29 Feb 2008 02:14:36 GMT

I apologize for not writing into the blog for some time.

A few weeks ago, I attended the wedding of my good friend, Michael Bittel. His blog on Africa, while it is updated infrequently, certainly certainly helps me keep things in perspective.

Also, I have continued to do some work for www.1CCN.com . Please check out this web site/ phone application for project management if you, or someone you know, is in the construction industry. We recently added the ability to add pictures to status updates. Hopefully this will be useful to someone.

I started a new job recently for a startup company here in Saint Louis, MO. One of my new co-workers showed me this interesting rendition of the Mandelbrot Set (yeah, I'm a big fan). Basically, instead of using real numbers to create the set, the renderer used complex numbers... And the results are pretty eerie... Looks like a buddha!

Hope everyone reading this entry is doing well,

Jonathan

Undergoing MyBlogLog Verification

LINQ and Financial Simulation

Jonathan Starr — Sat, 26 Jan 2008 02:00:25 GMT

improve my => 'code'

I just started playing around with LINQ seriously, and I really love some of the features incorporated, like the Enumerable.Range() function and how it can be used for integer programming.

Here's a simple function for generating lognormal distributions (could be useful for financial engineering).

Hope you're enjoying the samples,

Jonathan Starr

public List<double> GenerateLogNormalDistribution(int numberOfTimes, double mean, double standardDeviation)

{

Random randomGenerator = new Random();

var randomNumbers = from theNumbers in Enumerable.Range(1,

numberOfTimes).Select(x => randomGenerator.Next(1,

1000)/1000.0)

select theNumbers;

List<double> results = new List<double>();

randomNumbers.ToList().ForEach

(x => results.Add(mean + (standardDeviation * (Math.Sqrt(-2 * Math.Log(x)) * Math.Cos(6.28 * x)))));

return results;

}

Surprising CLR Behavior

Jonathan Starr — Fri, 25 Jan 2008 22:45:20 GMT

improve my => 'code'

The following code (surprise, surprise) compiles. But it does not work as intended (you won't be able to "doSomethingElse()!

Can any of you figure out why? (I have my suspicions.)

Jonathan Starr

using System;

namespace test

{

internal class BaseTest

{

private int _prop1;

public virtual int prop1

{

get { return _prop1; }

set { _prop1 = value; }

}

internal class DerivedTest : BaseTest

{

public override int prop1

{

set { base.prop1 = value; doSomethingElse(); }

}

Response to Brainteaser #11?

Jonathan Starr — Fri, 25 Jan 2008 21:23:24 GMT

I have been pretty excited about LINQ, because it seems to do all of the optimization for me for free (kinda like T-SQL).

Yow Han-Lee asks in his blog, Brainteaser #11, Given any two large List, what is the quickest way to find the mutual intersection of the two? Now take into consideration memory constraints?

Well, the answer that only takes a minute or two for me is the following...

Comments welcome!

Jonathan Starr

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace orderlisttest
{

    internal class Number
    {
        private int _Num1;
        public int Num1
        {
            get { return _Num1; }
            set { _Num1 = value; }
        }

        public Number(int theNumber)
        {
            this._Num1 = theNumber;
        }

    }
    public class start
    {

        public static void Main(string[] args)
        {
            var bigList1 = new List<Number>();
            var bigList2 = new List<Number>();

            for (int counter = 0; counter < 100000; counter++)
            {
                Random randomGenerator = new Random();
                int number = randomGenerator.Next(10000000);
                bigList1.Add(new Number(number));

                int number2 = randomGenerator.Next(10000000);
                bigList2.Add(new Number(number2));
            }

            var Found = from o1 in bigList1
                        join o2 in bigList2 on o1.Num1 equals o2.Num1
                        select new { o1.Num1 };

Console.WriteLine(Found.Count().ToString() + " items were found in common.");
}

}

}

Beauty.Equals(Truth) ?

Jonathan Starr — Tue, 22 Jan 2008 19:58:11 GMT

improve my => 'code'

I noticed an entry on Wikipedia that made me smile.

SPL or the Shakespeare Programming Language is, in the words of Wikipedia, "designed to make programs appear to be something other than programs; in this case, Shakespearean plays. "

Variables in code are treated like characters in a Shakespearean play. Variables must "enter" to be useable (allocated?) and "exit" to be declare out of scope... And variables speak their mind to output to the console. For instance,

[Enter Juliet]
[Enter Romeo and Juliet]

Hamlet:
Thou art as sweet as the sum of the sum of Romeo and his horse and his black cat! Speak thy mind!

[Exit Romeo]
[Exeunt Romeo and Juliet] [Exeunt]

My only point is - Do you write your code pleasing to the eye? Or is it a jumble of symbols barely comprehensible?

I am all for bringing a sense of beauty to our coding, and am open to suggestions.

Interested in your comments,

Jonathan Starr

The Sesame Street Presentation Rule - Not #1

Jonathan Starr — Mon, 21 Jan 2008 20:53:25 GMT

I just read through Jeff Atwood's recent post - The Sesame Street Presentation Rule - and it warrants a reaction.

The most important feature of a presentation is that it communicates how you can benefit your audience. People are not actively trying to fund cartoons or quips as much as they are looking out for their own very personal needs (whatever that is). So, it is vital that we analyze our audience for their needs - as needs differ.

Employees are generally interested in security, and possibilities for advancement. Investors generally look for quick and sizable returns on investment. If you focus on the particular interests of your audience, there is very little need to be funny.

Humor can help - I will concede. But it is so difficult to be funny.

Hey, Jeff Atwoods' blog is a case in point. Really not very funny, but he satisfies the needs of his readers to explore quirky topics.

Interested in your thoughts,

Jonathan

Thought Experiment: Reforming Meetings

Jonathan Starr — Wed, 16 Jan 2008 23:31:18 GMT

I just read an excellent article posted on XKCD on how to create a better IRC chat.

Basically, to keep chats interesting, the server boots out users who enter things already entered before.

Wouldn't that be good for corporate meetings? The rule could be amended: If someone says anything said before (even using different words), the person cannot speak again for the duration of the meeting.

Imagine how much shorter meetings would be with this rule. No more endless repetitions. No more wasted time.

Another nice side effect is that meeting attendees might pay more attention to what is said - because they are enforcing the rule!

Interested in you thoughts,

Jonathan Starr

Automatic Properties in C# - A Critique

Jonathan Starr — Wed, 16 Jan 2008 02:00:47 GMT

improve my => 'code'

In the latest release of Orcas, one of the new features provided is "Automatic Properties" which allows developers to use a shorthand like the following:

    public class Person {

        public string FirstName {
            get; set;
        }

        public string LastName {
            get; set;
        }

        public int Age {
            get; set;
        }
    }

and the compiler knows to interpret this as

    public class Person {

        private string _firstName;
        private string _lastName;
        private int _age;

        public string FirstName {

            get {
                return _firstName;
            }
            set {
                _firstName = value;
            }
        }

        public string LastName {

            get {
                return _lastName;
            }
            set {
                _lastName = value;
            }
        }

        public int Age {

            get {
                return _age;
            }
            set {
                _age = value;
            }
        }
    }

Prima facie, this looks like a good thing. The developer is typing less code, and still has hooks in property accessors to perform validation, or needed side effects from value changes.

But I have a few problems with this shorthand.

Criticism 1

Why is this shorthand needed when there is a snippet (prop) that provides full property accessors, with better hooks for inserting custom actions like validation?

Criticism 2

I think that the shorthand looks too much like the signature of a method normally found in an interface, not a class. The only difference appears to be an access modifier. So I find the shorthand syntax is confusing...

What do you think?

Jonathan Starr