Better late than never! Here is my rather length wrap up of QCon London which I attended in February.

TL;DR:

Main topics of conversation (at least my perception of the conference) were REST (How to do it ‘properly’), and micro-servicing / component-based architecture: breaking up big apps into independent components that are more easily ‘managed’ (ie. refactored, rewritten, deployed, etc).

My favourite talk: Steve Sanderson’s “Rich HTML/JS apps with Knockout.js and no server” – thoroughly recommended.

Also worth a look was Mike Hadlow’s EasyNetQ talk – bringing RabbitMQ to .NET developers with an easy-to-use wrapper that can get you creating distributed systems in relatively little code.

Crowd-favourite was Damian Conway’s “Fun with Dead Languages” – definitely watch this for the most entertaining keynote I’ve ever seen!

QCon (InfoQ) will be publishing the talk videos online over the next few months. See their video calendar to see what’s available now.

</TL;DR>

First up I attended Dan North’s tutorial titled “Accelerated Agile”. Dan explained that he has spent a lot of the last few years at a company that weren’t practicing Agile in the way that we know it (his LinkedIn describes this role as “Lean Technology Specialist at DRW Trading Group, Chicago”. They were breaking most of the rules and creating their own, but also meeting with much success. Framing what he observed there within his years of  agile experience beginning in the 90′s, he has boiled down a collection of patterns that he is now wrapping up and presenting in his “Accelerated Agile” course. They range across both engineering practices and organisational practices, and I’ll enumerate a list of those I found most interesting from the day of training here.

But a little history to start. Dan explained that Agile initially emerged in the 90′s to combat the unpredictability of software development, where massive projects would be worked on for years without end users ever seeing them, and eventually get canned several years into development as things had degenerated into a mess. This rung true for me as until recently I worked at an organisation that had this exact problem – a big, slow, clunky enterprise system where tech debt was never paid off and most of the core technology older than 5 years! However we needed to upgrade our definition of the success of Agile as predictability is not that important anymore. In my own experience I have time and again seen that prioritizing predictability has a negative affect on product quality, with specific reference to user experience. I have long thought deadlines to be the single biggest evil in software development and it is good to see the tide turning towards quality over predictability. After all, who cares how long it takes? Just make it good when it arrives!  Nobody remembers that a product was late, only that it is great! I think there are many project managers that still need to learn this lesson. Anyway, back to Dan’s tutorial – here are some of the patterns he revealed:

3 Phases of Activity:

An individual/team/organisation is typically in 1 of 3 phases:

1. Explore : Goal is to learn; behaviour is around experimentation and discovery. “Will this work?”

2. Stabilise : Goal is to optimise for predictability, repeatability, minimize variance. “Ok we know (or highly suspect) this works, let’s build it out and provide a rough schedule given what we’ve recently discovered.”

3. Commodotise: Goal here is to minimize cost and maximise efficiency. “Ok we’ve built it, now let’s scale it up!”

The first two are probably most relevant to software product development. I think Ops/DevOps probably think about number 3 a lot more.

Dan said that as an individual/team/organisation, we need to be deliberate about what phase we’re in and use the corresponding criteria to judge success. One contender for Quote of the Day from the audience was  that the “business is often in Explore mode while expecting product delivery to be in Stabilize mode!”.

One further observation from the floor which I found interesting was that different personalities favour different phases. For example, some developers love to play with the new stuff (Explore) but get a little bored when having to build out an entire product or feature once the novelty wears off. Other developers aren’t natural explorers but are OK to just get through building out a product once they’ve been shown/taught what new tools to leverage.

“Fits In My Head”

Here Dan talked about the importance of conventions across the codebase, and the ability for engineers to be able to effectively ‘reason about’ the codebase. One of the negative side-effects of TDD is that it encourages the emergence of ‘fractal systems’, allowing developers to be ‘intentionally ignorant’ of parts of the codebase outside of the classes-under-test that the engineer is currently working on. Over time you end with several different ways of doing the same or similar things, which makes things difficult to reason about and violates the principle of least surprise.  I am a strong believer in this concept but at the same time my experience tells me it’s not the easiest thing to stick to conventions for an infinite period of time as better ways to do things are constantly emerging, and it is usually not plausible to go through an entire codebase to update the way we access data, for example, but has to be upgraded piecemeal. However, I am writing this a few days after having refactored some code at work from getting a list of Countries in 5 different ways using 3 different representations for Country, so the point is not lost! I think in the end it is a balance, but certainly more software teams have to be more deliberate and public about their conventions, and allow developers only to break form convention when the new/different way of doing things is demonstrably better and going to itself form a new convention!

“Short Software Half-life”

Dan started this one with question to the room: “How long does it take on average before half of code in your codebase might be rewritten”. The average from the room was 2-3 years (I think in reality it might even be much longer than this for most enterprise apps). Dan wowed the room when he revealed that in DRW, for some products, it was 6 weeks! He recounted that they might build a new product or feature in one language, and end up writing the next iteration of that product from scratch in a new language, using the knowledge they’d learned both on a technical and product side, and end up adding more value in a shorter amount of time just because they’d started from a blank slate. This seemed a little extreme at first but then I started thinking about how much time we spend refactoring and upgrading our codebases! For some products it may well be worth starting from scratch and that using the latest tools and frameworks, together with the new product-related information we have from the previous version, it is possible to build a better product in a shorter time, with less code and with more agility and better maintainability going forward too. After all, source code is a liability, not an asset. This practice is one that becomes a lot more plausible when you have effectively broken up parts of your big application into componentized modules, and this was a recurring theme for the rest of the conference. This also puts you in a position where you can rewrite certain components in different languages or platforms that might suit the job in hand a lot better.

“Blink Estimation”

Another practice Dan said he saw a lot at DRW was Blink Estimation. This is basically getting a few experts in a room, talking about a project a little bit and then guessing how long it would take. No Feasibility Studies, no Impact Analyses, no Gantt Charts, nothing. “It’ll take about 6/8 people about 6/8 months.” This way of working is obviously only feasible if your organisation supports it (ie. supports the flexibility needed when 6 people turn into 8 and 6 months turns into 10!). This goes back to prioritizing outcomes (good quality products with delighted users) rather than developing until an arbitrary deadline. Dan reminded us that he thinks that too often way too much effort is put into planning and estimation and I agree. That said, in order to practice Blink Estimation he did say that you need “Experts estimating, an expert messenger (who can manage expectations effectively) and an expert client (who knows their business really well and can work with the developers to articulate what needs to be done). Working in a consumer-orientated website company as I do means the constraints are not as tight as consultancy, and deadlines are relegated to being guidelines while we’re constantly re-evaluating whether to spend longer on a project or feature or switch to delivering value in a another part of the organisational eco-system.

As usual with these things, I found myself observing that these practices are only executable in a relatively progressive organisation with relatively passionate and engaged people! Still, if you’re in an organisation like that, it’s good to either have confirmation that some of the things you are already doing are ‘emerging best practices’ or get some idea of what practices you should be engaging in next.

That’s the tutorial day done, now on to the conference.

Of course much of the fun in a conference is actually attending it, absorbing the atmosphere, chatting to fellow developers in the Open Spaces and learning a thing or two in the live talks and demos. But here I’m going to summarize a few of my favourite talks and link to the videos.

Barbara Liskov’s keynote was the first order on the opening day. This was mostly spelunking around the historical evolution of some programming theory and concepts emerging over time via several academic papers coming out over the decades from the universities most engaged in computer science . Barbara reminded us that some of the concepts we take for granted as being relatively recent inventions were firs thought of in the 70′s!  The keynote was generally very interesting if not particularly actionable. If you’re into your computer science academic papers (who isn’t right), Graham Lee summarized the list Barbara mentioned very well.

GOV.UK – Paul Downey, Technical Architect.

This was an interesting talk recounting how Paul’s team essentially needed to deliver a brand new site serving much of the content of the DirectGov site (redesigned and updated) and seamlessly slip it online without much fuss, redirecting all links to the old DirectGov site to to their Gov.uk equivalent to cater for so many bookmarks to the old site, including physical products! The team gradually redirected more of the traffic to directgov to gov.uk, eventually culminating in a switch off of the old site on 17 October 2012.

Much kudos needs to go to the team as a quick surf around gov.uk and you can see how useful and easy-to-use it is, with the content far superior to what came before.

Road to Rest – Rickard Oberg

Rickard’s talk centred around the road to rest in his application and deciding how to expose his rest services. While initially exposing his data model, he ended up taking his REST services one layer of abstraction higher and rather exposing use cases. So instead of:

/users/user1/changepassword

/users/user1/resetpassword

He’d rather have:

/users/user1/changepassword

/administration/usermanagement/user1/resetpassword

Rickard now recommends exposing REST functionality this way, and reminds us that the best REST services are actually analogous to ugly websites, as they  effectively embed single use cases through a sequence of pages. In the above example one might visit the Administration page, then click through to the User Management page, then click through to User1 page and from that page submit a Reset Password form. Rickard reminds us that we could effectively use this mindset to efficiently expose entire use cases or user journeys from a single intuitively designed REST endpoint. This also means you are able to refactor your domain model underneath your use case layer more flexibly than if you exposed your model directly to REST endpoints.

Mark Nottingham: HTTP 2.0

This one was interesting too, as I had no idea that “HTTP 2.0″ was even in development. With HTTP 1.1 over a decade old, there is obviously room for improvement, and Mark believes that HTTP 2.0 will change the way we design, manage and operate the web. The IETF HTTPbis working group is starting with Google-developed web network protocal SPDY as a base point, and hoping to shape HTTP into something that better fits the way we use the web today. Mark pointed out that these days pages are usually over 1MB in size and average 200 requests for various content. Also, mobile usage is growing but that platform is burdened by slower speeds and despite 4G will be for the forseeable future. HTTP in it’s current form doesn’t lend itself to these challenges, leading us to develop ‘hacks’ like CSS spriting and domain sharding, to be able to work around these shortcomings. Mark pointed out that the working group currently includes people from Microsoft, Google and Twitter but is not a ‘corporate consensus’ but rather just a group of engineers around the table.

If you’re interested in HTTP 2.0, you might want to check out the Working Group page and/or the draft spec on GitHub for more information.

Ward Cunningham – A Federated Wiki

Ward is working on a new federated wiki system than can pull in data from several sources into one dynamically curated outlet. There is quite a lot of support around physical inputs, like thermometers and oscillators. This looks to m pretty much like a tool to build big dashboards and live/dynamic knowledge bases. If you want to know more, check out Ward’s 8 minute TED talk for more. Ward’s introduction in the first few minutes are not very clear but skip to 7 minutes in for a demo of the wiki itself.

Also, here is another example of federated wiki: http://fed.wiki.org/view/how-to-wiki

Ward also has more on his github page.

Although this looks cool, I’m not sure it’s relevant beyond certain niche communities…

Mike Hadlow – EasyNetQ

I know I’m a little late to this party, but I’ve only recently become interested in distributed architectures and the .NET tools in this space. Mike has a good presentation style and this talk was one of my favourites. Mike covered why firstly you’d want to use RabbitMQ for messaging in general, and then why you’d want to use EasyNetQ to bring it into your .NET architecture.

Why RabbitMQ?

- Brokered instead of Brokerless

- RabbitMQ is open source and free, with commercial backing from VMWare

- Implements AMQP, which is based on the mature and battle-hardened Erlang-based Ericson OTP telecoms protocol

- Multiplatform

Why EasyNetQ?
Mike said that EasyNetQ has been inspired by NServiceBus and MassTransit, but because those tools weren’t ‘ready’ two years ago when he started on this, 15below chose to do something original. In terms of popularity (Nuget downloads), I see that while NServiceBus is way out in front with ~70k downloads, EasyNetQ is catching up to MassTransit with both around 16k.

Mike’s sell for EasyNetQ included the fact that knowing your way around AMQP is not easy, so EasyNetQ takes care of things like serialization, threading strategies, and managing connection loss, and is also more opinionated on things like QoS default settings and error handling.

On a slide summarizing 15Below’s experiences, Mike related that having your messaging in code turns out to be a big benefit over using database-as-queue. Some might describe it as a black box but is a very reliable black box compared to SQL Server which can be ‘touchy’. The sql database is no longer the bottleneck at 15Below. Performance is also great: They’re running a multi-billion pound business and are not even anywhere near RabbitMQ’s ‘red lines’.

Mike wrapped up by saying that this is in his opinion one of the better ways to build an SOA, and urged us to check out EasyNetQ today!

Steve Sanderson: Knockout + Azure + PhoneGap

Steve now works for Azure Mobile Services, and his talk demonstrated doing a KnockoutJS site but with no server, instead hooked up to Azure, and finally doing the minimum porting required to build a native iOS app (effectively containing the web app he just built). I’d never seen or played with the insides of Azure and I must say I was really impressed with it – will possibly migrate from AppHarbour before long!

KnockoutJS is around 3 years old now, and Steve has demo’d KO a few times before, so I’m not going to detail that much of that now – for more info check out my Knockout Kickstart post or Steve’s Mix11 talk.

Side note – Steve was using a lightweight editor called docpad which looked quite cool.

On to the the Azure Mobile Services part. So Azure in this case just acts as a db-over-http (REST). You create a new ‘Mobile Service’ which seems like a nosql db, with the following kind of (psuedo)-code:

var client = new WindowsAzure.MobileServicesClient(urlToYourAzureApp);
myTable = client.getTable(tableName);
myTable.insert(data).then(callback); //asynchronous

myTable.read().then(callback); //callback function would update the viewmodel

It operates in schemaless mode until you switch mode to locked – until then it just infers schema, very handy for development.

Azure also supports easy integration with Facebook/Twitter/Microsoft/Google for user authentication, eliminating the need to develop your own ID scheme. A simple client.login(‘twitter’).then(callback) is all that is needed to invoke the right popups and user flows – easy peasy!

To get going on the native iOS platform, Steve used PhoneGap by firing up a console app that just created a barebones PhoneGap app, creating an xcode project with a few standard iOS-like files and folders, but with a few files and folders more familiar to web developers as well. Steve was able to drop his web app straight into the PhoneGap directory structure, and with a couple of tweaks, could run the app inside the native container! This was the really impressive part of the demo.

Steve’s hot tips for developing a mobile app this way:
- Leave the iPhone simulator behind, rather develop in the browser for a quicker feedback loop.
- Writing PhoneGap plugins to be able to access native functionality are easy, so don’t be shy.
- Use commercial artwork – paying for a few images and icons etc will save loads of time and make it look decent.
- Use CSS transitions instead of $.animate() – javascript performance can drag in a mobile app.

“And Finally”

Over the 3 days of QCon I picked up that one popular theme was ‘micro-servicing’, or breaking up what have in the past been monolithic apps into smaller components:

Dan North talked about micro-servicing being a good way to enable separate development, deployment, etc of a bigger application.

Mike Hadlow said building micro-servicing joined via messaging is a good way to build stable, scalable, robust SOA’s.

Paul Downey of GOV.UK said it was a useful way to get their stuff done but must be done carefully, for example avoid slicing vertically (ie. a “data access” micro-service) but rather not horizontally (by app).

And now for something slightly different:

Last QCon I noticed a few re-occurring phrases that remind me that sometimes these conferences and the community in general can be quite an echo chamber! These aren’t technical topics but just grammatical turns of phrase that seem to catch on, which as an amateur linguist I’m always interested to observe. Last year there were at least 3 or 4 that I can’t remember now but this year I only picked up one: “reason about”. A lot of people were talking about how easy or difficult something is ‘to reason about’!

QCon remains a really great conference I look forward to QCon London 2014!

Knockout Kickstart

Posted: April 18, 2013 in Uncategorized
Tags: ,

A few weeks ago I waded into KnockoutJS, using it for a simple CRUD screen at work. In short it was a really good experience and I was amazed at how little javascript I had to write to get everything going. I’m looking forward to combining Knockout with other JS frameworks to enable more complex scenarios with as little effort.

However looking for tutorials and example code online, I found some resources that weren’t that good, and then looked some more and found some better stuff. I did find that it took a bit of effort to find decent learning materials – there is a fair amount of confusing and sporadic KnockoutJS content around – so I thought I’d blog what ended up being the most helpful content, in order to save you the hassle. So if you’re wanting to get going, consider the following resources above others.

First, definitely go through the tutorial at Learn Knockout. This covers the basics and leads you to the official documentation that will serve as a great reference to the various building blocks you’ll need to refer back to (and copy code from!) when building your page/site. By the time you finish the tutorial you’ll understand the basic structure of a Knockout page, and the steps involved in building the necessary parts.

Second, definitely view Steve Michelotti’s excellent PluralSight tutorial “Knockout Fundamentals“. I actually watched the TekPub Knockout screencast first but found this didn’t actually cover the fundamentals as well as required to actually build a non-trivial page. It covered Knockout in an ad-hoc manner, missing some key pieces around handling arrays, rather than the logical and cumulative treatment (building up a big app over several videos) that Steve’s video provides. Steve’s course covers all the basics systematically, so you will cover everything you need to build a proper page. The Pluralsight course also ends up with more sophisticated app than the one in TekPub, stretching your KnockoutJS knowledge further on completion.  If you are not a subscriber to PluralSight, I would heartily recommend signing up (lots of great content) but failing that, the trial will give you free access to your first 200 minutes, which will cover the 1h40m KO course.

Just these two resources should be enough to get your first Knockout page/site built, but once you start hitting those edge cases and yearning for some advanced features, the following posts helped round out my Knockout knowledge even further:

Ryan Niemayer’s blog is generally pretty good, but here are two articles that are worth reading first:

Hope that helps! Next up I am going to discover how DurandalJS builds on top of KnockoutJS to make developing SPAs even easier!

 

My previous blog post on finding a new developer job in London reminded me of a blog I posted internally (at my previous company) last year summarizing my experiences with StackOverflow Careers when hiring developers in London. Here is a cross-post for your enjoyment!

Finding good software developers is hard. So I’m constantly looking for new and innovative ways to find those great developers. Some of the ways we currently go about it include:

  • Agencies
  • A job advert on StackOverflow, a hugely popular programmer’s Q&A website
  • Twitter + Facebook
  • London .NET user groups
  • A physical advert on a notice board at a local training agency

Using these methods we’ve recruited two great developers over the last few months, however filling my last vacancy was turning out to be tricky (exacerbated by a seemingly massive August/September slowdown). Recently we decided to try a new avenue: the StackOverflow candidate database. This is a tool that allows you to search a database of developers that have created profiles on the StackOverflow site when wanting to post questions about software coding and wanting to answer other programmers questions. This is an important difference to sites like LinkedIn because the primary motivation to have a profile on StackOverflow is to participate in an online community of programmers, not to look for job. Consequently, the programmers that one can find using the StackOverflow candidate database are on average usually higher skilled and more passionate about their craft than other online candidate databases. There are a variety of criteria to search on, enabling me to quite specifically identify candidates that would suit the role.

SO

So we purchased access for one week. I managed to message over a dozen eligible candidates and then I realized a curious thing. Even though the candidates that I had message had marked their profiles as “actively seeking positions”, it turns out that this probably means something more like “looking for opportunities if that opportunity is a huge pay increase to go to Google or Facebook”. In other words, developers might indicate on their profile that they are active seekers but as they haven’t actually taken the step to hand over an updated CV to a recruiter, it would take more than a message out of the blue to ‘dislodge’ them from their current employer. While all replies were professional and complimentary of the role on offer, most candidates were not open to our new opportunity.

Nevertheless, we were able to find one developer interested in what we had to offer; within a week we’d interviewed him, liked him and he’d accepted our offer!

SO2

The effort to hire great people, I suspect in any industry, often requires a lot of energy, guile, patience and persistence. You never know when that advert on a random job board or networking at that industry event will turn up your next great addition to the team. It pays to always be on the lookout, and in the mean time, constantly strive to make your team/department a better place to work. The StackOverflow candidates database is definitely something we would try again in future should more developer opportunities become available.

“The key for us, number one, has always been hiring very smart people.”

- Bill Gates

As transparency seems to be the new black (I’ve read quite a few posts on HN recently about people fully documenting their earnings, for example), I thought I’d blog about finding a new developer job in London. Nothing too exciting but visiting various shops, comparing interview processes, and working with recruiters is always…entertaining.

Firstly, here’s a quick run down of the places I visited and some notes of my experience/observations (WordPress table editing is not so good, so excuse the rudimentary layout)

Company (type) Source Interview Stages Date Outcome Notes / Observations
Digital Agency in Croydon StackOverflow 1st (Face2Face) 7th Nov No callback First interview! This one was all about getting experience (I would probably never work in Croydon…); Had to hack a to-do list together in 20 mins. Unpracticed at Razor so this probably took longer than it should’ve! Good guys but company not really progressive enough in terms of technology
Shrink-wrapped Accountancy software in Charing Cross Jobserve (urgh) 1st (online test); 2nd (30 min phone interview) 9th Nov Not taken forward (by me) Online test was C#/CLR trivia galore (got 64% doh); phone interview was 3 guys asking some random questions, not very coherent. Not the best interview process in the world but no loss as unlikely that I’d work in something as exciting as accountancy!
Shoreditch Music industry startup StackOverflow 1st (pair programming f2f interview) 12th Nov No callback This was intimidating as I had/have these guys on a pedestal, especially the Director of Engineering who is active in the community and has seemingly done an amazing job using progressive ideas to create a successful engineering outfit. Consequently stuffed the interview up, howlers include trying to mock a concrete class with Moq and not pointing out mutability as problematic. At least I learned about the Chain-of-Responsibility pattern and was able to show them FluentAssertions. All is not lost!
Big City Management Consultancy StackOverflow 1st (30 mins HR phone interview) 15 Nov Not taken forward by them Pictured myself wearing suits everyday and going from client site to client site hacking in fixes in a tech debt creation frenzy (am I being harsh on city tech?). Interview went well but in the end I was “not a match for their requirements”, most likely because I said I wasn’t going to do any Java…
Charity platform Recruiter 1st (Online test); 2nd (f2f w/ CTO); 3rd (f2f w/ Architect & Technical Manager) 19 – 23 Nov Offer Accepted Great looking company that looks after its people and is technology-focused; liked the people I met in the interview – enthused, passionate, skilled, etc. High retension, always a good sign. Good tech stack, office space, progressive culture etc etc. Job done!

Some key observations and takeaways from the whole process:

  • Recruiters are the usual annoying and manipulative lot but actually finding a decent one is possible and can make a big difference.
  • Overall though, I’d definitely start with the StackOverflow job boards (avoid Jobserve like the plague!) where you can find lots of decent companies and also do THEM a favour, as if you’re recruited through SO their costs are lowered by around 7k-10k per role in recruiting fees. I did note that SO is slowly starting to “jump the shark” though, carrying ads from Big Consultancy Inc who aren’t really doing interesting things with tech. Along with SO who will feature most of the bigger, more established outfits, also be very sure to pay SiliconMilkRoundabout a visit at one of their twice-yearly shindigs, where there are many much smaller but very exciting companies who are looking for adventurous types to join their cutting edge startups. If working on something interesting and novel is high on your list, SMR is a must.
  • Another observation I made was the presence of huge variance in interview techniques and processes. In my opinion it turns out that the places you would rather work tend to avoid online tests of the multiple-choice questionnaire type, and have some element of your own code, whether that is pair programming at the interview or submitting your solution to their problem question over email. In my own hiring I have had the most success with:
    • 1st stage: CV screening that I do, screening on modern tech (ORMS, IoC, TDD etc) and passion for the craft (OSS/blogs/twitter/etc)
    • 2nd stage: 45 min phone interview going over technical basics (including questions like “What problem does IoC solve?”) and some recent work experience; If successful I give email a programming challenge and ask them to submit a project that solves it.
    • 3rd stage: 2 part face-to-face, 1st part soft-skills, 2nd part hard-skills where we talk about his/her code submission and possibly ask them to extend it in the interview.
  • Finally, the last observation I made was that it is seemingly quite a small world in the London tech scene! New hires in my old company were from places that invited me to interview, fellow colleagues from work were being submitted for some of the same jobs I was, some through the same recruiters, some through different recruiters, etc. Felt like a bit of a crowded space at times!

Anyway, my job is done as I’m now at a much better outfit than before, so hopefully I won’t have to traverse the recruitment maze again for a long while and I can get back to creating software and help building good teams. Hope you find this little anecdote interesting!

NBuilder is a tool for .NET that allows the easy creation of test objects. It provides new instances of any class you provide (as a generic parameter) and those instances are populated with garbage data. I find that using NBuilder for test objects is a nice explicit way to show that the test does not care about the data but just needs an object in a decent enough state not to produce NullReferenceExceptions.

So given:


public class ComplexType
{
    public string Name { get; set; }
    public int Number {get;set;}
}

You could have the following test:


[Test]
public void Should_Return_Instantiated_Object_With_Test_Values()
{
    var result = Builder<ComplexObject>.CreateNew().Build();
    result.Should().NotBeNull();
    result.Name.Should().Be("Name1");
    result.Number = 1;
}

By the way that was also using FluentAssertions.

However, even after a fair bit of Googling I’m not sure why it does not include the creation of child complex objects, recursively. Instead these end up as null. So given:


public class OuterComplexType
{
    public int Number { get; set; }
    public InnerComplexType InnerComplexType { get; set; }
}

public class InnerComplexType
{
    public string Name { get; set; }
}

The following test would fail:


[Test]
public void Should_Return_Instantiated_Object_When_Given_Object_With_Complex_Properties()
{
    var result = Builder<OuterComplexType>.CreateNew().Build();
    result.InnerComplexType.Should().NotBeNull();
    result.InnerComplexType.Name.Should().Be("Name1");
    result.Number = 1;
}

So I wrote a little utility class that helped with this situation (see the Gist here). I have not used it in anger very much yet, so let me know if you spot any potential improvements.

using System;
using System.Linq;

using FizzWare.NBuilder;

namespace MarkGibaud.UnitTest.Utilities
{
    public static class NBuilderUtility
    {
        public static T Create<T>()
        {
            return (T)Create(typeof(T));
        }

        private static object Create(Type type)
        {
            if (type.IsInterface)
            {
                var firstConcreteImplementation = type.Assembly.GetTypes().FirstOrDefault(t => type.IsAssignableFrom(t) && !t.IsInterface);
                if (firstConcreteImplementation != null)
                    type = firstConcreteImplementation;
                else
                    return null;
            }

            var baseType = Build(type) ?? Build(Nullable.GetUnderlyingType(type));

            var complexTypeProperties = baseType.GetType().GetProperties().Where(p => !p.PropertyType.Namespace.Contains("System")).ToList();

            if (!complexTypeProperties.Any())
            return baseType;

            foreach (var complexTypeProperty in complexTypeProperties)
                complexTypeProperty.SetValue(baseType, Create(complexTypeProperty.PropertyType), null);

            return baseType;
        }

        private static object Build(Type type)
        {
            var builderClassType = typeof(Builder<>);
            Type[] args = { type };
            var genericBuilderType = builderClassType.MakeGenericType(args);
            var builder = Activator.CreateInstance(genericBuilderType);
            var createNewMethodInfo = builder.GetType().GetMethod("CreateNew");
            var objectBuilder = createNewMethodInfo.Invoke(builder, null);
            var buildMethodInfo = objectBuilder.GetType().GetMethod("Build");
            return buildMethodInfo.Invoke(objectBuilder, null);
        }
    }
}

Usage is something like this:

[Test]
public void Should_Return_Instantiated_Object_When_Given_Object_With_ComplexType_Properties()
{
    var result = NBuilderUtility.Create<OuterComplexType>();
    result.InnerComplexType.Should().NotBeNull();
    result.InnerComplexType.Name.Should().Be("Name1");
    result.Number = 1;
}

I guess the next step is to integrate this functionality into a fork of the NBuilder project…I’ll save that for a rainy day.

Personal Kanban

Posted: November 7, 2012 in Uncategorized

My software development team at work recently decided to dispense with our Kanban board and move back to Scrum (long story). The result is that we are now working from a ‘vanilla’ Scrum board and I can no longer measure cycle time, see all the work in progress, easily see impediments/bottle-necks, and all the usual benefits that come with a visual mapped value stream.

Wanting to continue on my path to deepening my understanding of Kanban as well as trying it out in different scenarios, I thought I’d give Personal Kanban a try. Jim Benson wrote the book, which I would be tempted to describe as possibly the GTD of the Lean world. Jim’s advice includes that the usual to-do list lacks context and does not do a good job of providing feedback and communicating progress as well as a Personal Kanban (PK) board.

So I’ve created a PK board and put it up in my home office (aka the bedroom):

It’s decidedly low-tech. I have four columns: Backlog, Next Up, In Progress and Done. That’s the value stream mapped. I have four corresponding boxes at the bottom of every work item card, in which I will note the dates that the card moved into a particular column. That’s cycle time sorted. I’ve divided work items into categories like ‘Presentation’, ‘Book’, ‘Blog-post’, etc. That’s the similar-sizing of work sorted (albeit using the hack of categorizing the work, much like t-shirts sizing does for Kanban software teams). Natural space on the board is limited to around 3-4 cards, so that’s the first stab at limiting work-in-progress sorted. I plan to retrospect every 6 weeks or so and record the data (eg. average time to read a book), so that’s the continuous improvement trigger sorted.

I can already report that it helps to focus by forcing me to decide what is important to work on and limiting those options. The power here is as much as selecting what you WON’T spend time on as what you will. With strict WIP limits, you know that the only way you can start reading that next book you’re excited about getting into is by finishing the previous one – a potentially powerful hack. Anything that makes me START less and FINISH more is definitely a good thing.

I hope to report back a lot more in a few more weeks. I’m especially interested to discover the drawbacks of a system like this. So stay tuned!

I could’ve written this post at least 6 months ago, if not more, as it was really later last year / earlier this year that I began to cotton on to a new area of expertise opening up in the world of Software Development: that of Product Management.

Being the Dev Team Leader of a team that has really good engineering but is pretty light on product management skills led me to tweet a quote from Marty Cagan’s book “Inspired: How to Create Products Customers Love” earlier this year:

“It doesn’t matter how good your engineering team is if they are not given something worthwhile to build.”

Increasingly these days I think the problem is (generally) becoming less about building stuff that “doesn’t break” and much more about the problem of building relevant, dare I say useful, software. In the world of enterprise it is still Project Managers and Business Analysts that occupy this space, and these skillsets don’t seem to include the ones that help us determine whether our users are delighted or our stakeholders are enfranchised (eg. Analytics / Customer Feedback, Stakeholder Prioritization models, UX/Usability skills, Agile product development skills like MVP, etc).

I think part of the problem is also wrapped up in the configuration of the present-day large organisation (at least in mine), where the PM/BAs do not act as champions of the product but rather as relatively disenfranchised interfaces between the developers and the ‘business’ users, who for far too long we have mistakenly believed understand how to build software applications. This configuration doesn’t allow for the PM/BA to really own the product, or own a vision for the product, thereby not shouldering the actual responsibility of user satisfaction and resulting in an incoherent or indeed non-existent product strategy, and generally little value derived over a period of time.

I now see two parts to a successful software team. The first part is the software delivery part: Good engineers, good engineering ethic (TDD, refactoring / tech debt payoff, etc), Continuous Delivery capability enabling fast-feedback, etc etc. Input here is requirement (probably a story or epic in Agile terms), output is a piece of working software in production, with hopefully a very short duration of time between these two things. The second part is the product discovery part – “What should we build?”. Input here is things like customer feedback both quantitative (analytics) and qualitative (surveys), the vision of the product (from a Product Management team with a strong sense of what should/could work!), and of course any other stakeholders you might have (people that have a stake in the product but might not use it directly – eg. call centre agents that get more demand when the website goes down). Output here is of course, a new requirement/epic/story.

These two parts are as critical as each other. A cracking product manager might as well go home instead of be frustrated by a team of developers that repeatedly churn out broken software un-timeously. Likewise, customers can see little value in a cracking software development team churning out irrelevant features.

I recommend the reading of two books that talk a lot about this space:

Marty Cagan is part of the Silicon Valley Product Group, and his site has a lot more information about Product Management. This books succinctly summarises what a good Product Manager is and isn’t, and provides a lot of practical advice to get going with better product management practices immediately.

The second book is also hugely popular and focuses on how Lean Principles-inspired product development results in products that matter – must read material for any aspiring Product Managers! Eric Ries also blogs at startuplessonslearned.com.

These two books will fast-track your introduction to this area, and allow you start thinking about whether the activities undertaken by those who are telling you what to build really the ones that uncover what users want.

I’m looking forward to watching how the Product Management space evolves and discovers more about how we can incorporate insight gained from better knowledge of our users into the development of ever more useful software!