Unspace Blog

Throne of JS

2012-03-08T00:00:00-05:00

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

We Make Pickup Trucks

2012-03-05T00:00:00-05:00

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.

Ruby Job Fair 2012

2012-01-18T00:00:00-05:00

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.

Duck Programming

2012-01-08T00:00:00-05:00

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:⁴

Requirements are documented–whether simply or elaborately–before code is written.
Code is reviewed before being deployed.
Automated tests are run to validate that the code behaves as expected and no unexpected defects are present.
Code changes are first placed in a test or staging environment for human testing before being deployed live.
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:

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.
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?”
There are no automated tests, and no way for the end users to write them.
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.
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:

Document requirements for the duck programming using the same system the team uses for programming in code.
Stage changes through testing and/or staging environments, then deploy the validated changes to production.
Build a system that allows users and analysts to write and run automated tests for the duck programmed functionality.
Do not allow live changes to duck programmed systems.
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.

As noted in Trivialities: “Trivial” is programmer slang for “I understand what to do and I’m ignoring how much time it will take to do it,” much as one might say that adding two large numbers by representing them as piles of pennies, pushing them into one pile, and then counting the pennies is a “trivial” exercise.↩
James Whitcomb Riley (1849–1916)↩
“Problem exists between keyboard and chair.”↩
Many organizations have even more practices, but these are fairly minimal and commonplace in 2012.↩

What's on your dashboard?

2011-09-06T00:00:00-04:00

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.

A Request for Proposal (or “RFP”) describes a piece of software as the client sees it in his mind. The RFP purports to provide all of the information a consultant or custom programming team needs to propose a project to design and implement the software.↩
It is not necessary to ask this exact question. You could describe a notification system and ask, “When should you be notified?” RFPs often ask for flexible reporting systems: Instead of deferring the details until later, you could also spend time on the management reports up front. There are many ways to get to the same place, the important thing is to dive into how the entrepreneur plans to manage his business, not just how he sees the software from the end user’s perspective.↩

Strong Opinions, Weakly Held

2011-06-27T00:00:00-04:00

Paul Saffo is credited with inventing the mantra, “Strong opinions, weakly held.” In 2008, he wrote¹:

The point of forecasting is not to attempt illusory certainty, but to identify the full range of possible outcomes. Try as one might, when one looks into the future, there is no such thing as “complete” information, much less a “complete” forecast. As a consequence, I have found that the fastest way to an effective forecast is often through a sequence of lousy forecasts. Instead of withholding judgment until an exhaustive search for data is complete, I will force myself to make a tentative forecast based on the information available, and then systematically tear it apart, using the insights gained to guide my search for further indicators and information. Iterate the process a few times, and it is surprising how quickly one can get to a useful forecast.

Since the mid-1980s, my mantra for this process is “strong opinions, weakly held.”

The process he’s describing is iterative. At each step, you come up with the best forecast you can despite limited information, and then you act with confidence. Where others would be tentative, would delay action to perform more research, or would hedge their bets, you move forward.

However, your strong opinions are “weakly held.” You mix action with further investigation. You deliberately search for flaws in your strong opinions. You evolve to have new opinions. And of course, these new opinions are also strong opinions. You move forward again and repeat the process.

“Strong opinions, weakly held” is a dedication to taking a stand in the face of conflicting information and uncertainty. It’s also a dedication to continuous reflection and self improvement, a rejection of “legacy” thinking. It’s a rejection of clinging to old ideas just because nobody’s disproved them yet. If nobody else has disproved your strong opinions, you disprove them yourself.

Unspace is an opinionated software development company

We describe ourselves as “An opinionated software development company.” This doesn’t just mean that we have opinions. It means that we have strong opinions, weakly held.

It means that we have strong opinions about the best way for us to build world-class software for our clients, even though the entire software development industry is built on a massive pile of uncertainty. We don’t think we know the One True Way to develop software. We know that software engineering is still in its infancy as a practice. Great software has been written in Assembler, Lisp, C, Visual Basic, Perl, Haskell, and yes, PHP.

We don’t think that other opinions are wrong. We aren’t divas who refuse to subject ourselves to anything less than some narcissistic “standard of perfection.” But we do think that based on the evidence we’ve gathered and the experience we’ve gained, our tools and practices are useful, the equivalent of Paul Saffo’s “useful forecast.” We know they’re useful: We’ve iterated over them repeatedly, and we continue to iterate over them.

One of the sources of our strong opinions is the belief that the whole is greater than the sum of the parts. Consider the opposite of strong opinions: The belief in “best practices.” Best practices are the standard procedures that other companies in the industry are following.

Strong opinions vs. best practices

A naïve way to follow best practices is to survey companies and ask them how they develop software (If you are a CIO, you can save yourself the trouble and purchase the survey results from “analysts” who make a living charging vendors for the privilege of being named as leaders in—I am not making this up—something called a “magic quadrant”).

For each element of software development practice, you collect statistics. Thus, you can determine what the most popular hiring interview questions are, the most popular text editors or IDEs, the most popular source code revision systems, the most popular issue tracking systems, the most popular programming languages, the most popular project management methodology, the most popular test frameworks, the most popular QA process, and so forth.

The flaw in this approach is that these decisions are not independent variables. Some practices work well with others, some conflict. If you follow a waterfall project management practice, you will get very poor results if your developers practice YAGNI. If you practice continuous refactoring, you need to also practice continuous integration and especially automated testing.

As noted above, doing whatever seems to be popular—even if it’s using fashionable tools like Coffeescript or Node.js—is symptomatic of having weak opinions, not strong opinions. And our experience is that the results are also weak: The aggregate result of choosing popular tools and practices is that some work well with each other but some actively hamper each other.

Unspace is in the business of lowering risk

Why do people do this? Because there’s a lot of uncertainty about the best way to develop software. Gather a bunch of really smart people in one room and ask them how they do it. If you have ten people, you’ll emerge with fifteen opinions. As an industry, we can’t even agree on whether strong typing is a win. Simon Peyton Jones and Anders Hejlsberg say it is. Paul Graham and Alan Kay say it isn’t.

Nobody ever got fired for following “best practices.”

Given the uncertainty, social safety beckons in the footsteps of others. Nobody ever got fired for following best practices.

As “safe” as it may seem for someone’s career to pick and choose the best practices, we are not in the social safety business. We are in the shipping software business. Think about our business model for a moment. Why do clients engage us? To develop software, of course. Why don’t they do it themselves? Because it’s more advantageous to hire us than to do it themselves.

So how do we make it more advantageous to hire us than for our clients to do it themselves? Well, there are two basic business models we can follow. One is to be less expensive by charging less. If we can charge clients less per hour than they would pay for their own developers to do the exact same work, it’s cheaper to hire us than to develop software in-house.²

The other way to be more advantageous is to be less expensive by lowering the risk. Since working with Unspace means less risk than doing it themselves, clients insure against the possibility of disaster by hiring us. Given the enormous expense associated with failed software development projects, our clients save a tremendous amount of money when they hire us.

Lower risk saves money in two ways. Obviously, averting disaster is an incalculable savings. A project that seems cheap at the outset wastes everything if it fails. But not all failures are massive disasters. Some projects end up taking a lot longer than expected. Some are fraught with gotchas along the way that require continuous rework. Lowering risk throughout the project avoids the disasters, but it also lowers the cost of projects by wasting less time and money on things that don’t work.

Obviously, we like the “lower risk” model. It avoids disaster and is less expensive. But to make it work, we can’t simply do the same thing that everyone does. We can’t afford to have weak opinions, to use whatever hodgepodge of best practices seem to be surfing the hype wave this week. For that reason, we have strong opinions. We select people, tools, and practices based on how well they perform separately and together.

We accept that there isn’t enough (or any!) unbiased, empirical research answering questions such as whether C# and Linq is better or worse than Ruby and ActiveRecord, and we accept that popularity is not a substitute for wisdom. But we make our choices and we make them strongly. We invest heavily in learning our tools. We study, we practice, we debate, we examine. We place our code in the public eye³ and learn from the feedback we obtain.

Risk and project management

Our strong opinions extend to more than just tools. We have strong opinions about having an iterative, agile process. Given our business model of lowering risk, this makes perfect sense. The entire mantra of strong opinions, weakly held is to continuously iterate in the face of uncertainty. What could be more uncertain than the outcome of a software development project at its outset? The “strong opinions, weakly held” process is the process of forecasting and iterating to improve your forecast until it is a good forecast, until you’ve driven the uncertainty out.

We start every project with a great deal of uncertainty. But do we attempt to develop a “telephone book” specification in a vainglorious attempt to eliminate the illusion of uncertainty? No. We come up with the best estimate we can given limited information. In other words, we have an opinion. And then we start work. That’s what makes it a strong opinion: We commit to it, we don’t hesitate, trying to pad our estimates out with details that make them look impressive without significantly reducing risk.

Our opinions are weakly held. We do not put the plan in a glass case. We iterate. We review. We probe and test. We work with clients to develop prototypes and alphas and other manifestations of working software than can be poked and prodded and tested to see if our strong opinions need to be revised or even discarded.

This is an incredibly important foundation for how we reduce risk for our clients. Many of our clients approach us with a draft specification and two questions: “How much?” and “How long?” Answering those questions as best we can and then blindly following “the plan” does not remove any risk from the project.

The client begins the project with a tremendous amount of uncertainty, and answering those questions gives the illusion of reducing the uncertainty. But in fact, the uncertainty is still there. It is only by constantly re-evaluating and recalibrating our expectations that we reduce the actual risk in the project.

Unspace. Yes.

Others have popularized the notion that being “opinionated” means saying “No.” We believe this is true, and that saying “No” is a good thing. Another way to put it is that being opinionated means being focused. Our clients are more successful when they say “No” to non-critical features. Those same clients are saying “Yes” to delivering software earlier with fewer defects. Those clients are saying “Yes” to iterating more quickly and thus reducing uncertainty and risk. We try to take the same approach in everything that we do. Less is more, and the way you achieve “Less” is by saying “Yes” to less by saying “No” to more. Relentlessly.

Perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away—Antoine de Saint Exupéry

But we do not fall in love with the sound of the word “No.” Our strong opinions are weakly held. We attack our own opinions. We question them. Today we use Haml for nearly all of our projects, to the point where a recent project was using Haml in the browser, performing the rendering in Javascript. Tomorrow we may discard Haml as a tool that was right for its time and place, but not for this time, not for this place.

That doesn’t mean we’ll swap Haml for something a little bit better, or even a lot better. It means we’ll think about our entire tool chain, our entire process, and ask ourselves which piece or pieces no longer fit, and what changes need to be made everywhere to continue to offer our clients a tremendous advantage.

Having strong opinions, weakly held isn’t about saying “No,” it’s about the right way to say “Yes.”

Also, Bob Sutton has some interesting things to say about why having strong opinions, weakly held is good for you as a person.↩
In the case of business model centric startups, the cost to engage us and the time to launch a product are dramatically lower because the client does not have to staff a team from scratch. That being said, many of our clients already have developers on staff but choose to employ us for building out new products or functionality that is riskier than extending the functionality and lifespan of existing applications.↩
This post is far too short to list all of the open source projects that have come out of Unspace and its members over the years, but the most popular are probably the Haml template language and its excellent companion, Sass.↩

RESPECtable Employment, rooftop RPN, and the return of Giles Bowkett.

2011-04-28T00:00:00-04:00

Welcome to the old blog on Unspace’s swanky new website! We’ll be transferring over to a new rethink model next week, but rest assured that all archived article links will remain in tact.

In the interim, we’ve decided to celebrate by launching registration for a few events that we’ve conjured up:

We’re having a hard time coming to grips with the fact that this is our third job fair, so we decided to brand it as old as we feel.

Just like it says on the tin, this is a box social-styled event where prospective employers will be able to boast of their enviable jobs before mingling with all-star job-seekers over scones and questionable tea.

We decided to follow this up with another special edition of Rails Pub Night on the Unspace HQ rooftop, just because we had so much fun (from what we remember) last time. All-inclusive drinks, food and BBQ will be on offering for free, so long as you’re one of the lucky devils who register on time.

Registration for both events open here! http://rubyjobfair.ca

Technologic is back after a winter S.A.D’s hiatus, and we’re beyond excited about our first offering of 2011. We don’t know what Giles is speaking about yet, but historical evidence dictates that it will blow your mind.

We’ll be adding talk and party (which may resemble the Hacienda) details shortly - we sold out the last Technologic in 48 hours, and expect no less of this one. Remember that your admission includes unlimited drinks and eats for the evening as well - we challenge you to ferret out a more stellar deal in T.O.

Register ASAP (no, seriously): http://technologicto.com

Open Data, Open City

2010-09-22T00:00:00-04:00

I met with Jaclyn and Kim from the Martin Prosperity Institute (think Richard Florida) to discuss my vision for open data in government and in the world in general. I relayed several stories that hopefully clearly indicate that Data Literacy is an obvious way to make the world better.

They were composing a series of not-position-statements that identified issues which should be considered important going into Toronto’s [terrifying] upcoming mayoral election. One of those issues was open data, which is near and dear to my heart.

You can read the article here, or go ahead and download the PDF of the discussion document here.

Kudos to my fellow source David Eaves, a man far more eloquent in these matters than I could hope to be.

Questionable validation

2010-09-08T00:00:00-04:00

Lindsey Harper posted an interesting article about using Amazon Mechanical Turk to test her start-up hypothesis.

Many of the comments were not in favour of the idea, because of the [perceived?] inherent selection bias of asking Turkers for their opinion. Only she can say whether their feedback is helpful; she’s in stealth mode so it’s hard to say for sure without knowing her idea.

My issue is actually with the quality of the test, regardless of who she asked. The problem is that it’s been amply demonstrated in studies that if you ask people if they’d use a service or purchase a product, they will often say yes if they think you want to hear yes. There is a significant primal desire to tell people what they want to hear. That’s why finding mentors who aren’t afraid to burst your bubble is so important. I strongly suggest that you consider reading Influence: The Psychology of Persuasion if you’re interested in understanding why people do the things they do. It’s a fascinating book.

If Lindsey really wants to test her idea’s sales potential, she needs to immediately follow up someone who says they will purchase a product with a request for them to purchase your product. Customers pay you money, so they need to open their wallets in order to demonstrate being a real customer. Say “In that case, would you be willing to become my first customer? If you pay right now in advance, I’ll give you the first year for 60% off!”

Many founders are genuinely alarmed at how quickly those YES answers become awkward NO answers. Apparently, your sure sales aren’t so sure about why they need your product. Perhaps you’re not making them happy or getting them laid?

A good measure is whether you can easily find 10 people that will happily give you real money to get your product as quickly as possible. Let’s face it: you’ll have a hard time convincing an investor to get on board if you can’t find just 10 people. This fellow thought it would take 6 months to get 200 customers. It actually took 30 months!

TL;DR: Founders need to be able to get 10 people to pay them in advance, or their market doesn’t exist. You shouldn’t worry about scaling your technology stack to millions when it might take 30 months to get to hundreds. Your sales process always takes way longer than you could ever expect. And perhaps most importantly:

People always tell you what they think you want to hear.

I'm not a spammer, I just need to blast these potential customers

2010-09-05T00:00:00-04:00

One problem programmers and other geeks simply cannot code themselves out of is dealing with the beliefs and expectations of that most elusive demographic: everyone else.

Right this moment, there is a large group of well-intentioned small business owners that are trying to use MailChimp to deliver a newsletter. They aren’t particularly technical folks, and the emails are intended to round up some new paying customers. While they have made some effort to remove the emails belonging to people that aren’t customers for a reason, the tolerance for unsubscribe requests is just 1%. Even scarier, only 1 in 1000 recipients can click “Report as Spam” before the campaign is aborted and the sender’s account is placed under review pending a serious warning.

These entrepreneurs consider these email “blasts” an important part of their business strategy. Isn’t it bad enough that they have to pay to send out emails? They never used to have to pay, so why not just fire up Outlook and BCC 800 people? They aren’t spammers, after all; just people who have to send out marketing emails to all of the folks that haven’t paid them money in a while. And since they aren’t spammers, they won’t send out emails to people who are paying them — that would be unnecessary!

Cognitive Dissonance

Hopefully you geeks haven’t gnashed away your molars reading this. You could use a dozen harsh analogies to demonize these “stupid newbies” that don’t get why what they’re doing is wrong. The abolition of slavery was likely viewed as a significant inconvenience to many former slave owners — a real pain in the ass! Morality and ethics change over time; anyone who watches Mad Men marvels at how backwards social norms were just 50 years ago.

We’re all going to be seen as dinosaurs someday soon. Discussions about the best Rails hosting strategy will seem as quaint and historical as watching videos of Douglas Engelbart demonstrating the mouse. Adaptation to a new way of doing things is not easy, and people will work very hard to maintain the status quo. If you’ve already made the switch — think Subversion to Git — that doesn’t make you’re better, smarter, or more entitled to respect.

Instead, it’s really just an opportunity to demonstrate your true colours. Will you help people do things better, or leave them in the cold?

Clean Up Toxic Spills

Meanwhile, back at the ranch: what is to be done with our unintentional spammer friends and their out-dated mailing lists? Can’t we let them do one last blast just for old times? It’s not actually illegal, is it? (Yes, it is.)

The ugly truth is that their lists are probably too risky to be of practical use. When you can only have 1% of your list unsubscribe, it means that you cannot use a service like MailChimp to clean up your list. They will shut your ass down, hard. You’ll get one warning, and that’s it. If you try to send the same emails through GMail, they will shut down your account. And if you attempt to set up your own mail server, your ISP will have something to say about it.

So how are they going to send out these emails? What’s the solution? They’re tired of hearing about RBLs and assassins and IP bans! They just want to email those legitimate future potential customers so they can go put the kids to sleep.

How Legitimate Marketers Can Prevent Spam Complaints

You know the answer already: they aren’t going to send those emails successfully. They might need this explained to them several times, but ultimately they don’t get to make up new rules just because they don’t understand what they’re doing wrong.

Someone in their position needs to start over from scratch using a double opt-in system, preferably making use of the excellent tools on their mail provider’s site. They must regularly prune their lists as customers move on. It’d be great if more internal systems used the API to remove old customers after 3-6 months, because ultimately there is no substitute for permission. If someone doesn’t remember signing up to your list, then you don’t have their permission to send stuff to them.

Ask Before You Blast

As geeks we need to do better at remembering how unintuitive, frustrating and nerdy this stuff seems to people who are just trying to get a job done. Making people feel stupid compounds the problem, because you’re probably not as subtle as you think you are. You might be great at poker, but chances are if you think someone is dumb, they can figure that out in no time flat.

Email is a privilege, not a right

If you go to any bookstore, there’s an entire section of online marketing titles that all encourage the reader to broadcast their sales message via email. It’s like cold calling, except you can do thousands of people at a time. Progressive marketers get it — or have moved on to Facebook and Twitter — but some of the bad apples genuinely don’t care about the ramifications of sending spam email. They need to generate sales, and if the conversion rate for spam is 1 in 10,000 then they’re just going to have to send a lot of emails. Those people aren’t just selfish, they’re criminals.

What of the accidental spammer, though? How do we break them of their regrettable bad habits? Can they be shown a better way?

With patience, people will learn to change how they perceive their relationship to email. The only folks they should be sending to are people who are customers that have specifically opted in — just buying something does not make it okay to email them forever. Furthermore, recipients should be getting actual newsletters, not a sales pitch. Harassing 1000 people might generate 4-5 orders, but it’s not worth getting your email account shut down to get them.

As it turns out, a genuinely interesting regular bulletin will reward the sender with highly engaged repeat customers that give good feedback and recommend your products to their friends.

In other words, you’re not looking for permission to advertise at them; you’re giving them a channel to communicate how much they love your products to each other. It’s constructive, it’s legal and it will make you more money with less hassle in the long run.

Out With Dad

2010-09-02T00:00:00-04:00

One of my favourite things about Unspace is the wide variety of side-interests people on our team bring into the dynamic. We have several avid cyclists, Doctor Who scholars, a tattoo artist and now our office manager Eric Taylor is producing a great new web series called Out With Dad.

Sometimes your friends do something that is important to them, and you have to like it “no matter what”. I’m happy to say that this is not one of those times. Out With Dad is awesome, and I look forward to new episodes when they come out every few weeks.

Here’s the first episode:

The fifth episode came out today and features the famed/notorious Unspace roof patio in an extended cameo:

You can watch all of the episodes here.

Need to do a perfect investment pitch? Stop reading inspirational blog posts and start hustling

2010-08-03T00:00:00-04:00

Yesterday I participated in my first start-up pitch. I learned that you can prepare as much as you want for something, but you wont know what you’re going to do wrong until you start doing it.

I watched many videos and read no less than 25 eloquent articles from Hacker News on putting together the perfect deck. Things not to do in a pitch. What unfair advantages do you need?

We practiced our transitions and endlessly debated the subtle nuances of our screenshots. We needed to convey passion, trustworthiness and conviction while demonstrating the viability of our concept and being the kind of dudes you’d want to hang out with.

My preparations were not a waste. I learned a ton and was forced to ask lots of hard questions about what we’re working on. Luckily I really love business development and so even though I’ve been really anxious I can still say I’ve been having fun. People in our community like David Crow really stepped up to help, and I really encourage all of you wantrepreneurs to go through this process even if you have a rich uncle and don’t need to raise funds.

All of the preparation in the world couldn’t change the simple fact that we were doing it wrong.

Our idea is great but our first presentation was loaded down with “buzzword-laden socialist hippie kumbaya bullshit” and we failed to explain the core business value proposition on the first slide.

This was exactly what we needed to hear, and we’re already making great progress on changes. We want to nail it next time. We’re refactoring our pitch, the same way we iterate when we refactor our code. Luckily it was a “no harm, no foul” test run and all of the feedback we received was coming from a very positive place. (Thanks, Rick!)

Closing metaphor: let’s say you’re a pro hockey player who loves to skate. You could just skate all day! Thing is, your boss only cares about how many pucks you send into the other team’s net. You could be the best skater in the game, but you have to prove that you’re able to score or else they won’t let you see the ice.

Upcoming speaking engagements

2010-07-23T00:00:00-04:00

I (Pete) have been speaking regularly about Open Data and Data Literacy. There are two upcoming opportunities to see what I have to say:

July 23, 2010: good people drinking wine and talking to each other in Toronto, ON

Pete believes that Open Data isn’t just for geeks and economists anymore, and that Data Literacy for all would change the world. He’s writing a future Oprah’s Book Club title about how to get rich, expose corruption and win the Order of Canada using just Excel, some rope and a stick of gum.

August 14, 2010: FOSSLC 2010 in Ottawa, ON

The Open Data movement is picking up steam in a big way. Some government or NGO seems to announce plans for full transparency every week. Then you’ve got a guy like Rob McEwen creating billions of dollars of wealth when he decided to open source his gold mining company’s geological data. Still, data today is like the web was in 1995… all over the place.

We need a data commons: a place for people to discover, consume, contribute, discuss and purchase data. This talk discusses how such an infrastructure could work, and how we must bring tools for working with data to non-technical individuals.

You can sign up to FOSSLC here.

What are the problems that need to be solved?

2010-06-11T00:00:00-04:00

As it turns out, humans are really bad at answering questions about what they need. Often if they knew they needed it, we would be competing to provide the best solution for it.

This is the difference between inductive and deductive analysis. An example of deductive analysis would be tasking a student with applying pattern matching to a known domain to find an expected result. Inductive analysis is when you don’t actually know if there’s an answer to be found. Obviously this is a bigger challenge with a more interesting payoff, but I believe inductive analysis is a skill that can be practiced.

Demand Media realized that humans were really bad at coming up with problems to solve, so they started buying bulk search engine results and harvesting queries where people did not find what they were looking for. They then farm out these non-obvious (and often highly specific) needs to videographers to produce low production value clips that nail these never sexy “how do I fix the towel rack in my bathroom?” type questions.

Demand’s properties dominate the search results advertising for the extreme long tail of semantic Q&A on the web. Last I heard they are releasing thousands of videos a day, and making hundreds of millions in revenues.

If you want to solve a big problem, apply the same inverse deduction logic to the question of which start-ups are really needed (vs. the ones people keep building over and over) and you will be the next Richard Branson.

Raising capital in Canada

2010-05-14T00:00:00-04:00

Today at the Toronto Software Developers Lunch there was some conversation about how hard it is to raise money for technology ventures in Toronto. I was surprised that this was considered to be the hard problem, as I’ve always felt like there’s always money nearby in Toronto if you’re talking about good ideas and have a great team.

Of course, I’m pretty outspoken about my belief that most ideas are terrible. We live in a world where someone who has no business founding a tech start-up can get investment, hire a team (who presumably need jobs) and launch to market all without talking to a single person that is neutral enough to tell you to stop while you’re ahead. I’ve personally told potential clients that they should take the money they were about to burn on a concept that would never work and invest it in an amazing vacation with their family.

So yeah, sometimes you should just stop. It can be hard, because it seems like many developers are compelled to build the same things over and over again.

But let’s say that you’re really on to something and you’re thinking about raising capital in Toronto. Sure, there’s MARS — they offer venture advice and host angel forums. There’s also StartupNorth and their occasional Founders and Funders dinners. We live in an incredibly networked city with events just about every night. Plus when you factor in SR&ED and other grants, it seems like Toronto is the best place on earth to build a start-up. After all, we get to build our products in relative secrecy if we desire it — something that would be impractical in San Francisco.

So without further ado, this is my list of resources concerning VC and angel investment. I’m not a huge fan of VC politics, so my advice will tend to skew towards angel backing.

If I launched a start-up — if you click on one link, make it this one.

Brad Feld’s Term Sheet Archives is a really deep library of raw information. Required reading before you uncap that fancy pen.

Series Seed documents are free-as-in-beer term sheets that many angels are now agreeing to use. This article discusses how they are different from from typical Series A financing documents.

All about F-shares. No, this is not a wife swap but instead an interesting class of shares separate from common stock that entrepreneurs can receive when founding a company. Many investors seem to dislike F-shares, but perhaps they need to open their minds, loosen up and pop another quaalude.

What is the right amount of money to raise at a start-up? Let me know if you figure that one out.

What’s the difference between an angel investor and a venture capitalist? This does a pretty great job of answering that question.

Angels are just people, and it pays to be able to approach them with a cause they can believe in. This is often what differentiates angel mentality from that of a venture capitalist. Did you know they used to be called adventure capitalists? This article talks about the psychology of an angel investor.

Venture Hacks has become a very good source of news and information for folks raising capital. However, what I really find exciting is their relatively new Angel List. The deal is that if you submit your pitch and they think it’s good, they will send it out to a huge list of highly influential angels — all of the big names including Ron Conway and Chris Dixon.

Of course, sometimes you really do want to go after VC money and it pays to know who the players are in Canada’s VC industry.

Finally, there are dozens of excellent interviews with founders, investors and dreamers on Mixergy which are chalk full of great information.

What am I missing? Comment and I will continue to update this.

And just before I hit post, I just want to say something real: man, do I ever hate raising money. It fucking sucks. I’m all for making money and building big dreams — some of us have chosen life paths that pretty much demand it. Sure, there are elements of all this that one could argue are relatively interesting… but I hate to think of how much human creative potential has been squashed by the necessity of knowing all of this crap to get anything substantial off the ground.

The State of HTML5 Local Data Storage

2010-05-10T00:00:00-04:00

Of all the new features being implemented as HTML5, I think I’m most excited about offline storage. Despite more and more ubiquitous Wifi, despite the ability to tether our laptops to our 3G mobile phones, as web apps have become more and more sophisticated, the need to be online has often felt like the the last barrier separating the web and the desktop.

There are actually two kinds of offline storage on offer in HTML5. Client-side session and persistent storage (also sometimes referred to with the vaguely misleading “DOM Storage”, or simply “web storage”) is a simple, cookie-like key-value store. The key and value are treated as strings, but it’s possible to store more complex objects as stringified JSON.

If you’ve worked with cookies before, you’ll probably find yourself getting familiar with this storage mechanism pretty quickly. However, there are some significant differences between web storage and cookies:

The browser sends all relevant cookies in the headers of every request, but web storage is held entirely by the browser, until explicitly sent somewhere by client-side scripting.
Cookies have a built-in expiration mechanism, but data in web storage has no expiration - it will remain through page refreshes, browser restarts, OS reboots, etc. until explicitly deleted.
While all relevant cookies are exposed to javascript through the cookies object, allowing scripts to “walk” the entire collection of cookies, there’s no such mechanism with web storage - if you don’t know the key, you can’t get the data.
Note that unlike cookies, which can be restricted by server domain as well as path, web storage can only be restricted by domain. This can be a security issue for multi-owner sites that don’t use subdomains. It’s also possible to store data with no domain restrictions, making it available on any domain (but you still have to know the key).

The other kind of offline storage - variously called “JavaScript Database” (Webkit), “Storage” (Mozilla), Web SQL storage or “webdb” (various) - is far more robust. This is offline storage using real SQL - Webkit and Mozilla both use an embedded SQLite engine, and expose it through various client-side scripting interfaces.

Here’s an example taken from Apple’s developer documentation for Safari:

try { if (!window.openDatabase) { alert('not supported'); } else { var shortName = 'mydatabase'; var version = '1.0'; var displayName = 'My Important Database'; var maxSize = 65536; // in bytes var db = openDatabase(shortName, version, displayName, maxSize); // You should have a database instance in db. } } catch(e) { // Error handling code goes here. if (e == 2) { // Version number mismatch. alert("Invalid database version."); } else { alert("Unknown error "+e+"."); } return; } alert("Database is: "+db);

Unfortunately, unlike “DOM Storage”, the various browser vendors are less committed to standardizing on “webdb” - Opera’s support is still forthcoming, Webkit is fully on-board and shipping, and Mozilla has been vocally skeptical of the whole idea, and labels their API as ‘unfrozen’ - meaning it’s likely to change over time. There’s excellent documentation from both Webkit and Mozilla, but the APIs are drastically different.

Even worse than two drastically different APIs for the two major supporting browsers, the larger developer community hasn’t quite bought into SQL storage, yet. There are concerns that SQLite isn’t the most standards-compatible SQL implementation. Some had hoped to see the browser vendors adopt one of the modern, flexible, “document model” database formats, made popular by CouchDB, MongoDB and SimpleDB. For now, the W3C Working Group has officially declared SQL storage as being “at an impasse”.

In the mean-time, there are some interesting alternatives. If SQL storage sounds suspiciously familiar, it might be because it’s largely based on Google’s browser plugin Gears. Gears has some issues - like the need to handle cases when it’s not installed, or how to “encourage” users to install extra software (Gears is built-in to Chrome, but an additional install on other browsers), but it at least provides a consistent storage API across multiple browsers, and the additional Gears functions are pure gravy (background threads, desktop integration). Unfortunately, it seems development of Gears has stalled, as developer attention has shifted, with focus now on providing native support for these features in Chrome.

Another stop-gap solution is Paul Duncan’s PersistJS, which layers an abstract API interface on top of a variety of browser storage backends. PersistJS uses HTML5 native storage by default, Gears when available, and can fall back to Flash, and userdata behaviors for older versions of IE. (I should also mention that Dojo Storage has similar goals, but PersistJS seemed to cover more browsers, and has a smaller footprint.) Unfortunately, the cost of cross-browser compatibility is that PersistJS’s interface resembles the simple key-value storage you get with DOM Storage. While, as with DOM Storage, it’s possible to store serialized JSON in PersistJS (see examples here), some applications will suffer from poor support for more complicated data relationships.

I’ve been disappointed to discover that none of these implementation options provides any mechanism to support syncing data once the browser is back online! In today’s extremely social environment, the kinds of apps I imagine building with offline storage would need some mechanism to pull user data up to the server when the user is back online, and push any new data out to the browser. (Something like Caleb Crane’s Impel but without the baggage.)

I’m considering writing a javascript library that would layer jLinq on top of an implementation-obscuring storage API, but I suspect I’ll wait until Mozilla’s API reaches “frozen” status. I’d also want a library that would provide some kind of basic support for syncing, maybe something based on Thoughtbot’s Jester.

"Power Tube" by maury.mccown - http://flic.kr/p/SQx6r / CC BY-NC-ND 2.0

"Metro Woman" by Extra Medium - http://flic.kr/p/4doc3C / CC BY-NC-ND 2.0

require 'date' â The 2nd Annual Ruby Job Fair

2010-04-27T00:00:00-04:00

We had such a blast with our science fair last year that we decided to do it again. This year we’re changing things up and going with a “speed dating” structure: 5 minute rapid fire interviews between prospects and would-be employers before rotating to the next person.

Sign up at http://rubyjobfair.ca/

The event itself will likely only take about two hours, but then we’re moving on to Part 2… we’re hosting a BBQ for all Toronto Rubyists on the roof here at Unspace. So even if you’re not interested in the speed dating rounds, you should 100% RSVP for the after-party.

The event will be on Sunday, May 30th at The Rivoli in the back room from 2pm (sharp!) until 4pm. After 4pm and until 9pm we’ll move next door to Unspace. We’re at 342 Queen St. W, Floor 3.

This event is designed to be light-hearted and fun. We want you to take it seriously, even though this might be the only formal job interview you ever have with an Old Fashioned in your hand. Make sure that you bring business cards and expect surprises. Last year we had a visit from Harinder Takhar, the Ontario Minister of Small Business!

Employment.nil? Job Fair was a success!

If you have any questions, let Meghann know. Also, if you work in a place that you could put up some postcards on a board, get in touch!

Stop trying to measure innovation and be a hero

2010-04-02T00:00:00-04:00

In a recent post on his Radar blog, Tim O’Reilly asked “How do we measure innovation?”

The variety of ways that people interpret Tim’s question supports the notion that ‘innovation’ has truly jumped the shark and become a catch-all buzzword. It is now the tech/business equivalent of describing a rock band as ‘edgy’.

Science is the attempt to understand the natural world through repeatable experiments, while technology is the practical application of science to commerce or industry. Wikipedia suggests that innovation is “an invention leading to commercial or social reorganization”.

Alright, then — what are some of the many ways we can quantify innovation? Christian Gray suggests:

buzz and profile
impact and profits
adoption rate
ripple or trickle-down effect
impact over lifespan

Bill Seitz cuts right to the chase, saying that it’s more important to ask why we care. If you type the word innovation more than once a day, you likely seek to:

compare or rate companies and their products
influence policy
uncover demi-journalistic fodder

The last point sounds snarky, but it drives home Bill’s assertion that any metric — be it an index or comparison — is a filter on reality. The very notion of an innovation metric suggests that it will always support the outcome desired by its creator. This outcome is most frequently either the filing of patents… or the incessant and combative blather of tech tabloids.

In “The Myth of Crowd Sourcing”, Dan Woods has a few things to get off his chest about innovation:

Crowds don’t innovate — individuals do.

The notion of crowds creating solutions appeals to our desire to believe that working together we can do anything, but in terms of innovation it is just ridiculous.

There is no crowd in crowdsourcing. There are only virtuosos, usually uniquely talented, highly trained people who have worked for decades in a field. Frequently, these innovators have been funded through failure after failure. From their fervent brains spring new ideas. The crowd has nothing to do with it. The crowd solves nothing, creates nothing.

Jimmy Wales says that the vast majority of articles on Wikipedia are the product of a motivated individual.

There is no crowd of open-source developers ready to attack every problem. In fact, most open-source projects are the product of one obsessed individual who wrote the software to meet his own needs.

What bugs me is that misplaced faith in the crowd is a blow to the image of the heroic inventor. We need to nurture and fund inventors and give them time to explore, play and fail. A false idea of the crowd reduces the motivation for this investment, with the supposition that companies can tap the minds of inventors on the cheap.

Aha! Now we’re getting somewhere. Perhaps we’re abusing the word innovation when we should be proudly calling ourselves inventors?

TL; DR: Innovation can only be measured in the past tense. There is no way to predict whether an invention will come to be seen as innovative — or forgotten without consequence.

Saying that you’re an innovator rings hollow. It’s like referring to yourself as an Expert, or the CEO of a solo start-up. Don’t feel badly, as we’ve been trained to think in these terms by an industry that exists to profit by predicting future ‘innovation’.

And so, dear reader… which side are you on? Innovating for TechCrunch, or heroically inventing the future? Let your dreams be judged by their legacy, not some dipshit pundocrats with high follower counts and a slow news day.

unspace.ca is five today

2010-03-08T00:00:00-05:00

I realized this afternoon that I registered the unspace.ca domain five years ago today.

Ryan McMinn, Anthony Watts and I had gone through some hellish “branding” workshops trying to come up with a name for our new, quasi-legal partnership. We were just a project manager, developer, and designer sharing about 220 feet in an old sweatshop building on Spadina for about six months before we decided that we should band together and go after bigger fish.

Don’t be alarmed, but Unspace was almost called Orchestra.

Unspace was actually Anthony’s password (at the time, obviously) and when he proposed it, it was so much better than all of the other alternatives that we just acted on it immediately. The first Rails Pub Nite — the only one held at C’est What? before moving to The Rhino — followed shortly thereafter, which led to us meeting this crazy punk kid from Florida named Hampton.

It’s been quite the adventure. Ryan and Anthony have since moved on to other things, but we’re all still good friends. That is what’s most important to us.

Needed: Flash/ActionScript dev

2010-02-16T00:00:00-05:00

UPDATE: Thanks to all who replied. The position has been filled.

Are you a Flash developer with strong ActionScript skills?

We’re building a game-like web app that will play audio. We’d love to use HTML5, but browser support isn’t where we need it to be for this. We want a light-weight Flash mp3 player with a small resource footprint. It will be controlled exclusively via a JavaScript interface; there will be no visual user interface.

Here’s what it needs to do:

load, store and play multiple sounds, possibly simultaneously (load via URL, cache with an ID, play from cache given the ID) - and able to load new sounds loaded dynamically
expose methods to JavaScript for play, stop, pause, resume, seek to percent and seek to seconds
register Javascript function callbacks for events such as “swf loaded”, “sound file loaded”, “sound is playing” and “finished playing”

We’re still working through the specifics of issues regarding mixing and simultaneous playback; we look forward to deferring to the experience of the right candidate.

It should also be noted that our client is open to this code becoming the basis of an independent open source project.

If you think you’re the right person to work on this short-term engagement, and have time to meet with us and ultimately complete it by the end of February, please send a brief introduction and an estimate for how much you would charge for this work. Linking to your Github repository is appreciated, so that we can review your previous work.

Attn: Joshua Wehner at audio-flash-dev@unspace.ca