Marcin Floryan

It was a beautiful, crisp, cold winter morning today with temperatures finally dropping below zero so I have really enjoyed my cycle to work. I bet there are others, who, on the other hand, didn’t share my weather enthusiasm as they might have had to give up those precious moments of morning sleep to get up earlier and defrost their cars. It got me thinking about the temperature in our offices.

I think it’s a fair assumption that most of us work in some sort of open-space environments equipped with the usual comforts of temperature control; heating in the winter, air-conditioning in the summer; and the little innocent control dial somewhere in the corner. I have often observed all those interesting, intricate patterns of human behaviour directed at the lonely thermostat.

There will be some, who come in the morning, before most of us even start thinking of getting up, to get a grip on the control and set their favourite value. Others, who come later, will perhaps think: “oh no, it’s too hot in here, again” or the contrary “I have missed my cardigan again”. A brave individual will sneak up and turn the dial up, a few hours later someone else will pretend to ramble around and accidently fiddle with it, turning it down. Perhaps, like in one of the offices I worked in, people will start complaining to the building administrator and the thermostat will get locked in an ugly metal box. Now people will continue their battle over comfortable temperature with a barrage of emails.

All this is mostly being done covertly, quietly, often causing at least mild levels of personal agitation.

It might not be as trivial as it seems. Comfortable working environment is an important factor in how well we can do our jobs. If I can’t concentrate on the new piece of code I’m trying to write because my fingers are numb I’m prone to making more mistakes. There is also another aspect, one I’m more interested in –we seem unable to discuss the problem openly together. Perhaps we assume that, since clearly everyone has slightly different temperature expectations, it’s impossible to reach a consensus. Did we ever try to test that assumption? How would we go about doing it?

Surprisingly, it may turn out, tackling the office temperature issue will make it easier to handle other heated debates.

Or maybe it’s another argument for private offices.

I was writing some WCF services recently (driving development with unit tests, naturally) and eventually bumped into the problem I guess all authors of WCF services eventually bump into. I had to use the OperationContext.Current.

A bit of googling revealed, unsurprisingly, I’m not the only person struggling to mock the OperationContext. It turns out there is also a solution out there. It’s called WCFMock with a nice description is this blog post: “WCFMock, a mocking framework for WCF services“.

While it looked promising I have two reservations about it. The first one hides in this line:

1
2
3

#if DEBUG
using WebOperationContext = System.ServiceModel.Web.MockedWebOperationContext;
#endif

When doing TDD one of the rules I try to follow is never to bend the production code for the requirements of the test. Sure, I design the code so that it is testable. However, the production code is there to fulfil the functional and non-functional requirements (or to deliver value through working software if you like) and I want to make sure I test the same code that will run live.

The other reservation I have with the proposed approach is that it doesn’t really express the dependencies of the piece of code in question explicitly.

Look at the GetProducts operation on the ProductCatalog. The following line is where we need the context:

1

WebOperationContext.Current.OutgoingResponse.ContentType = "application/atom+xml";

But we only need the context because we want to set the correct ContentType on the response. Using the context just happens to be the way to achieve it.

Perhaps we could replace this line with a more explicit one like this (and there’s probably still more to be improved in terms of naming)

1

operationResponse.SetContentType(ContentTypes.Atom)

We replaced a reference to OperationContext with a reference to operationResponse. The operationResponse should be defined as an interface and can be injected in the constructor just like the repository is in the example given. Our test method now becomes slightly shorter and more readbale

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

public void ShouldGetProductsFeed()
{
    {
        var respository = new InMemoryProductRepository(
                new List<Product>{
            new Product { Id = "1", Category = "foo", Name = "Foo1", UnitPrice = 1 },
            new Product { Id = "2", Category = "bar", Name = "bar2", UnitPrice = 2 }
        });
        var operationResponseHandler = new Mock<OperationResponseHandler>();
 
        var catalog = new ProductCatalog(repository, operationResponseHandler.Object());
 
        var formatter = catalog.GetProducts("foo");
        var items = formatter.Feed.Items;
 
        operationResponseHandler.Verify(x => x.SetContentType("application/atom+xml"));
        Assert.AreEqual(1, items.Count());
        Assert.IsTrue(items.Any(i => i.Id == "http://products/1" && i.Title.Text == "Foo1"));
    }
}

I personally prefer this approach as we don’t need to go into the details of the OperationContext. Naturally, we’ll have to implement our new interface for production and it will eventually have to reference the context, but we can keep that bit separately and test it in an integration test. I would probably split and name the above unit test as well, but that’s a completely different story.

I’m reading Flow at the moment, I’m looking at whats going on at Stoos, I’m recalling my different work experiences… and I’m thinking what might be wrong with the world at work.

Perhaps the problem with management these days is not just a problem of management. What if we also contributed by accepting the unacceptable status quo, by remaining silent when we should speak up, by holding on to a job we should have left long time ago? By forgoing the fundamental rights we should have had at work? Like these rights that just came to my mind:

• right to respect and dignity
• right to express my opinion
• right to influence my work
• right to enjoy my work
• right to be happy

Yes. I have a right to enjoy my work. If I don’t enjoy my work it is my duty to speak up. It is my duty to take action, support change or leave the current employer. Regardless of my position, regardless of my title, regardless of my responsibilities.

I think of these rights not only as entitlement though, but also as an opportunity, a challenge, an obligation (via @auxbuss) and a direction. I can’t expect these to just happen to me, I have to consciously invest my psychic energy to continually improve in the direction they indicate.

What if we all did that?

We live in a complex adaptive system. It is called a biosphere. As complex systems go, they are often themselves composed of complex systems at a smaller scale. A big fractal if you like.

Any human social group-based endeavor in a cultural and social system is a complex adaptive system. Software development teams and organisations are one example.

Complex adaptive systems have relationships that contain feedback loops and are non-linear. Much as we would like, it is not possible to know, with absolute certainty, what the effects of our actions and changes might be. Ultimately what it means, is that for all the changes and improvements we may try to create in a system, there will be some that will fail. We have no choice, we must embrace and accept failure.

I was in Kraków last week for the ACE! conference (I was when I first wrote this draft, it’s been 8 months now) and in one of the presentations Barry O’Reilly made a salient point that “we should not waste our failures“. You might be tempted to rephrase it in a common adage “we should learn from our failures“. There is however a big difference.

We don’t learn from failures

I often think the readiness to learn from one’s failures is a convenient excuse. I subscribe to the view which Kevlin Henny shared in his lighting talk at the #openvolcano2010 openspace that we cannot learn from failure. Failure exposes what artists call the negative space. It doesn’t tell us what to do, only what not to do. (More on this perhaps another time)

I have another recipe to follow Barry’s advice: anticipate success and be prepared for failure.

Anticipate success

When you set out to create change or introduce something new – embrace the mindset of success. Precondition your own brain and those around you to think positively, believe that the outcome will be favourable. Create your own luck. It is surprising how this attitude can actually make a difference. It is the only sensible starting point.

Be prepared for failure

While you strive to realise the self-fulfilling prophecy of success remember to take the rose-tinted spectacles off for a moment and prepare for the eventuality of failure before you begin. You’re idea of the desired outcome through specific actions is always based on a set of assumptions about the structure and behaviour of the system. Make those assumptions explicit, write them down, verify them with others and then measure your progress.

If you succeed you will know your assumptions were right or at least lead you in the right direction. If, however, the opposite becomes the realisation, you can go back and questions the assumptions you’ve made more rigorously and iterate again from a slightly different, and hopefully better, place thus consciously and deliberately taking the experience of your failure forward.

So please, don’t waste your failures – anticipate success, be prepared for failure and make your assumptions explicit.

I bumped into this video on Facebook (via Murray). It’s supposed to be an experiment whereby parents gave their kids a terrible present and watched the reaction.

I’m not sure I would want to give my child a half-eaten sandwich. Still the kid’s reactions do make us laugh.

It also made me think.

Why do we find these kids funny? They just honestly express their disgust at a disappointing gift. Does that happen in real life?

Yes.

Remember the last time you got a shoddy watch with a company logo for your 5th anniversary on the job? A pen to celebrate gaining a company-wide accreditation? The Christmas bonus so embarrassing you quickly donated it to charity? Maybe a golden star for a project well delivered (that is after you ruined your Christmas, Easter and summer holidays working late)? The stars I remember were glass.

Did you honestly like any of these gifts?

Maybe you’re lucky and the new cuff links with the company logo really are nice.

Or do you have the skills to tactfully yet truthfully, with respect, speak about these terrible presents?

Maybe then we wouldn’t find these kids nearly as funny. Perhaps they can offer us a valuable lesson.