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.

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.”

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

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.

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.

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.