Two weeks ago, I ended my consulting firm, Durfweb. It was a difficult decision emotionally, but it was the right decision from a business standpoint. I wanted to get some distance and make some observations about it.

For those of you who are unfamiliar with Durfweb, it was founded on a freemium pricing model, in which the Agile Chuck Wagon podcast was offered for free, with technical and agile coaching consulting services offered at a premium.

What Went Well

This firm was my first foray into running a business. It was an educational experience, and there were some things that went well.

The most successful product of Durfweb was the podcast, the Agile Chuck Wagon. I published 41 episodes over a span of nine months, averaging one a week. I don’t have the statistics in front of me, but episodes of the show were downloaded over 4000 times, which works out to an average of 100 times an episode.

As an Agile Denver conference organizer, Durfweb obtained some gift in-kind donation of services for advertising at the Mile High Agile conference. This generated some additional web traffic and some positive verbal feedback about the podcast. I heard similar comments at Agile Roots, which was also gratifying.

For our premium services, I quoted a per diem base rate that I felt was competitive based on my market research. Most leads accepted the rate I quoted, which confirmed that the price point I chose was reasonable.

What Didn’t Go Well

I learned about the inbound marketing model from a guest lecturer in my MBA marketing class. It’s a pull system in which people discover your product, some learn more, and some decide to purchase. In the model, people start as strangers, which you attract to your site through your blog and social media. I feel like the podcast and the Durfweb website did a decent job of this. These people become visitors. The next goal is to convert those visitors into leads through techniques like calls-to-action, contacts and forms. Here, Durfweb did not accomplish its mission.

I had a few campaigns designed to get people interested in learning more about Durfweb, but none were particularly successful. A few that come to mind: I ran a book giveaway contest on social media, I issued a call through the podcast and on social media to rate the podcast on iTunes, and I created a badge system to gamify learning more about Durfweb. No campaign elicited much response.

I was approached by a few people to perform consulting services. The idea was to take fees from this and reinvest them into the business, snowballing capital to grow the business. However, I wasn’t able to convert these leads. More on this in the next section.

The death knell for Durfweb came in the Agile Chuck Wagon podcast download statistics. While I had developed a small, loyal following, the download growth rate was linear, indicating that the same 100 or so people were downloading episodes. Listenership growth was stagnant for a period of several weeks, with two marketing campaigns having no noticeable impact. The end result was that Durfweb was spending money on Agile Chuck Wagon hosting and other podcast production costs with no prospect of returns.

What to Improve Next Time

Durfweb was starved for resources. In order to get the market penetration we sought, we would have needed to spend a lot more time, money and effort toward Durfweb. A related issue was that Durfweb was originally envisioned as a collaboration between me and my wife Candy. I launched the business earlier than planned because of an unexpected windfall of time I had, and I focused on offerings I knew best. Candy was in crunch time on a project at that time and could not collaborate on it. As a result of this bias, most of the service inquiries we got were more in my wheelhouse than hers. This made it difficult for Candy to help get the business grow when it started faltering.

Next time, we need to market her offerings alongside mine so our leads can develop in a more balanced manner. We also need to make sure that either of us can perform our basic services. For example, we had one lead that fell through due to scheduling issues. It was for a getKanban game facilitation session, which I’ve run many times but Candy has not played before. We lost that sale because of scheduling conflicts.

Durfweb’s business model was to offer a customized coaching package for clients. For each lead, I would do an initial consultation, describe what services we had that would apply to their situation, and negotiate an engagement. However, I lost business with this model, because these prospects seemed to want a pre-packaged, flat-rate product. It seemed clear that they had a problem in mind, but didn’t seem as interested in solution discovery. We need to improve the packaging of our services to more clearly describe the value proposition.

An example entry-level offering that would be to explicitly package facilitation of the getKanban training game. We own a copy, and I have run it many times for employers and clients. Helping clients apply the lessons of this game to their particular situation could become a premium service.

Conclusion

I haven’t given up on this business idea. After I complete my MBA degree, I plan to revisit Durfweb, ideate, and then prepare a proper business plan. With that plan in hand, Candy and I can decide if and when to launch.

When hiring for a technical position, I like to give candidates a coding exercise to test their mettle. In this post, I talk about traits to look for in coding exercises and use those to discuss why coding exercises are useful.

Obviously, much of this advice would apply to a similar professional exercise like a backlog grooming exercise for a prospective product owner, but I’m hiring for developers at the moment, so that’s the focus of this post.

When to give the exercise

Normally, as the hiring manager, I’ll talk to candidates about the position and answer any questions they might have about the position. In the course of that discussion about their background, the candidate and I jointly decide if the position is worth pursuing for both of us.

I like to administer the coding exercise before the first team interview, which I like to conduct in-person where possible. This gives the team and the candidate something concrete to discuss during the interview. Otherwise, I find that these discussions devolve into a resume review, which is less valuable than “talking shop”. With the results of a coding exercise in front of the team, they conduct a code review with the candidate, which naturally leads to deeper discussions, and also often elicits better probing questions from the candidate about the position and the environment.

Traits of Good Coding Exercises

Clearly explain the end goal

I think it’s crucial to let candidates know the philosophy behind the exercise, and especially what aspects of the exercise they can ignore. In general, I ask candidates to develop a few things well as opposed to many things poorly.

Time-boxed

In general, candidates will be completing this coding exercise on their own time. To be respectful of that fact, coding exercises should be time-boxed to a reasonable amount of time. During my MBA classes, most exams that required freeform responses lasted no more than two hours, and I think that’s an appropriate duration for a coding exercise also.

Having a time limit allows evaluators to compare candidates as well. While speed is not the only criteria, it helps me compare candidates to people on my current team and previous teams. If I’m trying to decide if a person is a junior, intermediate or senior developer, it’s useful to know what they can accomplish given a new problem in a given amount of time.

The downside to this approach is that time pressure can cause some aberrant behaviors, outside the normal stress of a job interview.

Some scaffolding

This time pressure often means that I will provide some scaffolding. This allows me to better target the exercise to whatever aspects of the solution I’m looking to examine, as opposed to seeing if the candidate can create a new project correctly. That’s why some exercises I give are refactoring exercises instead of new feature writing, so that the candidate has time to show me their design chops without having to create all the necessary infrastructure.

It also allows me to illustrate how the candidate will fit into the team. For example, if I’m hiring for a .NET developer on a team that has already has a MS-SQL database developer, I will often work with said database developer to provide a database schema with several useful stored procedures so that they get a head-start and so they know they don’t need to worry so much about databases in this position.

On the other hand, if the candidate will be expected to work on SQL stored procedures, I’ll design the exercise to include a SQL component to signal that. This exercise is as much about the candidate deciding if they want to work with us as much as it is for me. In my experience, if they don’t like SQL stored procedures, they will either submit an alternative or bow out of the candidacy.

Require minimal extra setup by the candidate

A good coding exercise will focus on whatever technologies are needed for the position, and will leverage a standard coding environment whenever possible. For example, if I am interested in finding out the candidate’s approach to coding in Java, I avoid obscure libraries that would distract candidates.

Where possible, I use common industry tools like Git to distribute and evaluate the exercise, because those are in heavy use by my team and it allows me to ensure that a candidate can use them. When using Git, I collect answers as patches rather than as a fork so that candidates can’t look at each others’ work.

A word on the SQL example above: unless I expect that all candidates will have a working SQL environment, I avoid technologies that require a lot of setup. I want developer candidates to focus on showing their value, not their environment setup expertise.

Include some interesting decisions, appropriate to the level of the position

To me, a test like FizzBuzz is like a parlor trick. Many programmers know this exercise, and the solutions don’t vary much. Thus, they are like a Boolean test of programming prowess: can you program? (true/false). I liken a coding exercise to an essay question rather than multiple choice, so I design meatier problems to solve than can be handled by one method.

I also detail the outcome I expect to see, and these are the only clarification questions I’ll answer from candidates before submitting their answer. Unless I’m interviewing for a junior position where a test that that might be appropriate or where I expect to be giving detailed instructions, I like to give instructions with the same level of ambiguity that the candidate can expect when they join the team. This means that intermediate candidates can expect more prescriptive objectives and more scaffolding than senior or architect candidates (more on scaffolding later).

My coding exercises often include more work than can be done in the time allowed (more on that later), to force candidates to make priority decisions. With more senior positions, I even leave architectural or framework decisions to the candidates, expecting that they have relevant experience to bring to bear. These exercises often include some red herrings as well, to see if candidates can deduce what portions of a system are important to an issue and those that can safely be ignored.

In many cases, I suggest that senior candidate introduce their own features, not only to see how they explain their feature but also to provide them a chance to exercise their imagination. To me, coding has elements of art as well as science, so a coding exercise would not be effective if there was only one acceptable solution.

Offsite, in comfort

One deficiency of whiteboard exercises where candidates work a simple coding problem on a whiteboard is that they favor people who are socially extroverted and quick to adapt to new circumstances. In my experience, people who excel at whiteboard exercises and are a good social fit make for good team members.

However, whiteboard tests tend to provide false negatives for introverted candidates, who may not be comfortable with the “thinking out-loud” component, as well as for junior or intermediate candidates that are not confident in their abilities. People tend to be concerned about syntax errors that an IDE would immediate point out or even correct. I observe that many candidates are self-conscious and don’t produce their best efforts.

To mitigate this, I like to allow candidates to work on coding exercises in one of two environments:

• the candidate’s chosen environment, using their own equipment and setup
• as a pair programming exercise, in-person using their equipment when possible

While pair programming is my personal preference, it does require synchronous timing between the evaluator and candidate. And, I’ll admit, often the issue is my schedule! Thus, I design my exercises for asynchronous use as a remote exercise and administer in-person when I can.

Conclusion

I hope you found this post interesting. If you’d like to see examples of coding exercises I’ve given, have a look at my coding-exercises repo. These two are in use for the positions I’m hiring for. If you’d like more information on those positions, hit me up.

Fresh from Typesafe’s “Fast Track to Akka in Java”, I decided to apply Akka to a problem I know well, the bowling game kata. Although I’ll be using some code snippets to illustrate my journey, the full solution is on GitHub.

Bowling Game kata

For those of you know aren’t familiar with it, the kata was created by Uncle Bob Martin and involves the creation of a class that can score a game of bowling. While bowling does have a couple of “business rules”, if you will, it’s pretty straightforward. A game of bowling requires a ball, some pins and a long, narrow floor called a lane. The game consists of ten rounds called “frames”, and each frame involves rolling the ball up to two times with the goal of keeping the ball in the lane and knocking down the ten pins at the end of the lane.

Akka

Akka is a toolkit for abstracting away asynchronous code so you can think about your code in a single-threaded, synchronous way. Akka is an actor-based system, so designs are comprised of a handful of actor types (the “nouns”) and a group of message types (the “verbs”). Interactions between classes are conducted through messages, which is reinforced by the fact that you can’t get to an instance of an actor. Actors are created in a hierarchy, with a system actor called a guardian at the root. If you are intrigued as I was, visit akka.io.

Let’s dig in….

I’ve decided to convert this site from Wordpress to Jekyll, a Ruby static site generator that’s suitable for use with GitHub Pages. GitHub Pages is attractive because publishing is as easy as committing files to a repository.

I’m using Qck-Theme to style the site, because it has a little customized theming, but is still simple.

Getting started is easy, although I learned a few things the hard way. I ended up having to get help from GitHub Pages support, and their technicians were fast and very knowledgable. Kudos to James and Steven!

First recommendation is to install Jekyll locally for site development. If you plan to use GitHub Pages to host your site, do yourself a favor and use the pages-gem to install Jekyll and its dependencies. It uses the same versions of the gem files that GitHub does, so you can eliminate some causes of odd behavior that way.

Second, this is open source software, so contribute where you can. I learned a lot about Jekyll and how it generates sites by doing keyword searches on GitHub through my theme’s source code. I also found behavior worth a feature request and a bug. When you fix it locally, isolate the fix and submit a patch!

I used the WordpressDotCom importer to pull my site data from neontapir.com. It did a fairly good job, but there were a couple gotchas.

The most annoying was that the importer used relative paths to the /assets folder, where the images are stored. This meant that almost all the images on the site were broken.

I used a command like this to fix it:

ls _posts/* _pages/* | xargs perl -pi -e 's/img src="assets/img src="\/assets/'

A more insidious issue had to do with a bug in Jekyll itself. By the time you read this, it’s probably already been fixed, but Jekyll doesn’t handle time zones in the post dates in the front matter of articles. (Front matter is what Jekyll calls post metadata like title, description and publication date.)

It manifested in an inability for the post_url directive to find other posts by filename, even though they were in the folder. Files have the date encoded in them, and the search function noticed there was a mismatch between the date in the filename and in the front matter, so it wouldn’t return the file. This caused a site build failure that I couldn’t reproduce locally.

The imported site was usable almost immediately, but it took another 2-3 hours to get it looking half-decent. Most of that time was looking for links to other posts and replacing them with post_url directives, as well as configuring social sharing buttons and Disqus for comments.

Overall, I’d recommend it. For me, Jekyll lowers the barrier to entry for writing new content, even if it’s not as fully featured. That having been said, I rarely used many of the features Wordpress offers.

The Agile Chuck Wagon is gaining steam. See what the buzz is about!

Visit the Agile Chuck Wagon category on durfweb.com (Editor’s note: defunct) to see past episodes, which have included:

• Introduction to Kanban
• Mile High Agile 2015
• Principles of Kanban
• Lean Coffee

Upcoming episodes include:

• the Decorator pattern
• Offshore Teams
• the getKanban game
• Models of Change

Thanks for listening!