Notional Slurry Logo

Archive for Project

Working out the details of a real options framework

Suppose a prospective client approaches you to do work for hire. In many contracts for technical work, there will also be a requisite nondisclosure agreement (NDA), which may be unilateral or bilateral, but which in either case specifies that you (the contractor) will keep secret certain information regarding the client and contract.

Lacking such a nondisclosure agreement, it’s commonly understood that you could whenever you wish disclose whatever information you like about the name of the client, the nature of the work proposed or done, or even trade secrets you learned in the course of the conversation. Depending on the character and values of the client, one or more of those facts will probably be subject to nondisclosure clauses in the contract they want you to sign. And those clauses may (if you’re not thoughtful or careful) have no expiration date.

I’m thinking of one former client—a large Midwestern corn hybridizer—who made us sign an indefinite nondisclosure agreement that promised we would never state the name of the company. That’s it; just the name.

At any rate, let’s look for a moment at what you’re signing.

As we understand the law, until you sign that contract you possess the option to disclose whatever you want, at any time you want. Within certain extreme limits (libel, slander, state secrets, and so forth).

Let’s give you the benefit of the doubt as a contractor, and assume you’re not interested in revealing the pre-existing trade secrets of your client. Let’s just say you shouldn’t ever do that, and that they have a clear right to keep you from doing that before any are revealed to you, and that therefore the deal is broken if you demand the ability to tell anybody anything.

But common nondisclosure language also covers the broad range of knowledge and information that arise during the course of the project: not just the stuff you make together, but the name of the client, the terms of the contract, the outcome of the project… all kinds of new information that many clients would like to keep you from passing along.

What is the value of that option to speak about your collaboration with one another? Financially, I mean?

Well, the value to you might be substantial, especially in the current business culture: Assuming you’re a consultant, contractor, advisor, or other nonemployer firm, the relative marketing value of adding this information to your public portfolio of work may be huge, depending on the nature of the client and work. If you had completed contract work without the burden of the NDA, you would have the option to brag about the name of the client, the nature of the work, the details of the tools and cunning solutions you brought to bear, the amount you were paid… all inarguably useful information to trot out the next time you’re speaking with a similar client.

Lacking the ability to share any of that information, as an individual contractor or consultant, you have inarguably limited your ability to market yourself. Who did you work with? Can’t say. What did you do? Can’t say…. And (again, give the current business culture) that marketing value is not diminished even if the project was a total technical failure. So from the side of the consultant, it’s clear the ability to promote one’s own expertise has positive value.

Now suppose you do sign an NDA that restricts your ability to pass along this information for one year. In real options terms, it seems that you’re postponing the exercise of your implicit right to market your business. In exchange for compensation, of course: the payment you receive from the client, and whatever general knowledge and experience might be accrued during the course of the project.

So at this point it seems that the amount you should charge the client just to sign an NDA depends on the expected loss of revenue you will experience from limitations of your ability to market your work. If we pare away the decision to work on the project together, we cannot get looped into ridiculous conundrums like, “Well, if you don’t sign the NDA we aren’t going to have a contract.” The value of the NDA is not the value of the entire contract; the work you do for the client is what causes them to pay you.

The NDA’s value must be separable.

But there’s where I get hung up, somehow, so I keep mulling it over looking for a way to model the transaction that captures the risks and benefits of disclosure and nondisclosure so they can be made more explicit. Maybe because in this combined deal (contract-plus-NDA) there is also a set of complex options being created, sold and exercised by the client, I admit I get tied up.

I’m encouraged, though. Consider that a well-formed contract for work is above all an aid to the planning processes for both participants, in that it reduces the uncertainty regarding possible outcomes. As a contracted worker, you have more assurance of income in the near future; as a contracted client, you have more assurance that the project will proceed, and you have a better handle on the costs.

Still, the value of nondisclosure within one of these contracts feels complicated, though not necessarily from the standpoint of the contractor. What are the sources of value and uncertainty on the client’s side of this planning process?

Surely the client believes that by engaging you and applying your expertise and effort there will be positive business value compared to what they would achieve without your participation. Or perhaps your presence reduces the risk of failure by a detectable amount. In any case, let’s limit the scope of the analysis by assuming there is a clear-cut case in terms of risk and return for them to engage you.

But they clearly also believe—whether or not it’s true—that public disclosure of certain information will put them at a competitive disadvantage. As if you didn’t know it already, this is the assumption I’m most prone to challenge. It’s clearly the reason current practice so often makes nondisclosure a dealbreaker: it’s common knowledge that the revelation of trade secrets is expensive.

Now I confess there is a tendency among those of us who have been entrepreneurs or analysts or modelers or IT professionals or experts of any sort who type and draw on whiteboards a lot to imagine that the sort of trade secrets that a client might want to protect are the same kind of simple innovation that we create almost every day: better software, working analytics, cunning and insightful reports, graphic designs, improvements in institutional structure. Insights, call ‘em.

These “secrets” are the kind of thing we joke about around here by saying (quite accurately), “A good idea is born worth minus $25000.” Because ideas are cheap to formulate, but each one has real costs to implement. Over the course of a decade one inevitably hears the same idea pitched a dozen times in whispered tones as if it were made of gold: a real estate aggregator, a stock prediction system, a social site for book lovers, a killer app on the iPhone….

These are, in my experience, the most common kind of client projects: the sort any moderately smart professor or middle-manager or graduate student stumbles across in the course of their “real work”, sees unbounded upside potential of, and (without exploring the practicalities) pursues optimistically. And thus tends inevitably to overvalue.

In the case of such trivial secrets, let’s assume that the client’s model of the risks from disclosure of their “secret” greatly overestimates the chances or the losses, or both. Your model, or perhaps “the market’s” model, would produce a much lower risk for the client, and therefore a lower price for [non]disclosure.

But as an expert contributing skills to completing the project, the ability to promote the sort of work you are brought in to do is no less valuable to you—independent of its validity as a “secret”. You write, you type, you answer questions, you contribute insights whether they are building a hugely innovative first-mover, or a bog-standard also-ran.

So it strikes me that the problem in these cases lies with the quality of the client’s models of their intellectual property and competitive landscape. They overestimate the recoverable value (or underestimate risks) associated with the project, and as a result the realizable long-term value to them of keeping the secret appears to be greater than the immediate value to you—and to them—of promoting the work.

Because we shouldn’t disregard a qualitatively different model of the contract: Suppose instead of being client and customer you are partners, and you are faced with the decision whether to promote your project or keep it secret together. There is marketing value to both of you, but also risk from competition to both of you upon disclosure. And disclosure is irreversible, don’t forget.

So from a real options perspective if you can postpone the decision to disclose until the benefits of promotion definitely outweigh the risks of competition, you both win. Whether you’re partners, or consultant and client.

Hopefully you can see the same real options structure I do. At some point, if they’re paying attention, the client will eventually improve their model of the real value of their “secret information.” We just don’t know when that will be, externalities and uncertainties of life being what they are.

So suppose you enter into a suite of simple options contracts regarding disclosure in which (a) you cede your right to disclose the information for a fixed length of time (say a year) in exchange for a certain sum of money to offset your lost marketing value; (b) your client is granted an option to renew that contract for another year at its end; and (c) your client is granted an option to abandon the entire nondisclosure structure (including scheduled payments) at any time. They should exercise this option, obviously, when they’re out of the money: when the costs they will be paying in future outweigh the realizable benefits given new information.

What is the price for nondisclosure, here? It can be estimated as the loss of revenue you as contractor will experience from failure to market yourself. If your client receives new information at any time that reduces the perceived value of secrecy to the point it no longer seems to be worth paying you for it, they can abandon the agreement and your right to irreversibly disclose the information reverts to you. If at the end of a contract period they still perceive positive value in secrecy, they may renew (perhaps at a new price).

Now it’s been pointed out to me that there’s more than just this sort of “naive secrecy” I’ve sketched. While it’s common in startups and small businesses, a larger or more capable client probably has better models of the risks and values of disclosure. If nothing else, larger firms are more likely to be aware of real competitive landscapes and best practices, and tend to outsource development as opposed to research projects.

The secrets in these cases are not so much innovations as they are well-defined functional practices and information that’s been tried and tested. In many cases there are smart accounting models of exactly how much they’re worth.

But I don’t see how this negatively affects the calculation of the cost of secrecy. Indeed, it should improve matters and simplify for all involved if the components of the contract regarding secrecy are separate from those regarding work-for-hire. Give the customer the benefit of the doubt here, and assume we’re now at the opposite extreme from “naive secrecy”: now the least accurate predictive model is probably the contractor’s, in that it overestimates the value of marketing (disclosure).

What we do in this situation? I’m not sure.

And uncertainty is the key: that’s what real options pricing is all about. So maybe (after I think about it for a while) we can work the rest of the model out, and maybe slap some probabilities and prices on there.

In general, here’s where I feel like I am: The presence or absence of an NDA clause in a contract should not materially affect the expected cost of the actual work performed, and therefore it can be separated away from the work-for-hire clauses. Further, the matter of disclosure of pre-existing trade secrets (in either direction) is not what I’m thinking about here, and that should be separated as well; I’m talking about novel information material to one particular project, ranging from the existence of the project, to statements of the goals of the project, to descriptions of the particular techniques applied, to news of the eventual outcome.

This information would be of value to the contractor (and arguably the client, but we’ll ignore that) for marketing purposes, who therefore expects a financial advantage when it is disclosed. But the information is also (arguably) of value to competitors of the client, who therefore expects a financial cost should it be disclosed.

There is uncertainty associated with all these valuations, and with the probabilities of the events occurring. How do we model that in such a way as to make it simpler to separate agreements for work from agreements regarding nondisclosure?

It’s simple refactoring, really: The modules have very different functions, and yet they’re too often interconnected.

Notes on a remnant culture, part 1

In the last year I’ve had three, four dozen meetings with the local Chamber of Commerce CEO and staff, with the staff of the local “sole economic development provider”, with commercial real estate folks and developers and lawyers and entrepreneurship organizations and CEOs of local startups and community activists and landlords and marketing consultants and print newspaper editors and local government officials and retired executives and bank presidents. It’s not too rude, I hope, to call them the “traditional business community”. Most would be comfortable with this description.

In case some prejudice seems to be creeping in, I want immediately to clarify something important: these are nice folks as a rule. Admittedly many of them don’t seem to know what to make of “people like us”, and their responses to chats and conversations vary from dismissiveness to a kind of wishful yearning that they could have “my” lifestyle. But on the whole they’re doing what they perceive as their best to improve the world by whatever criteria they feel are most crucial.

But if I wanted a bit more hyperbolic effect, I might call these nice folks the remnant of the traditional business community. They may not feel so good about that, though I don’t mean them harm by imposing the modifier.

I admit though: I have, through these dozens of conversations and interviews, tried to convey that “people like us” often see them as a remnant, when we consider them at all.

Beyond a confirmation of the inherent niceness of people, and their critical diversity of toolkits, what have I learned with this two-year project? I’m making some notes.

Ubiquitous Overextension

As a rule these folks seem to schedule their time poorly. They’re always in a hurry, or late, or interrupting a conversation to take a call. They prefer to hold public meetings and events during the wee hours of the morning, or after work. They dilute even their nominally entertaining outings with one another (typically golf, of all things) with business concerns: “networking” or speeches or award-giving rituals.

I suspect that in part these habits are a mix of signaling and territorial behaviors, part the echoes of constraining sociotechnical infrastructure, and the habituation to the Received Clock.

Signaling is what you might expect, if you know some of “us” and some of the remnant.

“Somebody like me” signals I have the luxury of meeting you for two hours in the middle of the afternoon to discuss the philosophy of business and the next ten years’ forecast for banking and redevelopment in the state. I will meet you right now, if you like, or I can tweet you or phone you or send you an email or open up a Google Docs shared file for you to edit, right now. Because I can, you should be able to as well.

The signal of the remnant’s early morning meeting, the rushed meeting between other meetings, the truncated half-hour refresher or the hurried chat in the parking lot between events is: There is a hierarchy of demands on my time, and they are numerous. My hands are tied; we can go this far and no farther. Depending on the worldview of the person involved in sending this signal, the implication is either (1) a message about how egalitarian they are, that they have two dozen people from all walks of life to deal with, and that each gets their fair share, or (2) that you only rate this much time based on your relative importance in the scheme of things.

Both groups are saying something, in the way they set their time up, about their expectations for the other party. But those expectations are different for “us” and for institutional players.

The sociotechnical constraints seem to stem from these different senses of “institution”, as well.

I know (more or less) where everybody with whom I am concerned is, right now. Twitter, Plurk, Facebook, the phone (and SMS), email and a variety of tagged social media sites that work on a longer timescale keep my network in a kind of dynamic informative tension, like a spiderweb I suppose—though one that overlaps with all my friends’ and colleagues’ own spiderwebs. And when the unexpected comes up, I have these five or seven channels with which to reach somebody, ranging from speaking into the air to make the molecules vibrate in a sensible way, to a phone call to a for: tag on a delicious.com link.

The folks in the remnant, though, they seem blind and deaf somehow. I’ve often wondered if this is an adaptation; I suspect it’s a protective mechanism on a couple of levels. To have to be somewhere to communicate can be a feature or a bug, depending on what you want. To have to see somebody to have a conversation, to fail to record notes and make each meeting revisit old business, to spend so much time physically traveling… these offer up moments for planning, or for self-reflection. They reinforce immediate, physical social cues that are wired into our meat. They can be off-putting to “folks like us”, but if you think about it they can also help establish community boundaries and strengthen internal connections within larger-scale businesses “people like us” don’t interact with.

These cultural differences come up surprisingly often when you’re attuned to them.

I can think of several times I’ve watched “one of us” being told “I’ll have to get back to you once I’ve checked my schedule,” by a member of the remnant. You can see the frustration on both sides: schedules, among us, are made to be changed and adapted to on the spot; they’re agile and flexible and dynamic and our worklives are a matter of tracing an efficient path through the coming days. “Our” success comes from acting as quickly as possible upon the smallest tasks which provide the greatest return. The remnant’s schedules, on the other hand, are planned things, contingent on many stakeholders’ external decisions, written in the slow-flowing glass of institutional infrastructure.

The impatience “one of us” feels when told we’ll hear someday eventually about a scheduled event? That impatience comes from the execution risk that this imposes on our lives: risk that what would otherwise be a linearly separable quantum of social interaction and business value is left as an unknown in our agile schedules, with no clear likelihood of actually occurring at all, disrupting the flow through unaccounted linkages and forcing us to deal with unforeseen repercussions. The confusion one of the remnant feels when asked to make time right now is the disregard for the institution, for the plan, for the process that tries to be “rational” in balancing the utility functions of many stakeholders trying to cooperate on many schedules.

As a consequence, there are deep currents and implications of schedule-setting revolving around the notion of responsibility. “We” are responsible to ourselves, and to our social networks—an often global, contingent and ephemeral cloud of people who are effectively invisible to members of the remnant. The remnant have well-established channels for coordination, and the Company or the other large institutional boundaries make the breadth and bounds of those coordination networks publicly visible.

One correspondent of mine, living as he does at the peak of the local branch of a global remnant organization, often politely tells me how he envies “my flexibility in working whenever I want.” I’ve tried to explain that I work, in the sense of coordinating and driving this jinking spiderweb I ride through life from minute to minute, from the time I open my eyes to the time I fall asleep. But he cannot see that network or the effects I cause in it or I feel from it, and lacking an alternative signal he imagines I am sitting here philosophizing in a life of leisure and guileless meandering dilettantism. And I in turn write him off as a kind of fixed point in town, and expect him to be exactly the same in two weeks, doing exactly the same things as he was yesterday.

And think of planning and project management, across this cultural gap between the remnant and “us”: When I find my occasional correspondent is actually acting, when I discover she has unexpectedly “moved ahead” on a musing project notion we touched on briefly in our meeting three months back, when it comes to light she’s hared off like a juggernaut and done something that seemed like a good idea back then… how often was it the right thing for her to do? Our timescales are so often misaligned, that I can make a dozen iterative changes in a document or program or community design in a weekend, where she has scheduled an appointment with her staff to set up a committee in a few days. A crowd “of us” may have made three versions and discarded them, moved on and established both a position statement and a draft RFP in the time a government or business or church or other remnant institution has coordinated its way into considering what to do.

Just this week a friend in the remnant sent me a link to a “call for contributions” for a meeting to be held several months in the future, which will involve travel and planning and meetings and publishing and setting up bank accounts and LLCs and all kinds of stuff. But in the time between our original conversation and the “call for contributions”… the problem has gone away. It’s solved, at least in my context.

Our different attitudes toward time and action are alternate solutions to the same problems of coordination and planning and risk amelioration in an uncertain world. “We” are no better off for doing five times the work, for hiding or not even knowing who we affect in our ephemeral social networks, than the remnant is for spending all this energy on institutional identity and mid-range planning meetings.

But think for a moment about the remnant—whether you’re a member or not—and consider what happens when a traditional institution says they “need somebody to do social networks for them”, when they explore “modern” methods of customer response management, when they schedule meetings with “us” over golf outings (of all things) or at 7am in the morning, or in a City Hall five miles from “our” workplaces.

When we take the time to do the retrospectives, words like “blindsided” and “unmanageable” and “retrenching” always seem to crop up in internal discussions among the remnant. Terms like “obsolete” and “artificial” and “lame” tend to crop up in whatever appraisals of these remnant projects “we” are willing to record. “Lame” is particularly interesting, if you think about it etymologically: halting, crippled, disabled, slow.

How many times have you seen these clashes in the use and perception of time? In schedules and planning?

Can you see the remnant among the institutions around you? And can you see the ephemeral (nearly invisible) swarming social networks that “we” depend upon instead?

Which is bigger? Which is more important? Which should have the most influence in the coming economic transitions?

How prepared are you, whichever side you live on, for the role the other side must play? What will you do to reconcile these conflicts in habit and perception? How will you schedule your time and make coordinating plans across this cultural divide?

I want you to see a hundred or a thousand of “us” in every town of 100000, with our overlapping social networks and value streams and contingent agile plans thrashing wildly on a minute-by-minute basis on a dozen channels, permeating the infrastructure of the remnant. With little mass individually, but velocity enough to impart considerable momentum. Imagine then the effect on the remnant, these large, many-bodied institutions moving at a lockstep pace, surrounded by these thrashing waves of attention, of goals and actions changing faster than they can perceive them… invisibly in fact.

I see erosion. I see weathering, and seeds growing in cracks in a rock face.

But this doesn’t happen imperceptibly, from the rocky remnant’s point of view. The newspaper can perceive “us”, though it cannot make the connection between individuals and their invisible networks. The Chamber of Commerce can perceive “us” in their declining rolls, and executives there are scrambling to find ways to adapt. No doubt the remnant business development people are starting to falter and wonder what’s broken, though they (and the city) clearly imagine they stand firmly alone in a field. The University, the arts groups, the anchor businesses, the marketing infrastructure: what do they feel?

They are surrounded, invaded, and increasingly driven by things not planned for. Their plans erode and get revised to death, their boundaries and a century’s coordination strategies are made asynchronous and increasingly chaotic.

This is not a threat, but just a natural extension of the metaphor: every chip, every fragment and moment of their unscheduled time and attention, every lost cent of revenue slipping through the cracks in the remnant’s plans, that is a resource one of “us” can pick up, and pass along the networks we have built, that only “we” can see.

Whoever “we” are. I don’t know, myself, past the half-dozen friends I watch and interact with in my immediate social neighborhood. But then I don’t need to know more than that to make my way successfully. None of “us” do.

Watching things come together

You’ve not heard much from me recently because I’ve been busy volunteering and helping Mike Kessler and Matt Lewis set up the Workantile Exchange, a new coworking membership organization in downtown Ann Arbor.

I’ll have more to say on that in a few days. Still some work to do.

Meanwhile:

There will be more, soon. That’s a promise.

Dewey’s “Pattern of Inquiry”: money shot

From John Dewey’s Logic: The Theory of Inquiry, by way of John J. McDermott’s The Philosophy of John Dewey: The Structure of Experience, this summary of Dewey’s own chapter on the nature of inquiry.

In particular, this strikes me as something that bears on many discussions I’ve had about machine learning and modern statistics. And it reminds me of a cultural problem I’ve been wrestling with among genetic programming researchers and operations research people for some time. And would be useful in explaining the pedagogy and practice of engineering “craftsmanship”, and more specifically that of software development.

Oh, and complex systems research and emergence, too. That’s in there, somehow.

So you can see why I might think it’s important to understand.

I can’t quite put my finger on it, but something in here—perhaps obfuscated by what today we might perceive as a difficult style, but which is an attempt to convey very specific concepts in a way that tries to avoid misunderstanding—is vital to many threads in modern life. In particular, something deeply important happens down in the last paragraph, where I’ve highlighted it.

I would love to have a correspondent who could discuss this productively. Perhaps one might be found to read the original Dewey, or even the few surrounding pages extracted in McDermott’s summary, and tell me just what it is I’m responding to?

…Inquiry is the directed or controlled transformation of an indeterminate situation into a determinately unified one. The transition is achieved by means of operations of two kinds which are in functional correspondence with each other. One kind of operations deals with ideational or conceptual subject-matter. This subject-matter stands for possible ways and ends of resolution. It anticipates a solution, and is marked off from fancy because, or, in so far as, it becomes operative in instigation and direction of new observations yielding new factual material. The other kind of operations is made up of activities involving the techniques and organs of observation. Since these operations are existential they modify the prior existential situation, bring into high relief conditions previously obscure, and relegate to the background other aspects that were at the outset conspicuous. The ground and criterion of the execution of this work of emphasis, selection and arrangement is to delimit the problem in such a way that existential material may be provided with which to test the ideas that represent possible modes of solution. Symbols, defining terms and propositions, are necessarily required in order to retain and carry forward both ideational and existential subject-matters in order that they may serve their proper functions in the control of inquiry. Otherwise the problem is taken to be closed and inquiry ceases.

One fundamentally important phase of the transformation of the situation which constitutes inquiry is central in the treatment of judgement and its functions. The transformation is existential and hence temporal. The pre-cognitive unsettled situation can be settled only by modification of its constituents. Experimental operations change existing conditions. Reasoning, as such, can provide means for effecting the change of conditions but by itself cannot effect it. Only execution of existential operations directed by an idea in which ratiocination terminates can bring about the re-ordering of environing conditions required to produce a settled and unified situation. Since this principle also applies to the meanings that are elaborated in science, the experimental production and re-arrangement of physical conditions involved in natural science is further evidence of the unity of the pattern of inquiry. The temporal quality of inquiry means, then, something quite other than that the process of inquiry takes time. It means that the objective subject-matter of inquiry undergoes temporal modification.

Terminological. Were it not that knowledge is related to inquiry as a product to the operations by which it is produced, no distinctions requiring special differentiating designations would exist. Material would merely be a matter of knowledge or of ignorance and error; that would be all that could be said. The content of any given proposition would have the values “true” and “false” as final and exclusive attributes. But if knowledge is related to inquiry as its warrantably assertible product, and if inquiry is progressive and temporal, then the material inquired into reveals distinctive properties which need to be designated by distinctive names. As undergoing inquiry, the material has a different logical import from that which it has as the outcome of inquiry. In its first capacity and status, it will be called by the general name subject-matter. When it is necessary to refer to subject-matter in the context of either observation or ideation, the name content will be used, and, particularly on account of its representative character, content of propositions.

The name objects will be reserved for subject-matter so far as it has been produced and ordered in settled form by means of inquiry; proleptically, objects are the objectives of inquiry. The apparent ambiguity of using “objects” for this purpose (since the word is regularly applied to things that are observed or thought of) is only apparent. For things exist as objects for us only as they have been previously determined as outcomes of inquiries. When used in carrying on new inquiries in new problematic situations, they are known as objects in virtue of prior inquiries which warrant their assertibility. In the new situation, they are means of attaining knowledge of something else. In the strict sense, they are part of the contents of inquiry as the word content was defined above. But retrospectively (that is, as products of prior determination in inquiry) they are objects.

[Latter emphasis is mine.]

If I titled this the way I wanted, it might crash my server

A bit more on rspec and cucumber, since last night wrangling with directory structure in a project we’re doing I finally put my finger right on what was bugging me.

As I think I said, cucumber is for people, an almost-natural-seeming domain-specific language parser that smoothes the conversation between a non-programmer customer and a programmer implementing particular features. Better yet (and safer, in my case) it can help frame the notion of utility, so that a programmer writing code which may be peripheral or unrelated to actual features can discover the actual value to a customer… or get rid of the chaff.

I tend to be wordy, see. Tend to add features glibly, or type in extra methods without being called to do so. So for me, with my own special needs as such an unusual creature as a programmer who doesn’t pay attention (or as a customer who doesn’t notice how many features are being demanded), I think of cucumber and rspec as my affordances. Keep me from falling down as much as I am wont to do.

Cucumber provides an elegant interface between those two modes of thinking: between the linguistic description of a feature and the technical definition of the corresponding behavior. Not just by exercising all the cool and elegant code in its arsenal, but also in modifying the typical practice of conversation between a programmer and a customer: because it demands a degree of linguistic precision that is lacking in many conversations between these worlds. You “get” to use “plain language” to describe your features. But success requires thoughtful wording.

For example, this is the cucumber code I’m using to manage a feature in an image-processing system I’m playing with. I use it to capture the over-arching “meaning” of this particular feature, and also to state clearly when I’ll accept this code as being “done”:

Feature: Process an image in memory
  In order to collect training data
  As a statistical artist
  I want to reduce example files to database entries

  Scenario Outline: base-level block scanning
    Given an image in memory with <height> x <width> pixels
    And a maximum block depth of <maxDepth>
    When I ask for all blocks
    Then I should a list of all the <total> blocks I expect

  Scenarios: low-level blocks
    | height | width | maxDepth | total |
    | 1      | 1     | 1        | 1     |
    | 10     | 4     | 2        | 67    | # 40+27
    | 8      | 9     | 4        | 200   | # 72+56+42+30
    | 1      | 10    | 3        | 10    | # 10 (can't make higher depth than 1x1)

These four scenarios I’ve described are exercising a bunch of edge cases and standard behavior, and when they’re implemented in functional code they will imply all sorts of unmentioned things about exception testing and error checking and all kinds of libraries, and in that code I’ll have to pass all kinds of messages here and there. And note also that they don’t specify what a lot of the words mean, nor specify the names of functions (there’s no explicit mention of the method Scanner#allBlocks, for instance).

They may look like a flat text file, but in fact they’re very formal bases of very particular chunks of executable code. They say what I want, and when the cucumber story-runner turns them all green, I’ll feel this feature has been finished.

And elsewhere in my project code, in other files for “me, the programmer”, there are definitions that map these formal lines into runnable code:

Given /^an image in memory with (\d+) x (\d+) pixels$/ do |height, width|
  ... [code that sets up the infrastructure for the acceptance test]
end
Given /^a maximum block depth of (\d+)$/ do |maxDepth|
  ... [code that sets up the infrastructure for the acceptance test]
end
When /^I ask for all blocks$/ do
  ... [code that creates the test output]
end
Then /^I should a list of all the (\d+) blocks I expect$/ do |total|
  ... [code that compares the test output to the expected result]
end

With all these plain-text strings floating around, it may seem as if that's a bunch of wobbly, ill-defined vagueness in action. But it turns that the use of very specific framing of detailed and focused concepts is critical for making the jump from notions to code, or (if by some chance you're doing things ass-backwards) to take already written code and capture the pure function that it implements. It focuses attention on the boundaries between "system under [integration] test" and the rest of the typing you're doing.

Indeed, now I think about it, a lot of the negative comments I've heard from programmers who don't like the style of rspec or cucumber (or test-driven development, for that matter) story-writing focuses on how wishy-washy "plain words" are. But when you push them, it turns out the problem really is about the painful rigor one feels, when forced to map what somebody actually wants to what one is actually typing.

Being meaningful is hard work.

Now the code I show above, that's from cucumber files, and cucumber is for functional, integration, acceptance testing. That junction between what somebody actually wants, and what is actually done. Down inside the development process itself, where those little chunks of function are transformed into classes and methods and calls and results, is where rspec comes into play for me, as a unit testing framework. And what I was saying the other day, about the difference (which some consider spurious) between traditional assertion-based unit testing and specification-based unit testing? That's a matter of semantics. (As evidenced by, for example, shoulda, the unit testing extension for Rails that lets you frame your standard unit tests in spec-like language).

See, for me the preference of specification-driven as opposed to assertion-driven unit testing is not really about being wordy, and wanting to always use a paragraph when a line of elegant one-character APL code will do. Though I am. Wordy.

No, it's really about more comfortably capturing the little intuitions one gets, when building some complex object. Because when I'm programming I constantly feel, or I hear, or I know, "This should be over there. This shouldn't happen this way. This should never come up again." And whether I frame my actions as unit tests or as specifications, creating new ones should be simple and communicative, so I know when I'm done, and so I can pose and solve each little concern as quickly and with as much focused attention as possible.

How one states these little problems is, at its essence, how I (as an amateur) see the difference between behavior-driven and test-driven work: that behavior-driven work more clearly surfaces teleology.

For example, here's an extract of rspec code from that same project, where I am implementing code that will (eventually) get those cucumber feature description steps to work:

module Scanning
  describe TrainingImage do
    describe "when initializing" do
      it "should contain a new image with the given width and height" do
        newImage = TrainingImage.new(10,10)
        newImage.width.should == 10
      end

      it "shouldn't complain when given no parameters" do
        lambda {TrainingImage.new}.should_not raise_error(ArgumentError)
      end

      it "should have a default backgroundColor of white" do
        newImage = TrainingImage.new
        newImage.bgColor.should == '#FFFFFF'
      end
    end
  ... [lots more]

Each one of those "should" phrases is a little increment of work I consciously set up---or that I discovered along the way---as I worked on this complex object.

As you can see, this rspec code is more... code-y. But it still has those framing statements of purpose staring you in the eye, the describe and it "should..." blocks. And when you run the specs, you get a list of passing and failing and pending phrases, not function names or some other kind of code that would be another step removed from explicit description.

And, yes, somewhere else in the project hierarchy---frankly it's pretty much buried---is the actual code that makes it work. It's a little, tiny fraction of the bytes in a project. But that's OK. Because (if I do my jobs well enough), every distilled character of that code is simpler, easier to understand, tested, described, and tied directly to the functionality I actually need to produce business value.

Now I mentioned above, last night I finally put my finger on what it was that was bothering---paining---me the other day about both cucumber and rspec, about my experiences in using them, and about introducing these techniques to other people. And it's these intrusions:

require File.join(File.dirname(__FILE__), "/../spec_helper")

and

$: << File.join(File.dirname(__FILE__), "/../lib")

Ouch. No. Please make it stop.

These little nuggets of dense, inscrutable Ruby are the links between the many files in a standard cucumber- or rspec-driven project directory. They crop up at the top of files now and then (and often with no apparent cause in the manuals and tutorials past "this has to be here for it to work"). Some files need them, some files don't. To understand which files need these lines at the top, and where the links need to point, and what the links have to specify and the syntax to use... you need to understand what the cucumber and rspec libraries are actually doing.

You need to figure out what it is the algorithms want.

Now, it you're familiar with Rails programming, you'll recognize the pattern because it also appears in most Rails projects, what with the deep many-branched magical directory structure in that framework. And there, as here, they are a frickin' pain in the butt.

Why am I railing against such a little inconvenience of some nasty perlish Ruby code? Well, think about it: In the midst of these two rather elegant domain-specific systems (and for that matter in the midst of magickal mystical Rails, of all places), where it almost seems like natural language parsing is happening right there before your eyes, and which exist only to surface the link between desire and implementation as comfortably as possible, you have to say some shit like "$: <<"? This is not peanut butter on my chocolate bar, this cuts the eye.

OK, so work with me, here. One has already created a suite of pleasant, linguistically-smooth function names like Given and When and should_not and should have. And the mystical libraries that interpret them are stuffed down inside some gems so real people need never bother themselves with the ugly stuff they actually do. Yay!

But before you can use those elegant libraries, you need to say these magic phrases? This is what, some kind of reminder of our mortality, some kind of intentional flaw in the symmetry of a beautiful Persian rug?

Bah. As an amateur programmer myself, who has gone out on a limb so far as to insist my beloved wife pair program with me as I learn to use these frameworks better and remind myself of Ruby code after many months in Python land... let me tell you that the last frickin' thing I want is for the first line of the code that makes the wonderul thing I'm touting actually run to be something I have to look up every character in the manual to understand, and I still can't figure out which files have to have it and why.

Now, maybe I don't understand enough about the structure of these libraries. I'm not sure it's possible to use the same kind of parsing language they already use---you know, the ones they already have baked-in to take clauses of text and transform them into object instances? Whether maybe those could be brought to bear to create functions like Collect all_specifications.from "/../lib", or maybe FirstLoad "spec_helper.rb"?

I'm not really a very good programmer, as it happens, and I suspect doing anything to write these myself is way past my abilities. But I have this weird feeling it's feasible to add these little affordances for stupid people like me. And that maybe, since they crop up all over in big multi-file projects, they might actually be useful.

@cucumber should_behave like “I want”

When I first heard about test-driven development, it not only made perfect sense, I realized it was something I had been trying to implement (without the benefit of dynamic automated tests) by had in weird-ass languages like Prograph and R. Hearing about it just made sense, though it took me some time to climb on board the languages in which it was (back then) simplest to implement.

But I never got over the ass-backwardsness of assertion-driven TDD’s workflow: the sense that every unit test is a little magic trick. “Observe, as I create this NewObject. [applause] Nothing inside, nothing outside! I assert that NewObject.inside is aValue. No? It is not? [amused laughter] But where is aValue? Ah… but watch, watch carefully as I type, and… voila! My assertion is now correct!”

Close. I understand, I understood, I had been trying to do something like that in many ways, back long long ago.

But not quite. Especially, I’ve found, for the accumulation of unwritten tests. Yes, as you move forward with traditional test-driven development you will think of other things you should do. It should check for errors. It should fail gracefully when it can’t connect to the pipe. It should be an integer, not a float. &c &c

A while back (more than a year?), I installed and worked for a while with rspec and cucumber. I had been lured to Ruby years back by Ron and Chet, but never really got too far along my path that way. This was… different.

And then, a big bunch of Python. That’s slowed down, and now with Barbara I’m coming back to Ruby (and Rails, but not so much as Merb). And BDD is there, ready for me, and greatly improved.

No, really: rspec is exactly how the smallest increment of automated test-driven unit testing should work. Cucumber is [almost] exactly the way the smallest, simplest increment of automated acceptance test-driven project management should work.

The problem? The rituals of file linking. You have a specs file; you have a features file; you have a steps file; you have your actual code; you have your helper files…. Somewhere in that mess, you have a mesh of spaghetti, all sorts of stuff referring to other stuff. And that’s confusing. A little, teeny bit disappointing, even.

Don’t get me wrong: the latest rspec/cucumber release is the next resonant “yes” in a chain of substantial improvements in the way code can be written. Because with rspec you can gracefully and communicatively catch those incidentals: “it ’should check for errors’… it ’should fail gracefully’” You can say that in rspec’s cunning framework; you can let the customer say what it is they want, with Cucumber.

Brief pause

(even in the linking)

I’m in the middle of Ron Jeffries’s and Chet Hendrickson’s CSM training class.

Worth the effort, if you’re wondering.

When isn’t it a nice day to be nice?

Seems to me, if you

  1. had a roll of dimes and
  2. a spare half-hour when you were walking to and from lunch, or coffee, or a bar, or a meeting
  3. in downtown Ann Arbor,

…you might be a nice person if you dropped a dime into an expiring parking meter.

Especially if you were to see the parking enforcement person walking along with their little ticket thing.

Hey, I checked our records. You didn’t say you wanted a revolution after all. Sorry!

Clay Shirky wrote the other day, in what might be the most-linked item in my voluminous and wide-ranging delicious stream:

When reality is labeled unthinkable, it creates a kind of sickness in an industry. Leadership becomes faith-based, while employees who have the temerity to suggest that what seems to be happening is in fact happening are herded into Innovation Departments, where they can be ignored en masse. This shunting aside of the realists in favor of the fabulists has different effects on different industries at different times. One of the effects on the newspapers is that many of their most passionate defenders are unable, even now, to plan for a world in which the industry they knew is visibly going away.

As I’ve come to expect when reading Shirky: yes, that’s what I’ve been trying to tell people for years. [You know, if that Cassandra chick had been a smarter cookie, maybe set up with some agents or a PR firm or something, I bet she coulda made a fucking Fortuna. [Ba-dump-bump]]


As part of the “guerilla economic development” work I do at our company Vague Innovation, LLC, I spend a lot of time meeting with the nominal movers and shakers of the local business development community: folks from the Ann Arbor Chamber of Commerce, the Ann Arbor SPARK, marketers and Realtors and landlords and bankers and people who publish shiny color magazines have sunny offices in tall buildings.

I hate to stand alone against the stream of bigoted invective I hear from most of my New Economy peers, but people who wear suits and work in offices are good folks. They’re trying their best to help their town and region, their towns’ economies, to identify and shore up the entrepreneurs they recognize as the future of their local worlds.

They’re good people.

That said, a lot of my conversations revolve around the future of these nice folks’ careers. Like all of us, these are plain old human beings armed with the standard human cognitive heuristic toolkit. You know, the same one you have: some stupid mapping of your personal experience onto the whole world, the 5 ± 2 most memorable cultural norms they can bring to memory unconsciously, and the sense of massive importance of all that Received Wisdom they’ve been exposed to in their canalized plummet through life. Just like yours, you know?

As part of my work I keep a foot in both worlds (and a couple of others, too; you don’t want to know how that feels). And so:

I could go on. Hell, I did already. But I felt bad.

I deleted them all because they got more egregious and far more embarrassing for the “traditional business” folks as I totted them up. A list of searchable terms (and teachable moments) might do: “coworking”, “commercial insurance”, “business plan”, “admission price”, “intellectual property”, “next Google”, “corporate blog”, “personal brand”, “online marketing”, “open source”, “boot camp”.

Every one of those represents a little checkbox on the octagonal paper titled “Decommissioning Schedule of Battlestar BizDev.” A defaced gravestone in an overgrown family plot on a dirt road somewhere in ten years. A milestone on the road to obsolescence.

[And someday, when whatever is next comes along, the nanobio revolution or whatever, that will make people like you, you old fart, into stupid conservatives who still type into inorganic computers using some kind of "formal language". And you'll say you learned business sense the hard way on Facebook and with Google, and you'll say you've looked at the Senso but you can't figure out why people want to smell crap on other planets all day. And then you can look this blog post up "by Googling" on your stupid octagonal DVD of the "blogosphere" and be reminded: this has all happened before.]

These are good people. They try, really. But they’re crippled by insularity, by the people they hear and choose to listen to, by their distance from the Actual World. Hell, it’s a handful of them that even know the world exists as it does. No sense of the timescale “we” use, or of “our” means of action. A lot of these folks have heard about blogs and Facebook and Twitter now they’ve been in Forbes and NPR and stuff, but they don’t possess the cultural infrastructure with which they can parse what they’re seeing as relevant communication.

At least three people in very nice suits have made in my presence the joke about “Twitter is about what you ate for dinner” in the last month. So there you go. It’s no surprise that these people still aren’t welcome in the “tech community”. Which is sad.

And to be pragmatic about it all, and think about how cities and communities actually work in this capital-driven world we inhabit, kindof stupid: They have all the fucking money.

Ah, well. Cultural diversity gets short shrift these days. On both sides of that particular line: geeks and suits don’t get each other, though they often assume they do. [And Cf. "don't get me started on the other ones."]

Which, by a long and ranting road, brings us to our milestone parking spot for the day: Parking Data.


This won’t take nearly as long as the preamble.

We have a bunch of parking structures here in Ann Arbor. The Downtown Development Authority contracts with a commercial firm called Republic Parking to manage them, and parking is a huge source of income. The DDA also gets taxes from new buildings, as I understand it, and manages liquor licenses and oversees new developments and stuff. There’s more involved: it’s complicated and political.

[As a symptom of my own increasing frustration with culture clash here: If you're a geek? And you self-identify as an Interwebz-using computery person? And you're thinking or saying that politics or business practice is "unnecessarily complicated" or "opaque" or "useless"? That sounds to me like you're one of those assholes who say they "don't get math" as an excuse for not paying attention to it. Business practice and the law and local government infrastructure are complicated because they deal with real-world public-good complexity, dumb-ass. I don't care if you run some kind of "alternative community" or you're Lord High King Open-source Maven or a Libertarian Fundamentalist or whatever: don't dismiss "politics" or marketing or these other people's culture as trivial just because you're not familiar with it. It really undermines the argument you're "smart" whenever you do that in public. And when you do it in "private", thinking somebody like me isn't there as well, it makes me treat you like the child you are.

Or, shorter: Don't diss "the Man", monkey-boy. We're all man.]

If you’re tired by now, here’s a timeline of what happened.

Some time back, the DDA started putting counters on the parking structures, and around that time they started publishing online feeds that updated as the numbers of cars parked in the structures changed.

This was cool and geeky. We want a cool and geeky town, and this was a good step. +2 points for transparency, and for actually experimenting.

Then some folks I know, including these guys and Ed Vielmetti, did what good modern Internet culture people do: they created a handy open source software package that took the public data and repurposed it into a free way to use your phone to call a number and find out how many spots are available.

This was cool and geeky. We want a cool and geeky town, and this was a good step. +5 points for mashups, repurposing public domain data, open source, and some others.

Then the geek points added up to the point that the Ann Arbor News wrote a cover story about the mashup.

This was cool and geeky. We want a cool and geeky town, and this was an unusual good step from a typically clueless newspaper (Cf. “fish-wrap”, above). +2 points for cultural crossover to the MSM, and promoting the local geek culture to a mainstream audience.

Cue fan. Cue shit.

Apparently this is where the DDA first heard of the cool, geeky thing that had happened as a consequence of their publication of the data. As far as I can tell, they reacted just like anybody in the 1970s would have done: they noticed belatedly that their cultural role as gatekeeper was being undermined, and so they shut down the phone service access to the numbers.

This was neither cool, nor geeky. Burn –10 points for reinforcing stereotypes on both sides of that goddamned line I mention above, and throw in an extra –10 points for the ongoing online shitstorm of bad publicity and even newspaper publicity this is building into.

And here we are, today.

We’ve got people who are core members of the geek community up in arms about it. Folks are stepping around the stupid and ineffectual blockade the DDA started off with. They’re writing open letters that smack of outright political threat. They’re bringing in the big guns from outside town. They’re submitting FOIA requests for the numbers.

It was a simple little thing. A triviality, really. Susan Pollay’s email clearly misses the fact that this was an experiment, the very sort of thing that the phrase economic development means today in this agalmic open-source world.

But it brings the two cultures together in what are probably the worst possible circumstances: The old-skool scarcity-driven infrastructure probably didn’t know these people even existed. Or if they did, they had wildly inappropriate expectations about demographics and values and potential impact on the status quo. And the scarcity-avoiding geek culture that didn’t until until now give a damn about what “suits” did is now suddenly swinging the full measure of its attention to bear on this affront, and they’re processing it on fucking Internet timescales, without old-skool handicaps like “business hours” or “weekends” or “face to face meetings”.

To any of us who are watching with one foot on either side of this line, this is quickly turning into what you might call “spectacle”. No joke: hairs standing up on my arms as this little fooferaw started to come into focus. This (to paraphrase what the cool kids say) is what we call the fire we brought you long ago.

I wrote an email to a colleague from the Chamber of Commerce Friday, as soon as this dynamic became obvious to me. A heads up, mainly, since he’s not directly involved.

For a few weeks now (non-Internet time, remember?) he and I have been talking about what the Chamber and the old-skool infrastructure might able to offer “the 1099 community” or the “independents” or the “Not An Employee crowd” in the coming months. Admittedly we’ve spent a vast proportion of our meetings trying to reconcile our dramatically different assumptions about work and community, and last week we were just getting to a place where we could say stuff that didn’t make the other one smirk or look confused.

[Though he made that confused face when I mentioned glibly the bit about tearing down the hideous mid-century bank building at the center of town and getting a Town Square back. I'll win that bet, too, by the way.]

He’s framing what he sees as the future role for the Chamber in the coming decades in terms like expansion and cultural adaptation so that it can cope with the different lifestyles “we” NAE folks represent. He’s trying to help, and to make what has traditionally been perceived as a useful and necessary business support infrastructure available to more people who need help. Maybe he doesn’t see 100% that they don’t need that help, but he’s trying. He wants to help out and reach over the line for the sake of the city, the region… and to some extent to drag his organization into the 20th century [sic].

In our conversations I find that I’m framing what I see as the future role of the Chamber using concepts I’ve mentioned here already: as a safe decommissioning, as an opportunity for outreach between cultures that are fundamentally irreconcilable, as a model of what to do and what not to do in a nonoverlapping organization… and frankly because I like people and also money, and there must be some way of ameliorating the damage this whole thing will cause in the next decade (Cf. bank tear-down).

But I look at that list of benefits, and I realize that neither I, nor any of the people I know, want any of those “benefits”. But just like my friend in the Chamber, I also want to help the city… so it doesn’t end up abandoned when us New Economy people just leave in disgust. And the region… because I want there to be trains and convention centers and some non-provincial buildings built, and fuck “human scale” I want to see the bleeding edge of posthuman scale. And to some extent to drag out the useful salvage from the wreck of his organization and set it up and dust it off and introduce it to the 21st century [sic].

And in that email I sent last week, in which I explained briefly what I’ve said here in this rambling blog post, I pointed out that this little parking fiasco has something to do with the balance he perceived between our different views of the local landscape.

I said to my friend two things, and I hope I’ve set this up so they might make sense when I repeat them here in public:

(1) That it will probably seem from “his side”, among the suits and hallways in which people come and go according to agenda and business hours and rely on telephone conversations, that nothing much has happened. Some extra phone calls to the DDA maybe, some annoyance felt as this pissant internet crowd throw their weight around and complain about something this trivial. That in the long term this tempest in a molehill will look like it blew over and disappeared, and then “his” folks can get back to business as usual. Or maybe that things will get smoothed over, and the data will be free and things will get all geeky and fun again and all the frowns will turn upside down.

…but also, independent of how it plays out on his side: (2) When we look back years later, this will be the week we say the ground shifted. Or if we don’t identify this exact “triviality” as the turning point, then it’ll be one of the seventeen cued up and waiting in the wings.

Last week it was a decent and smart thing, an appropriate use of his time, for my friend to be paying attention to his goal of “outreach to the independent tech community”. It was good that he was musing about how the two cultures might mutually adapt to fit together for one another’s benefit.

Today, though, a switch is thrown: it’s now possible—no, it’s now the most likely outcome—that folks from the Chamber of Commerce will be watching in a year, or two, or five as all the businesses rush to join something else. Some other organization, not the “answer” to them because it won’t be set up in response to the Chamber or the SPARK or the DDA. Something new that just doesn’t give a damn about any of that old junk, or even recognize its existence.

An orthogonal institution.

Because of this fiasco about the parking, or maybe because of any one of the seventeen other accidental clashes that could function just like this, whatever rises up will not look at all like a partnership founded on principles of outreach and mutual support.

It won’t be founded on anywhere near the kind of cooperation it might have been.

The New Thing is not fully formed yet. It shambles on towards its Bethlehem, independent of what’s happening under its feet. But its eyes are open briefly, and today it’s paying attention to the friendly, helpful people in the suits who only want to help. And I suspect what’s moving though its collective mind are appraisals, a kind of sizing up that should make the friendly business development old-skool institutions pause. A look that increasingly feels like a brief consideration for salvage, of food value. Not a spirit of friendly symbiosis, but a glance that takes in all the hinges, all the convenient places for a pry bar to lodge.

I suspect these things happen too fast to respond to, when you insist on keeping your eyes to the path you started on, when you listen to the cues you’ve learned long ago.

And to be frank, maybe that’s best for everybody.

Mutual Business Coaching?

I find myself disenchanted with what you might call “traditional” business culture lately. Now you, a savvy Interwebz reader, may be the sort of person who lives on a Coast near a Valley or in a town with a Needle, the kind of town with lots of people and loads of young up-and-coming goateed creatives and stuff. Living as I do in the middle of flyover country, I’m not sure “traditional business” means for you what it does here: lots of golf, inordinate striding, breakfast networking meetings, calling important people by their first names, and—the kicker, for me—a tendency to assume that people who made money in the last business cycle, or the one before that, or one a Long Long Time Ago, that those people are rich now because they are good businessmen.

This is the kind of self-reinforcing unexamined mythology that leads young entrepreneurs to their doom. You get an economic development infrastructure in place, you get boards and angel and VC investors all used to what they’re used to and standing by the claim that “business is always essentially the same no matter what the domain.” They set up boot camps and training seminars and they arrange these networking lunches and earnest young people in black suits or khakis show up and eat slices of pizza (at Tech Startup Events) or hors d’oeuvres (at Future Of Our Region Events), and they listen to that crap.

When I invest in a company, it’s the team I’m looking at. And by that I mean: I want to see somebody who reminds me of me when I was a kid.

When I hear an pitch, I need to understand it in the time the elevator door takes to open. And by that I mean: (a) we live in a town with stringent “human-scale” building height restrictions, so (b) you can tell we’re pretty fucking provincial so use only a few small words I’ve known since I was on the football team.

When you’re getting ready to launch, you need to get your business plan ready and make a convincing case for your market and your prospects over the next five years. And by that I mean: nobody ever reads the damned things, but at least we know we can tell you what to do and expect you to listen to your betters, sonny boy.

When you’re trying to raise serious money, you need somebody in charge of the firm who’s familiar with the language of business, of marketing, and the culture of startups. And by that I mean: When somebody paying more attention than me tells me you have a clue, I’ll stiff you with some tried-and-true club buddy of mine and you’ll fucking do what he says if you know what’s good for you.

And so forth.

Of course, I know you don’t live in this imaginary town I do. These are all straw man exaggerations. I’m just resorting to hyperbole to stage my own pitch. Right?

You betcha.

That said, and strawmen aside: I think smart people are actually smart, and that dumb people mess up new businesses.

There’s a sign on the administration view of every website I’ve run for ten years. It’s on my laptop’s desktop, too. It’s a reminder to me, as a manager and a meddler and a planner and a guy who’s trying to help and at the same time make a buck. Every one of these reminders says the same thing: This doesn’t work the way you think it does.

The biggest danger, in my mind, to a person starting a business—whether it’s some hare-brained entrepreneurial thing, or a nonprofit, or a “lifestyle” business (a term I despise)—is taking advice from people who assume they succeeded because of what they did.

The core of my advice to folks wanting to found a business is simple enough to pass along here: listen to “coaches” and “bootcamps” and economic development people only enough to convince them you respect them, and to learn what they expect so you can use that to your advantage, but don’t let them fuck with your money or ideas.

Notice I didn’t say stay away from them: I said be nice, try to really listen, do your best to learn, and along the way do the minimum amount necessary to ingratiate yourselves to them. If you can’t do those things, you actually do need a “people person” around, because it’s all about risk amelioration, not financial returns. Because you’re doing this to minimize the disruptive influence of their received wisdom.

Here’s why: These people succeeded by chance. Quirks of fate. They happened to sell off their companies or execute some other exit strategy just before some random economic downturn. They had rich relatives. They happened to be in the room when some dude wanted to invest in a startup. They had a smart administrator who kept them out of the research wing. They were middle managers in some global giant fucking firm and (more’s a pity) never heard a real human idea in their lives, and now they think they can tell you how to run your business. They go to meetings with their own clones and nod and shout Hallelujah whenever somebody utters a mantra about “invest in the team” or “business savvy” or “demographic targeting”. They not only imagine, they will say outright that every business is essentially the same, and that what matters is making the right mystical passes in the right order and also running it by your guts.

Bullshit. These people are human beings.

That said, they’re the small fraction of human beings who have the goddamned money. It’s not your customers who are going to make your new idea into a company, Startup Grrrl: it’s those fools with all the money.

Let me be as precise as I can be: human beings are stupid. You are too, by the way. But they are moreso, because they’ve had success after navigating an uncertain course through the ratmaze to their perceived cheesy Winning State. And when that happens, our intrinsic human mental wiring kicks in and all of a sudden they’re doing pattern-recognition on scant data. They’re superstitious. They are poor at modeling. They suck at generalizing, and for the most part their culture is founded on principles of reinforcing their notions.

[Like yours is, and mine is... but leave that for another day.]

Risk, reward, reinforcement. So strong, they don’t even have to repeat it to get it engrained; they just play off one another.

This doesn’t work the way they think it does.

Here’s what I think, instead.

Save your money, if you can, and don’t burn it at the altar of the priests in black turtlenecks and sports coats. Hang out with the ones you can, as stated above, but don’t waste money. Don’t risk your money or your time on them.

Instead, find five other startups. Seriously.

Form a Guild. Form an association that lets you each do what you want, spread the work around, support one another. Form a community of 30 people, not three, that can demand the attention (when needed) of one rare but actually useful business advisor at a time, and aggregate your risks across all your firms, and kick the bastards out when you’re done with them.

Coach each other.

I believe smart people, people with ideas like you have, are actually smart. And I think people with new ideas are more likely to understand the one true thing I plaster all over my own sensorium: This doesn’t work the way you think it does. This doesn’t work the way they tell you it does. This doesn’t work by formula, by superstition, by the novel application of pat anecdotal hand-waving or ritualized networking or in-group marketing to people who can’t bother to learn the difference between a social network and a website before telling you how to run your company.

There is no heuristic.

What you need is advice on how to fill out forms. Names of people who give out money, and what they expect. Examples, hard and factual, of business plans that have actually been followed. Access to people who are running businesses like yours, and right now.

What you don’t need is pabulum. You don’t need obfuscation, a gatekeeper who will let you get access to the people they convince you will help, or who wants to dabble and sees your idea as a good starting point. You don’t need people who are a bad match for your culture; any asshole who tries to change that culture you have now, no matter how much a n00b you think you are, without first convincing you beforehand that there are measurable returns and you can undo the changes if things go wrong? They gonna fuck you up.

Hell, you don’t need anybody at all whose advice doesn’t come with a warranty and a money-back fuck-off clause that kicks in when they give you bad advice backed by misleading credentials.

In other words: Sure, you need expertise you don’t have, but treat your “advisors” the same way you would treat your accountant: protect yourself from stupid people.

Any human being is as good as another, when it comes to common sense. Unless they’ve presumed they are winners because they did something a long time ago, under completely different circumstances.

When that’s the case, they’re a liability.

Further: If you want a good example of how economic development professionals can undermine perfectly functional ideas and business models by just not knowing what the words mean, have a look at this.

The Arena, September 1897

The Arena, Volume XVIII, No. 94. September 1897. This is a preliminary PDF version; it has not been proofread or cleaned up, and is presented in a low-resolution screen format only. Someday soon the whole thing (a whole volume) will be forthcoming. Meanwhile:

arena0001.png

Go join Distributed Proofreaders if you want to see more of this sort of thing whenever you want.

Older entries »