Monday, February 10, 2014

How to get good software from contractors

OR Working with codecraft (me)

I think I have said before, the purpose of software development is to produce good enough software as quickly and efficiently as possible.  Everything I do at codecraft is driven by that principle.  But why just "good enough," and what does it mean exactly?

Good Enough Software

The software created by a project should only be good enough, not more.  That sounds crazy, I know.  But, if we are trying to get to market quickly and make strategic use of our investments, any bit of extra quality or premature scalability or speculative functionality costs money, money we could spend elsewhere.  One has to be serious about how time and money are spent or the competition will clobber you.

Good enough, then, means finding the balance between present and future costs and benefits.  Good enough means investing in what you need most right now, while being conscious of future concerns.  Good enough means getting something inperfect in front of users quickly, and worrying about scale and perfection when the system is viable.

So how do I go about delivering Good Enough, quickly and efficiently?  It is all about providing rich, continuous feedback.

What I Do

Continuous Planning
Every day, the plan will change to respond to where we are and what is the most strategic use of time.  I usually like to keep a prioritized "feature inventory" in a shared document of tracking system.  The client picks priority features, with some elaboration and discussion as necessary, and defines "Stories," pieces of the feature that make reasonable units of work.  Stories move from a Ready state to In-Process with further discussion as necessary, and using the principles of Kanban the in-process work at any time is limited to hone productivity.  Completed code for a story is captured in the shared repository when finished.

Continuous Communication
Using a tool like Campfire or Flowdock, the entire team can share and recall group communications.  Developers will be available continuously (during certain time frames) in this environment.

Continuous Quality
All business logic modules will be supported by automated unit tests and shared with the client as desired.  The user interface will be supported by a reasonable suite of integration tests.  The full test suite should be run before every commit.

Continuous Delivery
All completed source code is kept in a shared repository like GitHub and available at any time to the Client.  I would suggest we use a cloud or PaaS like Heroku or Digital Ocean to host a couple environments, "staging" and the ultimate live site.  As soon as possible, the running application will be available in staging.  Every bit that is committed into the shared repository will immediately be installed into the staging environment for review.  Code is often delivered several times a day.

What I Don't Do

I don't tell you what you want to hear.  I don't pretend to see the future and act like I know what the optimal solution for the client will look like, months from now, much less how much effort it will take.  After all, Estimation is Evil.
Rather than basing the relationship on a contract that gives clients a false sense of security about getting what they need, I prefer to set up a relationship based on trust.  Trust at a personal level, but more importantly a trust in the practices that we will set up together to ensure the best possible use of time and resources.

Wednesday, October 31, 2012

Using a module to share common association logic in Rails

UPDATE:  If I did this again, I would consider packaging the code as a Concern

I recently wanted to DRY up some repetitive Rails association code, similar associations used in multiple models.  This gave me the opportunity to figure out a few tricks, like creating a module Class method and using metaprogramming to add dynamically named accessors.

Anyway, here is the Module:

...and the client model...

Tuesday, August 28, 2012

Building procedures with composition

Often developers need to model a multi-step process.  Also common is the need to reuse pieces of the process:  maybe the steps are the same but the execution of the steps vary for different contexts, or maybe the step flow changes slightly in some cases but the logic of the steps is largely reused.

One common way developers address this situation is to implement a Template Method pattern.  For example, an insurance system might have several similar flows for processing feeds from different sources--partner EDI, consumer web site, provider applications--where many of the steps involved are largely reusable.

A Template Method basically uses inheritance to share common logic, while varying the implementation of steps by overriding methods representing particular steps.  However as the GOF posited and leading developers believe today, one should "favor composition over inheritance."  Inheritance abuse is a common and natural side effect of trying too hard to reuse logic the OO-way, but we can do better.

The essential problem with using inheritance with the Template Method is that the class tree can get pretty ugly if one needs to vary the implementation of steps AND the flow of steps.  Also, more often than not, the is-a relationship between common and specialized processors is restrictive and faulty.  For example if a processor implementation wanted to extend something else like ActiveRecord.

What if, rather than using a template method, one could compose flows of steps, where the steps are pluggable members?  Another way to build processes that can be reused and extended is with the Strategy pattern, where the algorithm (or steps thereof) are pluggable.  Using this approach, the developer creates the structure of the flow in one class but delegates the execution of steps to collaborators.

Now what if there was a fluent interface for building flows of plugable steps, as well as machinery and conventions for coordinating between steps?  Well, that is the idea of Flo:
Some of the ideas from Spring Batch and Apache Camel have also inspired my thinking here, but Flo is much simpler and less specialized.  I was also motivated by the Unix programming model, little tools that do one thing well, strung together with pipes.

Note that Flo is a work in progress, awaiting her first real application.

Monday, June 18, 2012

Controlling Rails mass-assignment with whitelists and :as

Rails 3.2 has some flexible features for controlling mass-assignment. A little Gist I put together demonstrates:

 whitelisting and roles:

Tuesday, November 29, 2011

Search as Data Store

A while back I came across Solandra, and began wondering about using it as a general purpose store for a typical content-heavy webapp. The idea was based on a pretty vague notion that combining search with NoSQL would be powerful. What Solandra does is bolts the SOLR search engine onto Cassandra instances, resulting in a distributed search with all the data persisted in a NoSQL store.

In poking around, I've found that it is not unheard of to use SOLR as a web backend. Perhaps the most prominent example would be The Guardian's use of SOLR for their "Content API." There was also supposedly a twitter-like example that "uses the Lucandra store exclusively and does not use any sort of relational or other type of database", though the link did not work as I wrote this (Lucandra is the predecessor to Solandra).

Why not just stuff everything into SOLR? It is effectively a document store with powerful and fast queries. Sure it does not support transactions and the data is not normalized in a relational sense. But do you need those things for content? What I mean by content is dynamic stuff that might be edited by humans or updated by feeds: articles, comments, tags, product descriptions, locations; data that is viewed a lot but edited infrequently, not super structured or requiring crazy integrity. With the Cassandra backing, you should at least get durability and eventual consistency on the data that you shove into SOLR (Solandra).

I guess now I will have to give it a try, see where the trade-offs are in practice between search, NoSQL, and Relational stores on a real content project. Who's got one for me? :)

Tuesday, November 15, 2011

Objects in practice: class basics in Java and Ruby

This post looks at basic class and inheritance mechanisms in both Java and Ruby. I might to decide to expand this into a series, illustrating basic programming building blocks using Java, Ruby, and Scala; we'll see how it goes.

For this post, we are modeling employees of a software company, something like:
(via YUML:

NOTE:  This is NOT a good design--doesn't allow employees to fulfill multiple roles, doesn't account for changes over time--but I'll show better designs in later Howtos.

So, the general idea is that we want to reuse some behavior and also provide some specialized behavior. Probably the most simplistic way to do this in OO languages is to set up concrete inheritance and leverage polymorphism. I'll show how this is done in Java and Ruby, and the complete code can be found at github


A simple parent class, provides startDate member and monthsOnJob to subclasses:

public class Employee {
  private Date startDate;

  public Integer monthsOnJob() {
    Integer months = 0;
    // Do the math
    return months;

  public String jobDescription() {
    return "New employee"; // Default description, will be overriden by subclasses
A simple subclass, adding behavior to the super and overriding the description

public class Developer extends Employee {

  public String jobDescription() {
    return "Developer: " + listTechnicalSkills(); 

  private String listTechnicalSkills() {
    String skillStr = "";
    // TODO get skills from getTechnicalSkills and build string
    return skillStr;

  private Collection technicalSkills;

  public Collection getTechnicalSkills() {
    return technicalSkills;

  public void setTechnicalSkills(Collection technicalSkills) {
    this.technicalSkills = technicalSkills;
Another specialization, Manager has Employees as reports

public class Manager extends Employee {
  Collection reports;

  public String jobDescription() {
    return "Suit";

  public Collection<Employee> getReports() {
    return reports;

Now the parent class in Ruby

class Employee
  attr_accessor :start_date # method that creates accessors

  def initialize(start)
    @start_date = start

  def months_on_job
    # Math is easy
    (*12 + - (@start_date.year*12 + @start_date.month)

  def job_description
    "New employee"

A Ruby Developer class

class Developer < Employee

  attr_accessor :technical_skills

  def initialize(start)
    @technical_skills = []

  def job_description
    ret = "Developer: "
    @technical_skills.each {|skill| ret << " ${skill"}

The Manager

class Manager < Employee

  attr_accessor :reports # accessor
  def initialize(start)
    @reports = []

  def job_description