the 'bee log

The High Cost of Losing a Developer

Dave Laribee — Tue, 17 Nov 2009 06:18:00 GMT

You've probably heard statistics about the "high cost of losing a customer." The theory is simple and true (fact?): keeping existing customers and repeat business is much more profitable than attracting new customers. Here are a few facts from BusinessCoach.com:

- For every customer who bothers to complain, there are 26 others who remain silent.
- The average “wronged” customer will tell 8 to 16 people.
- 91% of unhappy customers will never purchase services from you again.
- It costs about five times as much to attract a new customer as it costs to keep an old one.
- Each one of your customers has a circle of influence of 250 people or potential customers who hear bad things about you!

The point of this post is simple: RETAIN YOUR GOOD DEVELOPERS. Getting someone up to speed on a legacy codebase takes a long time and is an expensive undertaking. A large part of the software coach's or manager's job is attracting, developing and keeping talent. And that talent becomes more valuable over time.

Yes, you might be able to replace someone at a lower annual salary, but you have to take into account the complexity of your code portfolio in how long it'll take to make that person productive. A $60K/annum employee may very well take $120K before reaching the productivity level and contribution of the developer who left the team.

Code Coverage: What Is It Good For?

Dave Laribee — Fri, 13 Nov 2009 20:06:00 GMT

Absolutely nothing. Or so the story goes...

I had a mini-exchange with my pal Glenn Block last night on Twitter. He was recycling the somewhat old meme that code coverage is a cockamamie metric that, as he puts it, "[code coverage is] a false security blanket on quality".

Measurements (other than net profit, of course) are merely indicators. They give us insight into what we're doing, red flags that help us know when to follow up on and drill into with more qualitative and hands on tools.This is, more-or-less, the idea behind Autonomation or "automation with a human touch."

For example: while code coverage isn't proof that our testing efforts will yield higher maintainability, it does tell us a teams commitment to a test practice.

I tend to believe the most interesting indicators are composite metrics. What happens when we start thinking about combining code coverage with cyclomatic complexity? I'd like to read a (hopefully) inverse relationship over time, coverage rising while complexity falls, as a good indicator that we're doing simple design.

The important thing to remember about metrics is they are only single purpose tools which, correctly applied, gift us with little tidbits of insight. It's up to you to find meaningful and creative uses for the various metrics and their various combinations. Once you start doing that, measurements like code coverage can certainly help you achieve your immediate goals.

December 2-3 London Workshop Update

Dave Laribee — Thu, 05 Nov 2009 15:29:00 GMT

Forgive the self-promotional interruption, but quick housekeeping note:

I've asked the company hosting my workshop in London to reduce the price of my 2-day workshop on December 2-3 aimed at tools and techniques technical leads, folks interested in lean, standard work, etc. to try to get as many people there (it's a group collaboration focused thing). I also want to get as much feedback as I can. If you book before November 15th, the price is £550.

Low-Technology

Dave Laribee — Thu, 29 Oct 2009 18:55:00 GMT

I'm completely obsessed with the idea of low-technology:

The term low-technology is a description of those crafts and tools whose inception (typically) predates the Industrial Revolution.

A test for low-technology may be that it can be practiced or fabricated with a minimum of Capital investment by an individual or small group of individuals; and that the knowledge of the practice can be completely comprehended by a single individual, free from increasing specialization and compartmentalization.

An excellent overview of some of the cutting edge efforts in low-technologies can be seen in this TED video with low-technologist Amy Smith. I completely agree with when says, "not all inventions need to be grandiose, complex things... sometimes they can be simple and smart ideas that just help a lot of people."

The second block quote is where I'm coming from. What are those tools in software development that add lots of value without minimal getting started overhead. Pair-programming seems like an excellent example of low technology. Emergent design, test-driven development and value-driven approaches like XP are yet more.

It seems, to me anyway, that these are the things that'll yield the most benefits. Both vendor-supplied tooling and trending topics we hold near and dear, like Domain-Driven Design and DSLs and this fluent madness in general, strike me as more high-technology approaches.

There's nothing wrong with high-technology, of course, but my instinct is that the risk-reward equation for most teams usually favors low-technology. We have, after all, limited bandwidth and attention, so my vote will ever go to what I see as big and easy wins: stuff focused on beefing up the signal of our communication as a team and community against the noise we might get as a software fashion victim.

Anyway, this is a key topic I'll be centering on over the next little while and thought y'all might find this way of looking at our kit, our standard tradecraft at least a little bit interesting.

The Most Productive Programming Language

Dave Laribee — Wed, 28 Oct 2009 00:08:00 GMT

The most productive and useful programming language you know, by a long shot, is English or Hindi or Portuguese or Spanish or French or whatever human language your team uses. Good communication skills are way more valuable to you and your customers than picking up a new language every year. That is, while there is value in the item on the right, I value the item on the left more. Sound familiar?

Developers that name things well and program with a respect for human languages create more maintainable and easier to follow code. Being able to communicate with a customer, analyst and/or product owner can save you hour upon hour of effort and keep your solution simple. No programming language no matter how syntactically minimal or internal DSL friendly can ever come close to this.

London Workshop, December 1-2

Dave Laribee — Wed, 30 Sep 2009 21:00:00 GMT

UPDATE: The workshop is scheduled for December 2-3.

A little housekeeping. I'm doing a two-day workshop I'm doing in London in December (1-2).

http://skillsmatter.com/course/design-architecture/towards-a-new-architect

I'll share the experiences and tools I've developed as a team lead over the last decade doing architecture on Agile then Lean teams. My thesis should sound familiar: we need a Chief Architect-like role in development, someone who considers all aspects of the system and can coach the team toward emergent design in product and process. The workshop is aimed at giving you actionable tools and an overview of things I've seen work really well together. Some of the Lean/Kanban-related topics include how XP works with Kanban and how architectural/design approaches can help get to release-per-feature and higher ROI for your business.

The course is appropriate for technical leads (current and aspiring), product owners and designers, coaches and senior developers or software architects.

Hope to see you there (and have pints with the London Kanban and AltNetBeers kids)!

Exceptional and Substitutable

Dave Laribee — Wed, 09 Sep 2009 17:34:00 GMT

I watched Sean Chambers deliver an excellent talk about S.O.L.I.D. principles last weekend at Tallahassee CodeCamp. It motivated me to look a little deeper into the Liskov Substitution Principle, which states:

Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.

We accept this as a truth and it's what makes us hate the is keyword in C# so damn much. I wrote a post a while back that explains (or attempts to) what LSP and why it's important, which is to say I won't harp on the what and why here. I'll spend your attention, rather, on how LSP works with exceptions.

The LSP article on Wikipedia provides clarification around exceptions and subclasses:

No new exceptions should be thrown by methods of the subtype, except where those exceptions are themselves subtypes of exceptions thrown by the methods of the supertype.

Here's a contrived and fugly example in ruby:

class FileSystem
  
  def save(path, text)
    File.open(path, 'w+') {|f| f.write(text) }
  end
  
end

class AmazonFileSystem < FileSystem
  
  include 'amazon_library'
  
  def save(path, contents)
    begin
      write_to_s3(path, contents)
    rescue
      AmazonWebServicesError.new('cannot write file');
    end
  end
  
end

class AmazonWebServicesError < StandardError
  
  def initialize(message)
    @message = message
  end
  
  def message
    return @message
  end
  
end

def backup_system
  
  file_name = 'book.txt';
  my_important_text = 'hello world';
  
  [AmazonFileSystem.new, FileSystem.new].each do |file_system|
    begin
      file_system.save(file_name)
    rescue AmazonFileError
      # VIOLATION! FOR SHAME!
    end
  end
  
end

A try-catch (or begin-rescue) is a conditional pattern and it's my sense that when we use this with implementation inheritance we've made a particularly egregious and insidious violation of the LSP.

First off, we're know things about the internals of our subclass in our consumer. We've broken encapsulation and increased coupling.

Secondly, our special AmazonWebServiceError only shares StandardError with what's likely to be thrown by our FileSystem class. This means we can't treat errors that are likely to fall out of Ruby's IO core polymorphically. More conditional logic/branching, more cyclomatic complexity, more coupling, and these are bad things.

What can we do to stay on the good side of LSP when dealing with exceptions in inheritance hierarchies, you ask? Well, as the rule states, we can make exceptions subclass the exception the parent throws. For example, we could catch whatever error our fictitious amazon library throws and decorate it with a custom error that derives from the error File.write in ruby core throws. Another, perhaps, better option would be to hold off on coding defensively wherever you can and let the exception bubble up to a central part of your program that deals, exclusively, with these corner cases. That is, implement an exception shield wherever we don't need compensating logic.

LSP and exceptions: another thing to pay attention to while on programming's happy trail, friends.

The Secret Sauce

Dave Laribee — Tue, 08 Sep 2009 21:32:00 GMT

Are you listening? I'm about to give away the secret to to all of this this Lean/Agile/Software Craftsmanship fuss. The secret is... DISCIPLINE.

"The time is always right to do what is right" -- Martin Luther King, Jr.

Assuming we know what to do, and I know a lot of you reading this do, we should always just say no to shortcuts. Delivery pressure is a real thing, but if you're estimating a piece of work, estimate what it'll take to do the right thing. If real Object-Oriented Programming is new to you, it's going to take you a whole lot longer to get something done. If the language is new to you, it's going to take you a lot longer to get something done.

Sometimes we take embarrassing and unprofessional shortcuts like:

Getting out of TDD mode.
Rolling shoddy spike code into production.
Using an older, more familiar but less quality recipe to a common coding task.

The best way I know of to keep discipline up is pair programming. Some would say pairing is the way because two heads are better than one. I say it's a great practice because it creates a healthy peer pressure.

Learning and discipline are the two halves of continuous improvement. In short: live what you learn, act on your new knowledge and skill.

Return False on the Happy Path

Dave Laribee — Tue, 08 Sep 2009 19:44:00 GMT

When you call a query method that returns true or false, I highly suggest that you make true results trip conditional logic / guard clauses / etc. I was driving out some code today in an MVC controller that had a dependency on an type who's responsibility it is to check for unique email addresses in a database of user which looks like so:

public interface IUniqueEmailValidator
{
  bool EmailAddressIsUnique(string email);
}

All well and good, but you'll notice that the method returns true in the happy path. That is, if an email address is unique (working on an authentication system), the object returns true.

I use an auto-mocking container when doing TDD with .NET. Most implementations give you back a so-called dynamic mock which just absorbs calls and returns default values on methods that return value types. So in the case above, a dynamic mock will always return false unless you tell it otherwise. I'd end up having to put noisy stub code in all of my other specs. For example:

Dependency()
  .Stub(u => u.EmailAddressIsUnique(null))
  .IgnoreArguments()
  .Return(true);

In the controller we're working on right now, there are about 10 specifications that failed because of this default behavior. This is a big problem because the introduction of a new specification results in me having to change a bunch of other contexts which is stinky, fragile design!

An opportunity to make things better! I changed the interface to this:

public interface IUniqueEmailValidator
{
  bool EmailAddressIsUnique(string email);
  bool EmailAddressIsTaken(string email);
}

The new EmailAddressIsTaken method simply inverts the result of EmailAddressIsUnique. Really frighteningly simple stuff, but, by calling the new method, my test code stays isolated and the special cases don't break my numerous other specs.

Kanban Features in VersionOne

Dave Laribee — Wed, 29 Jul 2009 17:54:00 GMT

We added basic Kanban features (board, cycle time, cummulative flow diagrams) into our product VersionOne. These goodies are in the latest release which is available today. Steve Harman and I cut a video demonstrating the functionality on a 47" multi-touch display.

CHECK IT OUT.

Have to say, I'm pretty excited about the new features. Customers, be sure to let us know how/what we can improve!

Ubiquitous Language in Product Development

Dave Laribee — Wed, 24 Jun 2009 21:15:00 GMT

Hi there.

I got this question from a fellow named Martin today:

Real simple ... most of the discussion on DDD surrounds the design in terms of the ubiquitous language.

What if you are developing a product that is designed to be a tool for a certain industry, say marketing, but the processes and terminology all differ according to the marketing company that is in discussion.

To be specific, one company may use the term Client and the other Customer?

How do you accommodate the difference in terms? Do you code to a common denominator or do you just pick one and go?

Great question; in product development we're often trying to make a general solution that solves the common problems of customers that have different languages. There's no way around that.

First, find those elements that are universal. Question if there's really a need for all of this customization or if your clients are OK with calling a client a customer. Having a ubiquitous language that can be used end-to-end, from developer to end user, is extremely valuable and kind of the original point.

For variable terms you should, in my estimation and experience, form an internal ubiquitous language that's adhered to across product management and software development. In cases like this, you'll can potentially also apply DDD guidance to a generic subdomain that handles terminology. This domain usually goes by the name "localization," only slightly extended to allow clients to change terminology. This is exactly how we handle the differences in terminology (silly) between agile methods like Scrum and XP in our product at VersionOne. We simply have a set of components that handle the change between backlog item and story, iteration and sprint, etc.

Announcing the Lean Kanban Conference

Dave Laribee — Tue, 06 Jan 2009 14:44:00 GMT

I've been working with David Anderson and crew to produce the Lean Kanban Conference in Miami, February 18th-20th.

There are a number of great speakers and some folks that have been practicing Kanban and flexing Agile methodologies with Lean thinking for some time. For my part, I'm going to do a talk about introducing pull systems at the edges of an Agile team (based on experiences at VersionOne), JIT'ing retrospectives, and rethinking software development activities and practices -- architectures, continuous integration, source control -- through the Lean lens, which would have us release regularly (on a feature basis, in fact).

If you're interested in Lean Software Development and Kanban, this is the place to be. Register now!

Spicing Up Your Standup

Dave Laribee — Mon, 17 Nov 2008 01:58:00 GMT

Tags: luke-melia -is-awesome, funny

Ayende on Advanced NHibernate

Dave Laribee — Thu, 13 Nov 2008 14:02:00 GMT

There's this cat called Ayende that's been around the NHibernate block (20 or 30 times). In Austin, he did a 3-hour workshop detailing the advanced features of the tool. If you weren't there, sorry you missed it.

Oh wait! You're in luck; someone recorded it! The audio is a little quiet so be sure to, as the kids say, "pump up the volume."

Enjoy...

Designing the Team Room, Take 2

Dave Laribee — Thu, 06 Nov 2008 15:19:00 GMT

Based on the comments, a couple of clarifications on my "Designing the Team Room" post from yesterday.

The text at the bottom certainly does have contradictions and conflicts. That's by design. We wanted to see what people came up with, what ideas latched on to "productivity" versus "collaboration." The opening is simply for context. People that are up on Theory of Constraints will realize that defining conflicts and finding solutions based on root cause is, well, kind of the whole point.

I also neglected to detail the mechanics used for the design storm.

1. Each person tore of a sheet from a 3M sticky easel pad, grabbed a marker, and found a spot on the wall.
2. We had twelve (12) people stand in the circle.
3. I read the context statement I posted yesterday.
4. For 5 minutes, each person made a "design." Some of these were visual, some textual, some floor plans, etc.
5. We then counted off by threes to form a total of four groups (ones in one group, twos in another).
6. Each group member (within their group) had 1 minute to pitch their ideas.
7. After the individual pitches, we took another 5 minutes to synthesis a cohesive design.
8. The cohesive designs were presented to the entire group.

What was interesting is that this process took under 30 minutes and we got a little closer to consensus and got some really good ideas. And that was the point...