Back in February, a few of us at Unspace had the privilege of attending the first EmberCamp in San Francisco, as presented by the talented and delightful folks at Tilde. We had been working almost exclusively with Ember as a team since just before Throne of JS (I guess our preferential secret is out) and — long story short — we got inspired.

As unveiled last month, we’ll be presenting Embergarten in partnership with Discourse over the Victoria Day long weekend here in Toronto, and we’re so happy to reveal that we have Yehuda Katz within our ranks to help us convert our love affair with Ember.js to the Toronto developer community at large over a two-day training and mentoring seminar.

While we’re working hard to ensure that the application we’ll be building in the workshop segments can be carried through the whole weekend, the course-load is separated into stand-alone Beginner (Saturday May 18) and Intermediate (Sunday May 19) days. Preparatory materials issued beforehand to ensure that everyone is on the same page with no pain points.

We’ll also be doing some all-inclusive doting over you the entire weekend and sending you home with treats (and homework, of course). Here’s the breakdown of what you can expect on both dates:

Beginner — May 18

Yehuda is going to be giving everyone the beginners’ primer on Ember.js and its genesis right out of the gate. The rest of the day is going to be focused on learning the router, basic application structure and conventions, Ember’s MVC, the Ember Object Model, and finishing off the day with a basic intro to Ember Data and (of course) some useful debugging techniques.

As we’ve had a lot of inquiries about the beginners day coverage, we’ll lay out the full lesson plan here next week.

Intermediate — May 19

Tireless elves are still working on our day two syllabus, but as a preview we’ll be continuing our coverage of Ember Data, looking at how to wait for data to arrive (e.g. promises, loading spinners), as well as some tactics to handle duplication and re-submission issues. We’ll also examine how to implement more complex UI components, such as modals. Additionally, we’ll be waxing on integrating with 3rd party libraries (D3, useful jQuery plugins) and other template helpers (render, partial, control and yield).

We hope many of you can come spend the weekend with us, Robin, and Yehuda. We’ll be gathering other mentors for the on-site workshops to assist with walkthroughs as needed, who we’ll announce in short order.

As a final aside, it should be noted that we’re taking a one-year sabbatical from the conference circuit, so we’ve also coordinated a little open-to-all rooftop afterparty on the 18th to reconnect with our favourites in the Toronto javascript community — RSVP if you’re not a slave to the cottage, we’d love to see your face.

Backbone.js is a fairly minimal javascript framework when you compare it to its more full-featured cousins like ember or angular. It can be a rude suprise when Backbone suddenly leaves you on your own when you were expecting to have a helping hand. There are many gotchas surrounding sub-views for example that aren’t typically mentioned in the many TODO list examples out there.

It is very easy to find yourself in a situation where your views are leaking memory if you aren’t careful. Happily, with some recent additions to the framework and some good tools, we can identify these problems and patch them up.

The setup

Let’s start with a model and a collection:

class Item extends Backbone.Model

class Items extends Backbone.Collection
  model: Item

We want to show the items in a list with each item in its own view. Let’s create the list view:

class ListView extends Backbone.View

  className: 'list'
  tagName: 'ul'

  initialize: ->
    @collection.on 'reset', @addAll, this

  addOne: (item) ->
    view = new ItemView(model: item)
    @$el.append(view.render().el)

  addAll: ->
    @$el.empty()
    @collection.each(@addOne, this)

  render: ->
    @addAll()
    this

and the item view

class ItemView extends Backbone.View

  className: 'item'
  tagName: 'li'

  events:
    'click' : 'remove'

  render: ->
    @$el.html(@model.get('name'))
    this

We want our items to update themselves when they are renamed:

class ItemView extends Backbone.View
  ....

  initialize: ->
    @model.on 'change:name', @updateName, this

  updateName: ->
    console.log 'updateName'
    @$el.html(@model.get('name'))

  ....

When an item in the list is clicked, we want to remove it from the DOM (not from the underlying collection for this contrived example).

class Item View extends Backbone.View
  ....
  events:
    'click' : 'remove'
  ....

Here is a working jsfiddle example

Straightforward right? Well, it turns out we’ve just hit a pain point that many a backboner has found before us: we’re leaking memory. While we remove our ItemViews from the DOM when they’re clicked, they’re still registered to the model’s change events and therefore can’t be garbage collected. Because the views can’t be collected, the DOM nodes they control can’t be collected either (they become ‘detached’). These views are now ‘zombies’.

There is a second problem. When the models change, the events will continue to fire on our zombie views, which can cause strange behaviour in our UI.

I’m going to take what i learned from Andrew Henderson in his post How to detect backbone memory leaks and apply it to our example.

Here, in our initial snapshot, we see 5 ItemViews have been allocated as expected:

After removing the first 3 items, i then rename all the items in the collection and we see that all 5 ItemViews still respond to the changes. In the second snapshot we also see 3 newly detached DOM nodes. This proves we’re leaking memory

Backbone 0.9.9 to the rescue?

But wait you say, the new version of backbone comes with .listenTo which will automagically unbind from event listeners and now we can go back to faceroll development mode. Sweet! Let’s check it out.

@collection.on 'reset', @addAll, this
@model.on 'change:name', @updateName, this

becomes

@listenTo @collection, 'reset', @addAll
@listenTo @model, 'change:name', @updateName

See jsfiddle version 2

Running through Chrome again, the click events are now behaving as expected, we’ve taken care of our detached DOM nodes, and there are only 2 instances of ItemView now as we would expect. That’s pretty great for such an easy change, hats off to the backbone team for that one.

Let’s keep going though, if we now remove the ListView itself from the DOM we’ve got another problem:

We’ve removed the UL node from the DOM, but we’ve left the last 2 instances of ItemView zombified. They’re still responding to model events and their DOM nodes are detached.

My basic approach is that if a view creates another view, then it should be responsible for cleaning it up also. Let’s do that now. The plan is to fire an event on the ListView that ItemViews will listen for and call #remove on themselves.

class ListView extends Backbone.View
  ....
  addOne: (item) ->
    view = new ItemView(model: item)

    # the item view will listen for the clean_up event on the list_view
    # and clean up after itself and remove itself from the DOM
    view.listenTo(this, 'clean_up', view.remove)

    @$el.append(view.render().el)
  ....
  removeItemViews: ->
    # let the children know it's time to put away their toys.
    @trigger 'clean_up'
  ....
  addAll: ->
    # clear out any existing ItemViews when resetting the collection
    @removeItemViews()
    ....

  remove: ->
    # when the ListView is being removed, it must clean up it's children
    @removeItemViews()
    super()

Let’s check Chrome.

No more lingering event handlers, no detached nodes, and no instances of ItemViews remain.

All done.

Leaks: plugged. Zombie scourge: put to rest.

Final jsfiddle

Related reading

• Eliminating memory leaks in Gmail
• How to detect Backbone memory leaks
• Thoughtbot’s Backbone.js on rails

It wasn’t supposed to be this way.

All those late nights fiddling to sunrise, university, and this is what my life path has twisted to? Why is this overweight, middle-aged fanboy bearing down on me to use one technology over another, pressing ignorantly on timelines to deliver something that doesn’t matter?

It’s time for a change.

One of the underpinnings of a psychological disorder is that the issue causes consistent and significant distress. We all have our days where we survive rather than thrive in our jobs but if your job is causing consistent, significant distress, your job is akin to a disorder and therefore needs to change.

There was a time that I not only was thinking of a career change but had committed to the idea. I decided that I was going to go back to university and become a doctor so that I could feel like I was more on the “ground floor” of the world. Helping people solve real issues. I realize this is a naive view of what a physician does day to day, however, it is a thing that many hopeful premeds aspire to. I went off, back to university at the age of 29 and began the journey.

Backing up a few months, as I was applying to universities, I started working at Unspace. The way things work here as more of an independent collective of developers rather than a typical company allowed me to go to school and work at the same time. To my surprise, I began to wish that I didn’t have to study chemistry, rather, I was drawn to development. Re-honing my skills and becoming the best developer I could be.

Software is an art.

Before long, I began to realize that long hours in a hospital versus the almost complete flexibility of working as a developer, as a creator, were starting to sound unappealing. I decided to put school on hold so that I could focus more on development.

I’m now back to development 100% of the time and realize in full clarity that the prescribed ladder of success is tragically flawed for at least myself and likely many others. Many readers might roll their eyes at how obvious this is. In my case, the success ladder lead to my being a manager with the aforementioned middle aged fanboy on my shoulders. As I moved up the ladder I moved away from creating and the further I got from creating the less happy I was. It hit me hard and fast when I finally not only realized what was going on, but took control of my life to make the changes that had to be made.

Instead of using society’s metric of success, try to look inward to the things that are enjoyable to you. Sometimes, it might actually be tough to figure out because it’s not always plainly obvious. Our socialization is pretty effective in blocking our ability to look inward clearly. However, don’t forget, now is as great a time as ever to start playing around and trying to figure out the things that make you sustainably happy in your career.

Don’t take things too seriously.

There are two great things about the current world of software development. First, the possibilities are endless. You can work for a small or large company, create your own startup or just freelance. There is very likely a niche that fits your favourite way to work. Secondly, there is a ton of opportunity out there! Software developers are in high demand at the moment so right now is a fantastic time to experiment.

The Daily life of a software developer generally consists of (in no particular order) build, build, design, estimate, propose, design, build, and bill. Certainly lots of execution in there. But hey, execution is important, right?

The answer is obviously “yes”. However, I got to reading a dev book tonight that I have been meaning to read for a long time and the feeling of building on my own personal philosophies on development rather than actually building software was really rewarding. Surprisingly so. Every good software developer gets a thrill from building things and that applies to building on our own internal selves as well. Try it. I mean, really try it. Rustle around in the well of your subconscious and pull something out that you know is thin. Work on it consciously.

I think sometimes we get so focused on building things, that we forget how rewarding it can be to take some time for ourselves. Sitting down and reading a book, not executing, can make the times you are executing a lot higher quality. Hold back and forcibly slow yourself down a little bit. You might find that whatever it is you are reading about doesn’t even end up being the area which sees the improvment.

So, my challenge to you is to pick up a book and just start reading. Take some time away from execution to develop more crystallized philosophies on software. My guess is that when you do go back to executing you will see big improvements; not only to your enjoyment but also to the quality of what you create.

This past Monday (November 12th) Robin Ward, plus Unspace’s very own Justin Giancola and Carsten Nielsen hosted the first Toronto Ember meet-up at Bento Miso. A wide group of developers showed up to enjoy Robin’s talk about Ember’s innovative binding system and Emberpress, a Letterpress clone that he built to demonstrate these features.

Being such a new and evolving framework it can be difficult for new developers to approach Ember; the learning curve is probably more steep compared to one of the other client side frameworks such as Backbone, but that’s mainly because of what Ember is giving you back once you learn to master its features.

Due to all this it can be tricky to find some good resources for newcomers to understand where to start exploring the magic world of Ember. For this reason I’ve compiled an evolving list of resources and demo applications to try to understand the power of this great framework.

You can subscribe to the Toronto Ember mailing list to be notified when the next meet-up will be taking place, you can also follow them on Twitter: @torontoemberjs

Introductions

• Fundamental Structure - Article by Trek
• Why Ember - Nice presentation, built with Ember
• Understanding Ember Object
• Ember Intro

Guides

• View Layer
• Ember App Structure
• Routing
• Asynchrony

Interesting Articles

• Talk about the current state of Ember / Ember Data - It’s down right now, but it should be online again soon
• High Level Overview
• The Emberist - Insights from core team member Peter Wagenet
• Useful Ember Functions
• Advanced Bindings
• Useful Observable Functions
• 8 Ember Gotchas With Workarounds

Developing with Ember

• Brunch and Ember Brunch - Node-based static site build tools
• Ember with Rails - Using Ember with a Rails application
• Iridium Ember - A Rake-Pipeline based static build tool

Demo Apps

• Ember Tunes - Our very own Justin Giancola walks you through building the same music player app that’s created in the Peepcode Backbone screencasts, but in Ember of course.
• Emberpress - A Letterpress clone written in Ember

There has never been a more exciting time to be a web developer. A year ago, building your own client-side rich JavaScript application was exciting, but fraught with peril: Early pioneers who “roll their own” have the pleasure of inventing things for themselves, but eventually the common problems each developer solves for and by himself will be baked into frameworks and plugins, rendering their work obsolete.

Today, it is a different story. There is a Cambrian Explosion of client-side JavaScript frameworks, with communities springing up around each one. Building on a framework frees us from having to reinvent the wheel, making us more productive and giving us more time to put our creativity to solving domain-specific problems.

The breadth of choice is staggering. And unsustainable. JavaScript frameworks are battling each other in a winner-take-all struggle for the mind share and passion of the development community. Nobody wants to build on technology that will become marginalized, rendering their skills obsolete, their code unattractive to others, and their applications slowly rotting as their underlying technology falls behind the curve.

So we pore over their feature lists. We watch to see who is using what. We read tea leaves to determine which framework is gaining traction, looking for the framework that hits the perfect sweet spot of being powerful, easy, well-documented, well-supported, and popular.

Throne of JS

We all want to know which frameworks will thrive and which will fail. We all want to know which niche each winner will dominate. And that, in a nutshell, is why Unspace Interactive is hosting what may become a watershed event in the client-side JavaScript ecosystem, Throne of JS — Seven Frameworks.

Throne of JS brings together the creators of the important client-side JS frameworks to speak about their creations. Throne of JS is a single-track conference, because we know you need to see and hear everything. We love Node.js, CoffeeScript, and JS.next, but Throne of JS isn’t about server-side JavaScript, alternate syntaxes, or the future of the language, it’s about selecting the right framework, today.

At Throne of JS, you are going to hear the people behind the frameworks directly. You are going to mix and mingle with other developers just like you: People who are serious enough about client-side development that they’re coming to a dedicated conference to talk to the creators and with each other. People who are there to evaluate the frameworks, the communities behind them, and the reception each receives.

Each day there’ll be roughly 8-10 speakers. The speakers aren’t strongly committed to a topic, and may change their minds at the last minute. We always include frequent breaks for discussion and digesting ideas. As of today, we’ve confirmed:

• John Bender — jQuery-mobile
• Jeremy Ashkenas — backbone.js
• Yehuda Katz — ember.js
• Tom Dale — ember.js
• Miško Hevery - Angular
• Nick Small — batman.js
• Harry Brundage — batman.js

We’re adding more speakers every week.

Everyone will be together in one big room. There won’t be question periods at the end, because they are a waste of time. Throne of JS is small enough that over the weekend, you will be able to have a conversation with anyone you want to. There won’t be a feeling of us vs. them with the speakers, either. Everyone will be there, doing their thing. We think it’s a great format, and nobody will feel like hanging out in the lobby, either.

Register Now

“Bandit” tickets sold out fast. There are still “Warrior” tickets available, and they’re $100 cheaper than waiting until the last minute. And there may not be any last minute: Previous Unspace conferences have sold out ahead of time. Get your tickets now.

Throne of JS is the client-side JS conference. Don’t miss out.

For submissions to the roster, contact justin@unspace.ca
For sponsorship, logistics, and all else: meghann@unspace.ca

People sometimes ask me if Unspace Interactive is expensive. Well, our hourly rate is neither the lowest nor the highest. But our hourly rate says little about the cost of what we build for clients.

Comparing software development companies on the basis of hourly rates is a little like comparing cars on the basis of how much their manufacturers pay in salary to the designers and engineers.

Sometimes, an inexpensive car is actually cheap. As in junk. It’s poorly manufactured, out of poor quality materials. It doesn’t work well and falls apart quickly. Its construction was haphazard and many mistakes were made. We don’t do this kind of work. We aren’t cheap.

But sometimes an inexpensive vehicle is simply cost-effective. It is well-built, in large part because its manufacturer has invested a great deal of time and money optimizing the manufacturing process. It is manufactured out of quality materials where necessary for its function, without wasting money on uneccesary overengineering such as using carbon fibre for the dashboard. The company’s manufacturers invested a lot of thought into every aspect of the vehicle, finding innovative ways to maximize the functionality delivered at a reasonable price.

The epitome of such a vehicle is the pickup truck. Robust and affordable, pickup trucks are the backbone of businesses large and small. A typical “working truck” eschews finery and ostentation, but it has an extremely reliable drivetrain and hauls cargo without complaint.

Although the pickup truck is not flashy, it was manufactured in a state-of-the-art facility with an optimized supply chain bringing parts and materials from around the world to arrive just-in-time as the truck is assembled on the line.

We do the same thing at Unspace. We use our experience to choose lean approaches that maximize the functionality and minimize wasted effort. We employ tools, frameworks and libraries to automate work that used to be done by hand. We have a flexible team that can contribute to projects “just-in-time” when needed.

When our customers need a highly innovative software application that breaks new ground, we do that, just as General Motors truck bodies are used to make fire trucks, ambulances, and many other highly specialized vehicles. But when our customers need pickup trucks, our team puts its mind to building cost-effective, reliable applications.

And we do it inexpensively.

Come to our Apocalyptic (in theme only, we’re terribly propitious) mixer for the Toronto Ruby community!

If the Mayans were indeed correct and 2012 is the End Times™, then we reckon that makes February 10th your last best opportunity to either find a dream gig for yourself or a superstar hire for your organization. That’s the night our cozy Unspace offices will serve as a friendly environment in which to network, pick a host of brains and give a brief pitch on your eminently employable self or your killer business idea without needing to lug all your trade show paraphernalia onto the TTC at the end of the night.

We’ll have coat racks for your winter gear and our boardroom will morph, Transformers style, into an open bar. Dress code is Casual Fabulous. All we ask is that you leave your laptops at home — secure storage space is at a premium — and avoid being unfashionably early. No, seriously: if you come before 6pm we’ll force you to wear a pointy hat with the word K33N3R on the brim.

Questions? Email meghann@unspace.ca. We’ll be sending out a reminder the week of the event with other must-know info.

Prior to joining Unspace Interactive, one of our developers worked on an “interesting” project, a project that taught him many lessons. One of those lessons was to beware of “duck programming.” Before we explain that term, let’s have a look at the project and get a feel for what the designers were trying to accomplish.

prelude: the project

One of project’s key requirements of the system was that it be flexible enough to accommodate almost any change in business requirements “without reprogramming.” The team decided to build a data-driven rules engine. Most of the business logic was to be encoded as rows in database tables. Changes to business logic would be accomplished by updating the database. The system would read the rows and use their contents to decide what to do.

The system controlled the auditing of apprenticeship programs such as cooking, automobile repair, and plumbing. The system would track all the apprentices in the various programs as well as the educational institutions and working organizations that trained apprentices on the job.

The “rules” for completing an apprenticeship program are elaborate and vary with each program. Those rules do change from time to time, and the designers of the program imagined that the ministry overseeing the apprenticeships would update the rules on the live system on administration screens, and the system would store the rules in the database.

A similar design was imagined for controlling the ministry’s case workers and offices. Each case worker would be tracked along with the individuals or institutions they were auditing. A workflow system was envisaged that would assign audits to offices, case workers and managers.

For example, when a new restaurant was added to the system, a case would be opened at a nearby office, and assigned to a caseworker. The caseworker would visit the office and check that the qualified instructing chefs were employed there. The caseworker would also do an inventory of equipment and facilities, and the system would validate such things as that pastry apprentices work under a proper pastry chefs in kitchens with ovens. And those rules could all be changed at any time in response to changing regulations or practices by the ministry.

The team’s management decided that since the application would just be an empty shell, the actual business analysis would consist of gathering requirements and generating data for the tables. The software itself was obviously trivial¹ and could be generated in parallel with the business analysis, delivering a huge time saving over her company’s traditional waterfall model where analysis was completed in its entirety before the first line of code was written.

Alas, the project was not the success its customers, managers, and architects expected. There were many reasons it never lived up to their rapturous expectations, but one stands above the others: The success of the system rested on correctly configuring the various tables that controlled its rules engines, but there was very little time, attention, or process devoted to configuration.

The team failed to recognize that they were going to be doing a lot of duck programming.

what is duck programming?

Duck Programming is any configuration that defines or controls mission-critical behaviour of a software system that is thought to be “not programming” because it doesn’t appear to involve programmers, programming languages, or programming tools.

When I see a bird that walks like a duck and swims like a duck and quacks like a duck, I call that bird a duck²

Duck programmed systems walk like programming, swim like programming, and quack like programming. It’s just that people fool themselves into thinking “it’s not programming” because it isn’t code.

As described, the project’s system was designed to be nearly entirely duck programmed through the use of database tables that would be updated live in production. Rules engines aren’t the only software architecture that can be abused through duck programming: “Soft coding” is the practice of extracting values and logic from code and placing it in external resources such as configuration files or database tables. Soft coded systems are also fertile breeding grounds for duck programming.

Duck programming isn’t an architecture or an implementation, it’s a management anti-pattern, the failure to recognize that updating rules or soft coded values is programming just like updating code.

why duck tastes so good

When designing systems, the temptation to include duck programming is seductive. For one thing, it’s easy to ignore or vastly underestimate the amount of work required to do the duck programming. In the project described, the team worked hard to estimate the work required to perform the code and implement the various screens. Alas, by “code,” they only meant the shell. The configuration of the system through the various rules was “Left as an exercise for the reader.”

Budgeting time and resources for the “code” programming and hand-waving the effort required for the “duck” programming makes projects appear easier and cheaper than reality will dictate.

Duck programming also exposes projects to “Naked Risk,” the possibility that bad things will happen without safeguards to prevent it or processes for recovering from disaster. Duck programming can be seductive to development teams because it pushes a lot of project risk away from the project team and onto the shoulders of the users. If something goes drastically wrong, the response from the team will be a shrug and the cryptic notation PEBKAC.³ The system “works as designed,” thus any problem is the fault of the users for misusing it.

Finally, duck programmed systems seem more “agile” in that major changes can be made “on the fly” without reprogramming. Let’s speak plainly: “Without reprogramming” doesn’t really mean “Without those pesky and expensive programmers.” It really means “Without all the project overhead of writing requirements, writing tests, managing a small project to implement the changes, testing, and signing off that it has been done as specified.”

Project management overhead is necessary because organizations need to plan and budget for things. Most organizations also realize that changing systems involves substantial risks of doing the right things the wrong way (defects), the wrong things the right way (requirements failures), or the wrong things the wrong way (total disaster). Duck programming avoids overhead at the cost of ignoring planning, budgeting, and risk management.

dangerous but manageable

Duck programming is dangerous, for exactly the same reasons that modifying the code of a live application in production is dangerous. Let’s look at the ways in which programming teams manage the danger. Think about the process for “ordinary” programming in code. Hopefully, you agree with the following common-sense practices:⁴

1. Requirements are documented–whether simply or elaborately–before code is written.
2. Code is reviewed before being deployed.
3. Automated tests are run to validate that the code behaves as expected and no unexpected defects are present.
4. Code changes are first placed in a test or staging environment for human testing before being deployed live.
5. Code can be “reverted” to a previous state. Changes can be quickly highlighted with a “diff” tool.

Now let’s think about a typical duck programmed system or module:

1. Requirements might be hidden in emails requesting changes, but since these are just actions to be performed on the system rather than formal projects to update the system, they may not have the same gravity as requirements for code changes.
2. Changes are live immediately, so there is no review other than double-checking a form and clicking “Yes” in response to “Really foobar the financial administration system?”
3. There are no automated tests, and no way for the end users to write them.
4. Changes are live. Testing on staging is typically limited to verifying that the duck programmable system can be duck programmed, not testing that the duck programming itself works.
5. Reverting is typically very challenging, as in many systems it requires reverting part of a database and carefully managing the consequences with respect to all related data.

There are no controls to minimize the possibility of disasters, and no processes for recovering from disasters. Imagine you were interviewing a software team lead and he told you, “We don’t use source code, we work directly on the live system, and we don’t test, we simply fix any bugs our users report. If anything really serious goes wrong, I suppose there’s a system backup somewhere, you should ask the Sysadmins about that, it isn’t my department.” Madness!

how to manage duck programming

Duck programming is manageable. It starts with recognizing that while it may be designed to be carried out by people who are not professional coders, it is still programming, and must be managed with the same processes you use to manage code:

1. Document requirements for the duck programming using the same system the team uses for programming in code.
2. Stage changes through testing and/or staging environments, then deploy the validated changes to production.
3. Build a system that allows users and analysts to write and run automated tests for the duck programmed functionality.
4. Do not allow live changes to duck programmed systems.
5. Build reversions and change management into the duck programming system.

These five simple points are not as difficult as they may seem. Most software systems have a ticket application for managing work on bug fixes and features. Teams can use the exact same system for all “duck programming” changes. Some systems are smart enough to tie a feature request or bug report to code changes in the source code repository. Using techniques described below, duck programming changes can also be checked into source control and tied to tickets.

Most programming tools revolve around text files. One way to bring duck programming in line with code programming is to find a way to manifest the duck programming as text files. For example, Domain-Specific Languages can be written in text files that can be checked into the source code control system just like ordinary code.

Data-driven duck programming can be set up to export to and import from text files. Those same text files can be managed like any other code change. For example, instead of making changes to a live system, changes can be made in staging, validated, and then exported to a text file that is imported into the production system using an automated deploy script.

Most automated testing tools can be set up to allow non-programmers to create stories and scenarios in remarkably readable code, such as expect(case).toHaveAnOffice().and.toHaveACaseWorker(). Writing automated test cases has many benefits, so many that it is nearly ludicrous to propose developing a non-trivial software application without a substantial body of testing code. Besides catching regressions, readable test code documents intent. Test code acts like a double-entry system: Changes must be made in the normal or duck programming “code” and in the tests, and the two must match for the tests to pass.

The process for deploying duck programming to production can also be managed like the process for deploying code. Changes to table-driven systems can be made in staging, tested, and then exported to text files and imported into the live system’s database with automated deployment tools.

summary

The project described should not discourage anyone from contemplating building a system around rules engines, programmable workflow or domain-specific languages. There are many successful examples of such systems, and our developer went on to create several duck programmed applications himself. He learned from his experience that with a little common sense and appropriate process, duck programming can be a successful strategy.

By software consulting standards, Unspace Interactive is a small boutique. As a byproduct of our small size and close relationship with the startup community, more than half of the Request for Proposals¹ we consider are for what I call “Software that Powers the Startup.”

The typical RFP for Software that Powers the Startup is from an entrepreneur that wishes to launch a web-based technology business. The request is that we develop a plan to design and build the software that will make the startup dream a reality. In twelve weeks, without fail :)

While the RFPs vary in sophistication from an email with some ideas all the way to elaborate screen mockups created in Photoshop, they nearly all omit vital requirements that define critical business functionality. I see this RFP “blind spot” so often that I have developed a standard question to ask, one that invariably opens a massive can of worms.

What is this question I ask?

“Imagine your software has a dashboard, a single page that shows you at a glance the most important information you need to know to do your job as the company President. What’s on your dashboard?”

focus

If you log into Facebook, your “home” view is a kind of dashboard. There is only so much screen real estate, and you only have so much attention. Thus, the design of the Facebook home page is a statement about what Facebook the company believes is important to you.

Likewise, a business dashboard is a statement about what the entrepreneur believes is important to the success of the business. There is only so much space, so much time to develop dashboard features, and the entrepreneur only has so much time to look at the dashboard and figure out what is going on with his business.

The reason to ask an entrepreneur to describe his dashboard is that it forces him to think through and articulate how he plans to run his business.²

two bicycle shops

Imagine two nearly identical RFPs for online bicycle shops. One is for BMX bikes, one for Commuters. Both describe online shopping sites where customers can browse through models from various manufacturers, compare features and prices, and even customize the bike they want before buying it online and having it shipped to their door.

Given two nearly identical RFPs, should we end up with two nearly identical proposals? Almost certainly not. Although both businesses may appear almost identical to the bike-shopping user, they may be radically different to their respective entrepreneurs.

Perhaps our BMX company relies on optimizing operations. The founder’s business strategy is to maximize his cash flow. He cares deeply about metrics such as his inventory turnover. He wants to be alerted to stock that is aging so he can cut its price and move it quickly.

Our Commuter store may rely on optimizing marketing. The founder’s strategy is to maximize margins. She cares deeply about metrics such as average revenue per customer broken down by source. She wants to monitor her product profitability and advertising effectiveness.

To do a good job of proposing a project for our respective entrepreneurs, we would need need to understand these important differences. Asking about the dashboard kick-starts that conversation.

happy endings

Whether we’ve ended up building a dashboard into the initial release or not, I can say with confidence that every investigation that began with the question “What’s on your dashboard” has ended well for the client and for Unspace. At some point in the future I may be handed an RFP for Software that Powers the Startup with substantial attention paid to the business’s operational focus.

Until then, I expect to go on asking this question.