Our focus on feature toggles and branch by abstraction was quite accidental. We were changing a fundamental way our system handled calculations by moving from doing them ourselves to asking an external service to perform key calculations for us. As with many an integration point, the external system was not quite ready by the time we started to introduce the modifications, so testing our side was proving to be tricker than initially anticipated. One day, the pair working on the story came to me and said “Sarah, we are having problems changing our tests. We are going to need to change a whole bunch of tests, because they all rely on this value to be calculated on the fly but we now go out to the external system”[1]. We started spitballing ideas, when suddenly, it came to me in a light bulb moment. “Why don’t we wrap this class with a switcher”, I said. “The switcher can be told which calculator to use - the existing one, or the new external service”. BAM. All of a sudden, it made brilliant sense.

You see, one we had this switcher in, we were then free to continue developing this new feature, share the code with everyone and not stuff up our testing in the process[2]. So we continued along, quite happily, with our QA toggling the switch when he wanted to test the new stuff, and switching it back when he wanted to do testing on the other features.

That might have been the end of the story, the brilliance of this solution being completely lost, until the inevitable happened[3]. The external team delivered working code, but it was not production ready - it was way too slow for us to use it in the specified manner. Uhoh! Here come the managers in a series of crisis meetings. After various performance tests, back-and-fro with the other team, and debating what the performance should be, our business sponsors were faced with a dilemma. What should they do? They can’t release the software with the way it was performing, but they had a whole bunch of other features in that release that they were desperate to deploy.

“I can always turn off that feature”, I said timidly in one meeting. “We haven’t removed the ability to calculate internally, we have just hidden it behind a switch. All we need to do is release the current version with that switch turned to internal calculations. Then, when the performance has improved, we can switch the calculations to use the external system. We don’t even need a new deployment for that. It will happen automatically with a simple configuration change on the fly”. Silence. The room was gobsmacked. “You mean, the business has control of when this feature is to be deployed?”, they thought. Of course. That is how it should be.

This incident was probably the only time when my sponsor came to me and told me that I had done a brilliant job[4], that I had saved the company a lot of money by having the foresight to have this architecture in place.

Our imagination and innovation grew from there.

There was a feature in the UI that our product owner wanted to get approval from the rest of the business to remove but it was taking a while to jump through all the necessary[5] hoops. As a release was scheduled for the next day and the next not for another month it was really important to get approval ASAP. But we didn’t get approval in time and the product owner didn’t care. You see, we added in another toggle around the visibility of that feature. That way when the decision finally came through, one week after the release, the business turned it off and started to see the reward immediately without waiting another 3 weeks for the next release train to come along. Yet another time when we saved the company valuable money.

I also started to talk about allowing our super users to have the external calculations for their plans, and internal calculations for all other uses so that we could get first hand feedback to determine when the performance was indeed good enough. The performance had not improved by the time I rolled off, but we were certainly starting to put thought into this plan.

My mind races to think of all the other uses. Take AB testing for instance. How easy would it be to use these to gather statistics, then discard the unpopular path. BAM - mind explosion.

You see, Feature Toggling is not just a different way to achieve feature branching. It is an architectural choice that, sure, helps with maintaining mainline development but the power is that it hands back control of what features should be enabled and when to the business. And it is there, ready for you to harness. No extra steps required. As awesome as Git is[6], you just cannot compete with something that allows you to not only control what features go into a release but what features are live at any one time[7].

So now you know how we were able to save money by introducing Feature Toggles. What could you do, if you had feature toggles?

Update 16 July 2011 Whenever you write an experience report, you run the risk of missing out some of your thoughts, assuming that they come across clearly. Thank you to everyone who has given me feedback on this post. I am adding answers at the bottom to address some of the questions that have been raised since originally posting this.

How do you ensure that what is going into prod works? We achieved this by making the default configuration always be that of production. So, for our QA to test a certain incomplete feature in our QA environment, he had to turn it on explicitly. When a new build was pushed out, the configuration had to be changed again. My friend, Chris Bird recommends that you could consider separating feature flags from the deploy package and make it environmental config. This would mean the QA would not be configuring after each deployment. Perhaps considering tools like Chef to control the environmental config?

How do you know what toggle is on? We had an application configuration page which showed really cool things such as build numbers, db migration version and configuration values of the properties (and where the configuration was set eg app.config, prod.config). This page also exposed the values of all known feature toggles.

When do you remove the toggle? And who makes that decision? I would agree with everyone that they have a TTL. Although we didn’t do this, you could put a TTL on the configuration page…or how long it has been in place. Then, after it hits a threshold you remove it. On the project, once it was live we tidied up the code following the boyscout rule. You could also have a TTL wall, making it visible to everybody. Also, if you know how long the feature has been there without being turned on, you could get that stats for monitoring waste. As to who makes the decision, I would say that if the business knows you have these toggles, talk to them about keeping them in vs taking them out and the risk/debt you are carrying as a result. My friend, Chris Bird recommends marking the toggles with expirations through a mechanism like ignore attributes in the code. When those ignores expire it breaks a test (and then the build) to warn you about removing these attributes. This could also be a nice technique for reminding you when these things need to be addressed.

Don’t you get an explosion of combination of toggles? Yes, so remove them if they are no longer needed.

If you switch it on in prod, what about testing? How can you ensure that it is tested? Doing this was completely to get around the fact that the business wouldn’t let us release more frequently. We pushed and pushed and pushed really hard, but we were only able to do fortnightly releases twice before they thought the overhead was too much. What we did was to test it in UAT with the different combinations, so even though we switched it on in prod, we tested it thoroughly in UAT first. I would prefer to just push out a new release, but failing that, this was a good alternative. And I appreciate that that sentiment is not clear in the post, so I hope this clears things up.

[1] full confession - our tests were too unwieldy and smelly. This challenge just highlighted to me the problems with our tests. [2] before this, we were faced with keeping the code on a separate branch, but with the amount of refactoring that was going on in that crucial area, we were not too keen on the day we had to merge back into master [3] to be fair, given my talk on integration systems, I should have known better… [4] if you ever wanted to hear a case study of how negative reinforcing loops impacts team morale, I have some stories for you… [5] let’s face it - they weren’t necessary [6] and it truly is awesome [7] yes, I know the argument is to remove the toggles once it is turned on, which of course simplifies the code. I leave it as an exercise for the reader to determine the best course of action

Perhaps unsurprisingly, I agree with Martin & Mike’s view on branching. I have been on several projects that have adopted various strategies like branching by features, feature toggling & branching by abstraction so I have personal history to back up what others say about branching. But, the argument goes that that was when we were using source control systems that made branching and merging difficult and painful, like CVS, subversion and Perforce. This is true. But on my last client, we used git and branch by feature. This is my experience working in this way….

At my last client, we used started by using Git and branch-by-feature[1]. Features would take anywhere from 1 day to 5 days to complete. At the end of the feature, it would be merged back to master (having been good little girls and boys and continuously merging from master …that is CI isn’t it???)[2], pushed and then CI would trigger.

Guess what happened - tests on CI would fail because CI was running a bigger suite of tests than our cmd line. Ok, so we didn’t have CI running on the branch, but really - what harm did it do? So you had to spend a little extra time fixing those tests….we’re not buying that whole “you’re not really doing CI” argument. Branch by Feature is cool - look - you can clearly see which changes relate to a story and you can back them all out if you need to.

Then, QA gets their mits on it for the first time. Those little devils..they’re raising little pink stickies on my story! Well, better go fix them….on master. Wait - so the paradigm of branch-by-feature is only until the dev’s think its finished?[3]

But lol - a nice big juicy refactor story comes along. You know the one - the kind where you roll up your sleeve, batten down the hatch cause you are going to be there for a while. After 5 -7 days, you poke your head up again, and decide - jobs a goodin’, lets merge and push to master. But despite how well git handles merges, if you have removed/renamed/modified a method that a new piece of code relies on, git cannot help you. So you fix all compilation problems, and run tests (of course, we’re agile) and BOOOM!!! failed tests. They are harder to decipher. And didn’t we fix half of these before? grrr….so, 5-7 days after you finished the refactor, you spend another 1-2 days in merge hell…and this was with GIT!!!

Boy, you think we would’ve learnt that first time. But in spectacular face-palm fashion, we persevered with branch-by-feature always promising we would do it better next time. Fool me once, shame on — shame on you. Fool me — You can’t get fooled again.

Don’t worry - we did learn. We added feature toggles to help with the testing of a story (also using branch-by-abstraction). Then, when the 3rd party the new code was talking to wasn’t ready by the release date, we switched the toggle back to the old way, released all the other new features, thoroughly impressed the client (who believed that we would need to wait another 3 months for the 3rd party) and felt chuffed ourselves. After that, we hopped onto the release train, all stories developed on master with feature toggles where necessary and got the business back into fortnightly cycles, without the pain of branching-per-release[4]

Next time, I don’t think that I would be so diplomatic towards branch-by-feature….if I see it again, I think that I might stamp it out straight away. Every time I have seen it (and this is on 6 mthly branches, monthly branches, fortnightly, weekly & daily) the same problems keep coming up[5].

[1] actually - to clarify…when I rolled onto the project, that is what the team was doing so I decided to see how well it would go… [2] for those who are sarcastically-challenged, that was said tongue-in-cheek. [3] that wasn’t the only strategy tried..but it was the quickest for small fixes…for larger change there was a debate as to whether you should create a new branch or just merge current master into the old branch and continue…both send shivers down my spine… [4] we also tried various techniques with branching-per-release…we had another Go pipeline setup so that any releases or hotfixes would move through that. For a little while, this was important as UAT uncovered some stuff to fix, but in the end it was unnecessary as we just released whatever was the lastest good build - and toggled off all the other incomplete features. [5] actually…git’s branching does make it really cool for spikes and helping you work out how to refactor a piece of code…but once discovered, ditch it and start from scratch on master

At school, there were some subjects that I really wanted to do well in, and get As. Then there were subjects that I needed to take for prerequisites, but all I needed was to pass, so a C in that (or even a D) was perfectly fine by me.

When we develop software, there are some features that we really want to do well in and get right - these are our distinguishers. Then, there are other features that we just need to (e.g. to keep up with the market), but they don’t distinguish us from our competitors, so we want to spend only enough effort to get it in, without doing something distinguishing.

At school, there were also subjects that were basically easy As - I could put very little effort into studying for them, and I could take home top marks. Then, there also subjects that no matter how hard I studying, how much effort I put in, all I could pull off was a C.

When we develop software, there are some features that we can do really well at, for minimum effort. Then, there are features that are really trying to get in, and when we do, they might be a bit clunky or constantly requiring effort to maintain.

At school, there was also a limit to the number of subjects I could study at once. If I took more subjects then my normal limit, then they would all suffer - even the easy A weren’t so achievable. And I swapping between them all the time was difficult, so I would dedicate time to study on one at a time (usually half a day before I switched).

I think you can see where I am going…fill in the blanks about Work in Progress limits and “multi”-tasking.

So, thinking about stories and requests as school grades now gives a different perspective to prioritisation and valuing. We can start talking about getting outstanding As or just passing, about how some stories are easy to do well at (so let’s just do them) and others will take an effort to just pass (is that effort worth it in the end? Perhaps the time could be used for other features?). And for me, this metaphor is much more accessible - I have been there, I remember what it was like to study hard for subjects and get no where, and others be really easy and I remember prioritising my subjects based on how difficult it was (a really hard subject taken with an easy subject was the way to do it).

So - what grade would you like for that?

Here is how it works:

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
43
44
45
46
47
48
49
50
51

public interface IVictim<T>
{
  void MuggedBy(IRobber<T> robber);
}

public interface IRobber<T>
{
  T StealFrom(IVictim<T> victim);
  void Steal(T valuables);
}

public class Percentage : IVictim<T>
{
  private readonly decimal percentage;
  public Percentage(decimal percentage)
  {
      this.percentage = percentage;
  }

  public void MuggedBy(IRobber<decimal> robber)
  {
      robber.Steal(percentage);
  }
}

public class ValuablesRobber<T> : IRobber<T>
{
  private T stolenGoods;

  public T StealFrom(IVictim<T> victim)
  {
      victim.MuggedBy(this);
      return stolenGoods;
  }

  public void Steal(T valuables)
  {
      stolenGoods = valuables;
  }
}

public class PercentageFormatter : IFormatter
{
  public string Format(object toFormat)
  {
      if (toFormat == null) return string.Empty;
      var percentage = (Percentage)toFormat;
      var value = new ValuablesRobber<decimal>().StealFrom(percentage);
      return value.ToString("0.00") + "%";
  }
}

Here is how I did it (tests and other junk removed for readability):

.Net Code

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
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123

public class Pagination<PaginatedType> : IEnumerable<Pagination<PaginatedType>.Page>
{
  private readonly IList<Page> pages = new List<Page>();
  private readonly Page currentPage;
  private readonly IEnumerable<PaginatedType> paginatedCollection;
  private readonly int maximumCount;

  public Pagination(IEnumerable<PaginatedType> paginatedCollection, int maxCount, Page currentPage)
  {
      this.maximumCount = maxCount;
      this.paginatedCollection = paginatedCollection;
      var pageSize = currentPage.PageSize();
      for (var i = 1; i < maxCount; i+=pageSize)
      {
          pages.Add(new Page {StartingAt = i, EndingAt = i+pageSize-1});
      }
      this.currentPage = currentPage;
  }

  public IEnumerable<PaginatedType> PaginatedCollection
  {
      get { return paginatedCollection; }
  }

  public int MaximumCount
  {
      get { return maximumCount; }
  }

  public Page CurrentPage
  {
      get { return currentPage; }
  }

  public bool IsTheCurrentPage(Page page)
  {
      return currentPage.Equals(page);
  }

  public IEnumerator<Page> GetEnumerator()
  {
      return pages.GetEnumerator();
  }

  IEnumerator IEnumerable.GetEnumerator()
  {
      return GetEnumerator();
  }

  public struct Page
  {
      public int StartingAt;
      public int EndingAt;

      public string Name()
      {
          return string.Format("{0}-{1}", StartingAt,EndingAt);
      }
      public int PageSize()
      {
          return EndingAt - StartingAt + 1;
      }
      public bool IsValid()
      {
          return StartingAt <= EndingAt &amp;&amp; StartingAt > 0;
      }
  }
}

public interface IWillFindYouTreasures
{
  Pagination<Treasure> FindTreasuresFor(Pagination<Treasure>.Page page);
  Pagination<Treasure>.Page FirstPage();
}

public class PaginatedTreasureFinder : IWillFindYouTreasures
{
  private readonly IPropertyStore propertyStore;
  public PaginatedTreasureFinder(IPropertyStore propertyStore)
  {
      this.propertyStore = propertyStore;
  }

  public Pagination<Treasure> FindTreasureFor(Pagination<Treasure>.Page page)
  {
      if (!page.IsValid())
      {
          return new Pagination<Treasure>(new Treasure[] {}, Treasure.Count, FirstPage());
      }

      var criteria = DetachedCriteria.For<Treasure>()            
          .SetFirstResult(page.StartingAt-1)
          .SetMaxResults(page.PageSize());

      var treasures = ActiveRecordMediator<Treasure>.FindAll(criteria);
      return new Pagination<Treasure>(treasures, Treasures.Count, page);
  }

  public Pagination<Treasure>.Page FirstPage()
  {
      var endingAt = propertyStore.Get(ApplicationProperty.FirstPageEndingAt).AsIntOr(1);
      return new Pagination<Treasure>.Page {StartingAt = 1, EndingAt = endingAt};
  }
}

public class TreasureController : Controller
{
  private readonly IWillFindYouTreasures treasureFinder;

  public TreasureController(IWillFindYouTreasures treasureFinder)
  {
      this.treasureFinder = treasureFinder;
  }

 [AcceptVerbs(HttpVerbs.Get)]
  public ActionResult Show(int id, int startingAt, int endingAt)
  {
      var page = new Pagination<Treasure>.Page {StartingAt = startingAt, EndingAt = endingAt};
      var treasures = treasureFinder.FindTreasureFor(page);
      ViewData["Pages"] = treasures;
      return View("Show");
  }
}

View

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

<div>
  <span>There are currently <span class="treasure-count"><%= Pages.MaximumCount %></span> treasures available.</span>
</div>

<div class="pagination custom-page-select">
  <div class="options">To view specific treasures, please enter the number to start at <%= (RawHtml)Html.TextBox("StartingAt", Pages.CurrentPage.StartingAt)%> and to finish at <%= (RawHtml)Html.TextBox("EndingAt", Pages.CurrentPage.EndingAt)%> and click <%=(RawHtml)Html.ActionLink("Go", "Show", "Treasure", new { }, new { id = "paginateDirectly" })%></div>
  <div class="clear"/>
</div>

<div class="treasures-list">
  <% new TreasuresRenderer().RenderTreasures(Pages.PaginatedCollection); %>
</div>

<div class="pagination menu">
  <span class="info">Please select a range of treasures to view.</span>
  <ul>
      <% foreach (var page in Pages) { %>
      <li class="pages<%= Pages.IsTheCurrentPage(page)? " currentPage" : string.Empty %>"><%=(RawHtml) Html.ActionLink(page.Name(), "Show", "Treasure", new {startingAt=page.StartingAt,endingAt=page.EndingAt}, new {}) %></li>
      <% } %>
  </ul>
</div>

Helpful Javascript

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

function SetupPagination() {
  $(".pages a").click(function () {
      $("#content-main-container").load(
                  $(this).attr('href'),
                  function () {
                      SetupPagination();
                  });
      return false;
  });

  $('a#paginateDirectly').click(function () {
      var url = $(this).attr('href') + '?StartingAt=' + $('input[name="StartingAt"]').val() + '&EndingAt=' + $('input[name="EndingAt"]').val();
      $("#content-main-container").load(
                  url,
                  function () {
                      SetupPagination();
                  });
      return false;
  });

  $('input[name="StartingAt"]').numeric().limit(9);
  $('input[name="EndingAt"]').numeric().limit(9);

  $('input[name="EndingAt"]').keyup(function (e) {
      var key = e.charCode ? e.charCode : e.keyCode ? e.keyCode : 0;
      // return should trigger the pagination
      if (key == 13) { $('a#paginateDirectly').click(); }
  });
}

What is formal specification? Formal specification is a way that allows us to mathematically analyse our programs to formally verify that it is correct according to the specification. There are 3 basic constructs: pre condition, post condition and invariant. Preconditions are the rules which describe the state of the world before an action, post conditions are the rules which describe the state of the world after an action, and invariants are the rules which are always true. Using a trivial example of a bank account (which is not allowed to go in the red):

Pre condition to Withdraw: withdraw amount > 0 Post condition to Deposit: balance > deposit amount Invariant: account balance > 0

So, then a valid program would look something like:

account = new Account() account.deposit(200) account.withdraw(100)

All good there. Now what happens when I do the following?

account = new Account() account.deposit(200) account.withdraw(600)

My formal specification analysis would (should) verify that the last withdraw would mean balance is -400 < 0 which fails the invariant. So the program has a problem. Note that according to formal specification if you actually ran this invalid program, the result would be indeterminate: that is to say that (formally speaking) we cannot tell you what would happen (it may fail gracefully or blow up dramatically).

Ok, so good so far but can you see where this stuff might be useful? Do you ever explicitly write precondition code? The type that looks something like:

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

class Account
{
  public void Deposit(int amount)
  {
      if (amount < 0) { return } // or throw exception or something else horrible
      //else continue
  }
}

class MyBanks
{
  private Account account = new Account();
  public void Deposit(int amount){
      if (amount < 0) { return }
      account.Deposit(amount)
  }
}

I have seen this style a lot, especially when people heavily unit test each class for every possibility that could happen. In reality, your other classes bomb out before you get to the if statement in Account, but you really want to describe a precondition on deposit. I have felt that being able to unobtrusively define pre conditions, post conditions and invariants on classes has been lacking in common programming languages/ecosystems. So, lets take a look at CodeContracts which is coming bundled with .Net 4.0

.Net 4.0 Code Contracts Code contracts support pre-, post-conditions and invariants. They have the same meaning as I previously described. They can statically analyse your solution on compilation and also dynamically analyse during runtime. What would our previous solution look like:

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

class Account
{
  private int balance
 
 [ContractInvariantMethod]
  private void BalanceHasToAlwaysBeInTheBlack()
  {
      // Note to reader: only conditions can be in here
      Contract.Invariant(balance >= 0)
  }
  
  public void Deposit(int amount)
  {
      Contract.Requires(amount > 0)
      Contract.Ensures(balance > amount)   // Note to reader: you can also ensure on the returned object e.g. Contract.Ensures(Contract.Result<int>() > 0)

      balance += amount
  }
  
  public void Withdraw(int amount)
  {
      Contract.Requires(amount > 0)
      
      balance -= amount
  }
}

Running statical analysis (hint: turn it on in the Properties tab panel) on account.Deposit(-400) would show produce a warning to say that this breaks the precondition however if (amount > 0){ account.Deposit(amount)} would be validated. If you did not listen to the warning and carried on regardless, in production the application would throw an exception.

So, what do you think? In my opinion, it is an interesting idea and in theory I would love to use it. However, Microsoft’s execution has a lot to be desired. The analysis does not seem to find everything (the analysis checker said that balance/50 would break the invariant). I don’t think it is unobtrusive. Perhaps you can farm the Contracts off to a meaningfully-named method but I’m not sure that it works like that.

I am also a little worried about the implications of this. I was talking to a few people who didn’t write tests: they believed that unit tests were not DRY so they don’t like doing it so they were really excited by code contracts because it made the specification DRY. However, effective TDD is more around understanding what to test than the tests themselves and it is the same thought process involved when formally specifying the system. I worry the level of false confidence this gives to developers who are not used to writing effective tests now.

I am eager to work with them properly and explore how they can be used successfully. There is some good in there, so that I don’t want to throw the baby out with the bathwater.

[1] for my university honours project I was working on a theorem prover in prolog for formal specifications written in B

Next month, I will be speaking at Goto CPH (in Copenhagen of course) in a talk titled What about People over Process? I am really looking forward to this one - the form is a little looser than I usually go for but it is an accumulation of all the psychology books I have been reading of late.

This talk was really interesting, and I highly recommend watching it. In it, she gives three really great pieces of advice for fellow females:

1. Sit at the table - women systematically underrate their own abilities. As a result, women don’t negotiate for themselves in the workplace. Women attribute success to external factors, men attribute success to themselves. No one gets to the corner office by sitting on the side not at the table and no one gets the promotion if they don’t think they deserve their success or they don’t know their own success. Unfortunately, success and likability are correlated positively for men and correlated negatively for women. How good are we as managers for seeing that men are reaching for opportunities more than the women?

2. Make your partner a real partner - make your partnership an equal partnership. Be kind to the fathers at Mummy & Me classes. Make childrearing as important a job as any others, for both men and women. Societal pressures are just as hard for men who want to stay home to look after the kids, whilst their wives are at work, as it is for the wives to be leaders. We can’t solve the problems of the lack of female leaders if we neglect to also solve the problems of the lack of stay-at-home fathers

3. Don’t leave before you leave - basically, don’t back away from opportunities because you don’t think you would be able to fit it in with a family life or maternity leave, which could happen sometime in the future, but is not in your reality right now. From the moment a women starts having a child, and she starts thinking of how to make room for that child in her already busy life. And from that moment, she doesn’t raise her hand any more, look for a promotion, start a new project. The problem is that even if she were to get pregnant that day, with 9 months incubation, a year maternity leave and a few months getting back into work, it is almost 2 years before she can think of raising her hand again. And the reality of the situation is that it is usually a few years before she even starts to have children - in a lot of cases, before she even has a partner. Sheryl’s words are inspiring - Keep your foot on the gas pedal until you actually leave.

Sheryl is very engaging in this talk, and I throughly recommend watching this video!

Come to my London Dot Net User Group talk next Thursday (18th November) at Skills Matter and you will hear about how to design your system to decrease this risk, how to ensure the quality of the overall system and how to manage the successful delivery of the system. Not only that, but you will hear real-life cases, some success stories but also many failures and you too can learn from the mistakes I witnessed. Have questions around the integration points in your ecosystem? Fire them up, and lets see if we can work through them together.

Registration is at http://skillsmatter.com/podcast/open-source-dot-net/how-to-design-your-system-to-decrease-risks

Thanks to LDNUG, Skills Matter and Rachel Laycock for finding me a soap box to stand on.

On my current project we have decided to appease my sensibilities and have called these Cross Functional Requirements to better express what they truly represent - requirements which cross all the functions we are building. So far the wording works - but we have only finished the 2nd week of inception.

The English language is a very complex beast which can easily strike confusion in the most unsuspecting moment. Take, for example, the word “lollies”. Did your mind immediately jump to a bag of gummy bears, redskins, bananas or milk bottles that you get from the garage? Or instead did you start thinking of a frozen dessert on a stick? If you thought the former, then, like me, you probably are Australian. Because the English term for it is sweets, and the American version is candy (although I doubt that they have such wonderful lollies as bananas and milk bottles). And the frozen-dessert-on-a-stick - thats an iceblock for me!

Take another example - when Sisqo’s Thong Song came out I didn’t really understand why someone dedicate an entire song to $1 rubber plugs - until I watched the video clips and I realised that he wasn’t referring to ”flip flops”.

The lesson that I have learnt living in the UK is that I have to be very careful with the words that I use, lest I cause confusion by saying that someone was running around with their pants* off**.

And this is also applies to the words and language that we use around our business, between developers and in our code. Too often we describe concepts by words like “that thing” or “this stuff” which can obfuscate what it really is, and hence hinder our ability to model it. I often see complexity, misunderstandings and hacks creep into code bases when the original designer has referred to an information concept as “this thing” without taking the time to name it. I find that spending the energy talking to the business to understand what you are really producing helps clarify understanding which in turn distills the model into a simpler, easily understood model.

I had this demonstrated to me yesterday, when I came across a pair discussing how to “shove” this concept of “a thing that when clicked on opens up a popup with stuff in it” onto the model. As I listened to the conversation, I noticed just how muddled the model and the situation was becoming, so I decided to intervene with some of my words of wisdom about what they were trying to model. As soon as we worked out that the “thing that when clicked on opens up a popup with stuff in it” translated into “a help message”, we were easily able to see exactly where in our model it should go.

So, never underestimate the power of the words we use. When faced with a confusing concepts strive to distill it into easily understood, well defined names.

• pants in Australia are trousers - pants in the English vernacular are what I call underpants. ** yes I have once said that at work after I saw a pair of jeans on the table and was a little confused by what someone must be wearing!

I think one of the biggest concerns that conference organisizers should be worrying about (and luckily JAOO did) is that the ratio of women at the conferences does not reflect the industry - I have heard that between 5-10% is considered good, where as I believe the industry is at about 20% (unconfirmed sources). I don’t want to start of speculating at why the numbers are so low, but what I can share is why I don’t attend conferences.

Conferences are quite expensive for your employer - not only do they need to purchase entry, but accommodation, meals and transfer to and from the conference, not to mention loss of “billable” work. So, usually they can only afford to send one or two people there. I have seen two ways that these tickets are distributed. The first is that the same people always seem to go to the conference. It is noticeably remarkable how many people you see at conferences that seem to be on the “conference circuit” - they have seen each other every month, following the conferences around the world. So, unless you already are in the conference circuit, it is really hard to enter it - as there are currently 5-10% women normally at conferences, and the same people keep attending, then this number won’t change. The other way that I have seen tickets distributed is by everyone-gets-a-turn selection. Lets say the industry average is 20% - then its only fair that for every five conferences that are attended (given one ticket per conference), a company would send a female to only one of them. From that point of view, it does not seem that unbelievable to me that the number of women is low in comparison.

So, I think it is up to conference organisers to think outside the box for different ways to attract females to conferences. For this, I would like to commend the people at Trifork who organised JAOO Aarhus 2009 as they did something a little different. For every full-paying ticket that you bought for JAOO, you were entitled to a free day pass for a person of the opposite sex. This wonderful scheme saw registrations jump from a lowly 3.7% to about 14%. I think that this shows that the arguments around women not able to travel to be not necessarily the driving factor behind the low attendance, and perhaps the key lies in being selected in your company to attend. For me it is certainly true that the main reason I don’t attend conferences is that I believe that the bought tickets should be distributed fairly.

I think, however, speaking at a conference is slightly a different manner. I read today (I tried to find the source, but I can’t seem to find it again) that the difference between a would-be male speaker and a would-be female speaker is that the female thinks “I don’t know everything about [topic], I don’t think I can speak” whereas a male thinks “I know a bit about [topic], I think I will speak”. I obviously don’t know if that is true for all men/some men/no men in as much as I can’t say that it speaks for all women/majority of women. What I can say is that it certainly rings true for me.

As anyone who has known me since I was three can testify, I like public speaking. I am comfortable on a stage, talking about what I feel passionate about. As a female software dev who loves public speaking, I feel that I should be one of those who help increase the numbers - but here’s the catch. I don’t want to get up and talk just because I am a woman. If I ever present at a conference, I want it to be primarily because I have something important to say about technology and -oh yeah- I happen to be a women. But I also don’t feel that I have anything that interesting worth presenting - I don’t know as much as those guys already presenting, so what would I have to give. I don’t know if this is a female trait - I would be interested to find out if others feel like this.

If this assertion is correct (that women don’t feel that they have anything to say), perhaps the conference old-timers could help these would-be presenters in recognising material that could be presented. Another way to know if you have something valuable to say is to go and attend a few conferences yourself - see what other newbies are presenting, and see if you can do as good a job (lets face it - there is no sense in comparing yourself to a Martin Fowler or a Neal Ford - compare yourself to someone who is in the same position as you are).

So, there are the reasons why I don’t attend or present at conferences. How do we adjust this? Well, JAOO certainly has set the standard - I hope other conferences follow suit and find new and innovative ways to get women to their conferences.

The Women in IT meeting was quite fun and well attended - it seemed like it was the first time many of the people there met with others to talk about being a women in IT. I was also glad to see that this was not attended only by women - four of our ThoughtMen came along. I thought this was fantastic - how cool is it that I work for a company where the guys not only want to find out more about the problem and help where they can but are also willing to miss out on other user groups, such as the Java and Ruby groups which also met at the same time.

During the session, we had three of the conferences speakers (who were also women) form a panel to share experiences and exchange ideas. These speakers were Rachel Reinitz, Linda Rising and Rebecca Parsons. I have been to many of these sessions before, but I was entered a little skeptical and a bit jaded but I left reenergized to helping solve some of the problems.

During this discussion, I think I realised that the topic “Women in IT” was such a broad one, and there are so many issues surrounding it, that when you get a group of people to talk about it as a whole you get too many cross cutting conversations. So, I am going to attempt to list the issues that I see comprise the broader “Women in IT” ‘problem’.

• Not enough women entering maths/science/technology
• Lack of self confidence to speak up
• Lack of involvement in the community and open source projects
• Lack of women at conferences (attendees as well as speakers)
• Lack of role models
• Perceived glass ceiling and salary offsets
• Perception around women as mothers vs women as employees
• Employees don’t do right for humans
• Women are not networking as well as men are
• Treatment of women at social events/in the workplace/lack of respect for other humans
• When you try to do something positive, you get hit with people crying discrimination
• Filters women apply to situation to make them seem worse than they actually are
• Subvert harassment through jokes and conversations
• Lack of awareness with men to understand what is OK
• Women not respecting the problems other women have faced.

I hope to build out a series of posts around these points, explaining what I believe is the issue, suggestions of some solutions, and what I have seen the community do to try to help address these problems.

If you think there are parts to the problem that I have missed, tell me about them in the comments section!

Rendering template of a string without any holes

1
2
3

template = "This is a string without any holes in it"
engine = Slippers::Engine.new(template)
engine.render #=> "This is a string without any holes in it"

Filling in a hole within a template

1
2
3

template = "This is a string with a message of $message$"
engine = Slippers::Engine.new(template)
engine.render(:message => "hello world") #=> "This is a string with a message of hello world"

Rendering a subtemplate within a template

1
2
3
4
5

subtemplate = Slippers::Template.new("this is a subtemplate")
template_group = Slippers::TemplateGroup.new(:templates => {:message => subtemplate})
template = "This is a template and then $message()$"
engine = Slippers::Engine.new(template, :template_group => template_group)
engine.render #=> "This is a template and then this is a subtemplate"

Applying an object to a subtemplate

1
2
3
4
5

subtemplate = Slippers::Template.new("this is a subtemplate with a message of $saying$")
template_group = Slippers::TemplateGroup.new(:templates => {:message_subtemplate => subtemplate})
template = "This is a template and then $message:message_subtemplate()$!"
engine = Slippers::Engine.new(template, :template_group => template_group)
engine.render(:message => {:saying => 'hello world'}) #=> "This is a template and then this is a subtemplate with a message of hello world!"

Applying an object to an anonymous subtemplate

1
2
3

template = "This is a template and then $message:{this is a subtemplate with a message of $saying$}$!"
engine = Slippers::Engine.new(template)
engine.render(:message => {:saying => 'hello world'}) #=> "This is a template and then this is a subtemplate with a message of hello world!"

Render a subtemplate using a different rendering technology

1
2
3
4
5
6

age_renderer = AgeRenderer.new
subtemplate = Slippers::Engine.new('$first$ $last$')
person = OpenStruct.new({:name => {:first => 'Fred', :last => 'Flinstone'}, :dob => Date.new(DateTime.now.year - 34, 2, 4)})
template_group = Slippers::TemplateGroup.new(:templates => {:name => subtemplate, :age => age_renderer})
engine = Slippers::Engine.new("Introducing $name:name()$ who is $dob:age()$.", :template_group => template_group)
engine.render(person) #=> "Introducing Fred Flinstone who is 34 years old."

Select a renderer based on the type of the object to render

1
2
3
4

person = OpenStruct.new({:name => {:first => 'Fred', :last => 'Flinstone'}, :dob => Date.new(DateTime.now.year-34, 2, 4)})
template_group = Slippers::TemplateGroup.new(:templates => {:name => Slippers::Engine.new('$first$ $last$'), Date => AgeRenderer.new})
engine = Slippers::Engine.new("Introducing $name:name()$ who is $dob$.", :template_group => template_group)
engine.render(person) #=> "Introducing Fred Flinstone who is 34 years old."

Use the specified expression options to render list items

1
2
3

template = 'This is a list of values $values; null="-1", seperator=", "$'
engine = Slippers::Engine.new(template)
engine.render(:values => [1,2,3,nil]) #=> "This is a list of values 1, 2, 3, -1"

All we want our template engine to do is read a string which has holes in it, and replace those holes with the desired string, much like mail merge. Luckily for me, there is already a templating engine which enforces strict separation of model and view by only supporting these strings with holes - String Template. String Template is originally created in Java, however there has been subsequent ports to C# and python. It is opinionated, and I like it’s opinions. (And if you prefer permissive views, I would recommend you reading about the origins of String Template before completely ruling it out.)

Unfortunately, when I started to try out Ramaze (a great web framework for ruby - much better than rails imho) I looked around for a port of String Template to ruby, but couldn’t find out. So, I decided that if no-one else would port it, I would…and so Slippers was born.

Slippers is a strict template engine for ruby, supporting the syntax from String Template including anonymous template, named templates and template group directories but also goes beyond this to allow you to use your own renderers. Nearly all the useful constructs from String Template have been ported, and you can see the comparison on the Slippers vs String Template page.

In creating Slippers, I have been surprised to find how many development tools for ruby can now be found “in the cloud” (ie on the web):

• Slippers code repository is hosted on github.
• Slippers has been test-driven, and I have a CI build at runcoderun.com. As you can see, I have also made it Ruby 1.9 compatible.
• The gem can be found on gemcutter. To install:

  1 2 3 4

  # Run the following if you haven't done so before: $ gem sources -a http://gemcutter.org # Install the gem: $ sudo gem install slippers

Ramaze now supports Slippers as a view engine, as of gem version 2009.10 (also on gemcutter).

More information about Slippers can be found at http://slippersrb.com