4 months Ago

Riding the wave

Published by marco on in Finance & Economy

When we talk about getting real about the Internet economy, we talk about acknowledging that there is real value there. And when we talk about valuation, we think we are talking about some measure of that—real value. The word “value” is built right into the word, so that must be what it means, right?

But what do we mean when we say “real value”? What kind of value or values? And, more importantly, value to whom? Is there only positive value? Or is there a negative component? Which part is larger? Is one part felt more by one group than another? Is that, perhaps, what makes an idea seem attractive? That the positive value lands squarely on proponents while the overwhelmingly negative value lands on others and is, optimally, not even felt or visible to the proponents? Nary a ripple of effect arrives to disturb the blissful, warm feeling of self-satisfaction for having blessed the world with a wonderful idea that has, as a purely fortuitous and utterly unforeseen or even looked-for side-effect, made those proponents fantastically rich.

But let us talk of ripples, and waves, in a bit.

Is it lasting value that provides jobs, income, stability, happiness? Or is it some form of value that can be *converted* to real value? There are strong arguments for thinking that the second case applies in many cases.

These are bubbles. Bubbles ride a wave of hype. There are those who are part of the wave and those who are the surfers on that wave. Some of the surfers will crash into the wave and be subsumed by it. Others will ride in to the beach and walk away dry. These are they who have converted the intangible, ephemeral, hyped value into real currency that can be used in the real world.

Many, many people lost money on Groupon, for example, while a very few made a lot of money on it. For those that made money, this form of investment is a fantastic idea – mostly because the rate of return on actual work done is so high. And what kind of work was done? What was created of lasting significance? People are able to participate even more energetically in an economy that isn’t really working for them—they are able to save money on purchasing things that they don’t need.

My suspicions are that these valuations come from the surfers. They have an overarching interest in convincing us all to be part of the wave. Without a lot of deep knowledge, there is no way for the average person to know which waves are real and which are not. The majority are not real and will not be of benefit to anyone but the surfers. Our system requires that we try them all, sorting through a haystack of bad ideas to find the needle that will drag our miserable heap of humanity a little bit forward.

But we mostly don’t even know in which direction “forward” is. There are multiple levels of con game going on here. We think we know what is of value, we think we choose the right waves, but we are brainwashed into working against our own best interests. We end up being happy with our choices—and continuing to make them—but we are, in effect, not really benefiting at all. We help to further anchor a system that suppresses us all. We make it ever easier for the surfers who stayed on their boards the first time to stay on their boards the next time. We turn them into Gods, perhaps as a defense mechanism. If someone is doing so much better than you, is it not easier for your ego and conscience to think that they are doing something much better? That they are much smarter than you? That is one way to go. The other, which we employ less and less, is to excoriate the surfers for the parasitic criminals that they likely are.

When we say that something is a good idea or a bad idea, we evaluate it against a patchwork of often-vague ideas and moral convictions about how the world works. Often, the choice seems quite straightforward and easy for almost everyone to understand. For example, if you propose to handle two problems in the world by converting poor people (let’s just start with the $2/day level used by the World Bank) into food and energy for the remaining population, then most of the world is going to tell you that this is a bad idea. There are some who will tell you that you would need a pretty sexy website and dead-simple mobile app for that service in order to get past the second round of VC funding but, on the whole, your idea will be rejected. Apologies to Thomas Swift for stealing his satire.

If you, however, propose something less overtly evil, something that is still materially useless but much more aligned with the current economy/society like making it easier for people to get cars when they need them, then this idea is greeted as an overwhelmingly good idea by the majority.

Now, let’s dissect that sentence a bit. Who is the majority? Why, the majority of the people I know, right? Or are you less solipsistic, more noble? Then you’d say the majority opinion is that which one reads in the major literature, the major news sources. But which agenda are they promulgating? These sources will, of course, greet this idea with open arms because they are in exactly the class that will benefit from it. They probably have disposable income that they can invest in the idea in order to try to become expert surfers (see above). Or, at the very least, they will be able to use their phones to get cars to pick them up wherever and whenever they need them. And it will be more convenient, with a minimum of interaction with other people (especially people outside of/below their actual or perceived class).

But something like Uber is an idea that will only benefit that class. Because we have what we consider to be ethics, many of us will need the idea to do a song and dance, convincing us that the idea is good for *everyone*, not just ourselves and our friends. There are others who have transcended this requirement. They are riding waves everywhere.

The people that are actually driving will likely not benefit in any meaningful way. Instead, there will be anecdotes of drivers who make it big—similar to the bauble dangled in front of the poor and undereducated by the State in the form of the lottery—but most will just be struggling to make ends meet in a different, but still futureless job than they’d been doing the year before.

This is only one part of the human/social impact. What about the environmental impact? Is it an overall good to promote ideas that cause people to drive more? To perhaps purchase more cars in order to benefit from this ad-hoc spike of an economy engendered by the massive influx of speculative capital in Uber? Do we even care? We do not. Because we are clawing desperately at our own boards, trying to get up there, to climb to our knees and, hopefully, to stand, at first on wobbling knees like a foal newly squirted from its mare’s womb until, with practice, we stand confidently, hanging ten with the other captains of industry. That is the dream.

It’s hard to imagine why, when the current taxi industry treats its actual workers so poorly—long hours, low pay—we would imagine that a company that is on the Internet will magically be infused with more generosity to its workers, opening its arms to the common man, offering to share its limitless bounty with him. These are just the latest incarnation of schemes with which to build waves, to allow those magical captains of our industry to arrive once more dry on the beach. To walk away Gods, adored by the burbling dregs receding rapidly from the shore.

We very quickly are able to ignore the horrors done in order to support these systems, simply because we want to benefit from those systems. We ignore how the materials for our phones are collected, we ignore how those phones are put together, so that we can have that which we want. Or that which we have been trained to want. That we ignore suffering is also part of our programming, part of our training. It is the suffering of others, the unworthy, those not like us. Coltran is reaped from the Congo, millions die in the Congo, the people who live there do not benefit in any way (other than their own surfers) and that is the way our heroes, the companies and entrepreneurs we worship, like it. They keep it that way so that *they* can benefit rather than those undeserving Congolese with their appallingly low market cap and utterly unappealing marketing.

We still have a system where the biggest, baddest, *meanest* dog wins. We just dress it up to make ourselves feel better. We feel better about it when we win. We feel better about it when we lose. But we are playing a game whose rules are determined by others.

On encouraging a prescriptivist to use more hyphens

Published by marco on in Miscellaneous

The title sounds like a self-post on Writing Prompts, but it describes quite accurately what I attempted to do when formulating a response to the essay Nobody. Understands. Punctuation. by Peter Welch (Still Drinking).

Below is the text of my mail to him.

I’ve read a few of your essays since you made such a splash with what you are probably aware is your making-it-to-the-big-time essay ”Programming Sucks” and I enjoyed the last one propounding descriptivism over prescriptivism.

A descriptivist is ordinarily well-shielded from any sort of grammatical suggestions because even the most bull-headed of grammar Nazis should know a lost cause when they see one. But I detected more than a whiff of someone who was interested in language and expression and, more than anything else, being *understood*. I liked the description of writing as being a medium through which “writers are trying to transfer the voices in their heads into yours.”[1]

I read through as you lavished attention on semicolons, the beloved em-dash, colons and commas. But you paid only lip service to the dash or hyphen, leaving it without an example in your essay.

I write because I thought that my dear friend the hyphen could have been more enthusiastically represented in a few other places in your writing.[2] I stumbled only a few times when reading your essay, across what I like to call “speed bumps”, which are where a punctuation choice causes me to read a sentence in an unintended manner until I end up in a dead end of sorts — a parsing error — from which I must back-track until I find the fork in the sentence at which I stopped following the author’s intent. In my experience, these forks often arise from a missing hyphen; that was the case in the following sentence:

“Punctuation started with periods that told the speaker when to take a breath, and as both a long time proponent of using the run on sentence to better communicate the ranting rage in my head over the nonsense that people choose to fight about in this country and a person who is occasionally asked to read his work out loud, I’ve come to value this original function in a visceral way.”

I would have had an easier time reading the sentence above had you included a hyphen between “long” and “time” and, ironically, “run” and “on”. Perhaps it’s just me and my penchant for hyphens. Their absence online and in many otherwise excellent essays by excellent authors occasionally gives me pause and reason to wonder whether my expectation of them is wrong-headed. Perhaps others are much more easily able to read “wrong headed” as a single word without a hyphen, or “back track” or “bull headed”. But, when I look these words up in a dictionary, there they are, defined in the official dictionary as having a hyphen.

I hope you take this missive in the spirit in which it was offered — and also as what it quite clearly also is: just a bit of fun writing on my part. I hope too that you are open-minded enough to consider whether maybe, just maybe, the hyphen could be paid a bit more attention and perhaps even wend its way into your writing where it would not only be grammatically correct but genuinely useful to the task of conveying meaning and fostering understanding on the part of the intended audience.

Cheers and keep up the good work. I follow your blog with pleasure.

[1] As your essay made abundantly clear, it’s not that a descriptivist doesn’t care about punctuation, but rather that punctuation rules shouldn’t become a distraction from the main task of imparting meaning. For example, I am strongly of the opinion that it matters not at all whether I place a period or comma within or without an ending quote because it has zero effect on the pacing of the sentence. I chose “inside” for old-time’s sake.
[2] As an aside, I want to stress that my attitude toward punctuation lines up quite closely with your own.[3] Did I consider briefly whether I should surround “the hyphen” in the previous sentence with commas? I did, but decided that my mental oration of it didn’t require them, so I left them out. Did I also consider whether “briefly” in the second sentence of this footnote should be bracketed — nay, strait-jacketed — with commas as well? I did, and moved on, once again, without them.
[3] Am I also a fan of footnotes as a source of humor and tangential information? I am.

Questions to consider when designing APIs: Part I

Published by marco on in Programming

A big part of an agile programmer’s job is API design. In an agile project, the architecture is defined from on high only in broad strokes, leaving the fine details of component design up to the implementer. Even in projects that are specified in much more detail, implementers will still find themselves in situations where they have to design something.

This means that programmers in an agile team have to be capable of weighing the pros and cons of various approaches in order to avoid causing performance, scalability, maintenance or other problems as the API is used and evolves.

When designing an API, we consider some of the following aspects. This is not meant to be a comprehensive list, but should get you thinking about how to think about the code you’re about to write.

Reusing Code

  • Will this code be re-used inside the project?
  • How about outside of the project?
  • If the code might be used elsewhere, where does that need lie on the time axis?
  • Do other projects already exist that could use this code?
  • Are there already other implementations that could be used?
  • If there are implementations, then are they insufficient?
  • Or perhaps not sufficiently encapsulated for reuse as written?
  • How likely is it that there will be other projects that need to do the same thing?
  • If another use is likely, when would the other project or projects need your API?

Organizing Code

  • Where should the API live in the code?
  • Is your API local to this class?
  • Is it private?
  • Protected?
  • Are you making it public in an extension method?
  • Or internal?
  • Which namespace should it belong to?
  • Which assembly?

Testing Code

  • What about testability?
  • How can the functionality be tested?

Even if you don’t have time to write tests right now, you should still build your code so that it can be tested. It’s possible that you won’t be writing the tests. Instead, you should prepare the code so that others can use it.

It’s also possible that a future you will be writing the tests and will hate you for having made it so hard to automate testing.

Managing Dependencies

  • Is multi-threading a consideration?
  • Does the API manage state?
  • What kind of dependencies does the API have?
  • Which dependencies does it really need?
  • Is the API perhaps composed of several aspects?
  • With a core aspect that is extended by others?
  • Can core functionality be extracted to avoid making an API that is too specific?

Documenting Code

  • How do callers use the API?
  • What are the expected values?
  • Are these expectations enforced?
  • What is the error mechanism?
  • What guarantees does the API make?
  • Is the behavior of the API enforced?
  • Is it at least documented?
  • Are known drawbacks documented?


This is a very important one and involves how your application handles situations outside of the design.

  • If you handle externally provided data, then you have to handle extant cases
  • Are you going to log errors?
  • In which format?
  • Is there a standard logging mechanism?
  • How are you going to handle and fix persistent errors?
  • Are you even going to handle weird cases?
  • Or are you going to fail early and fail often?
  • For which errors should your code even responsible?
  • How does your chosen philosophy (and you should be enforcing contracts) fit with the other code in the project?

Fail fast; enforce contracts

While we’re on the subject of error-handling, I want to emphasize that this is one of the most important parts of API design, regardless of which language or environment you use.[1]

Add preconditions for all method parameters; verify them as non-null and verify ranges. Do not catch all exceptions and log them or—even worse—ignore them. This is even more important in environments—I’m looking at you client-side web code in general and JavaScript in particular—where the established philosophy is to run anything and to never rap a programmer on the knuckles for having written really knuckle-headed code.

You haven’t tested the code, so you don’t know what kind of errors you’re going to get. If you ignore everything, then you’ll also ignore assertions, contract violations, null-reference exceptions and so on. The code will never be improved if it never makes a noise. It will just stay silently crappy until someone notices a subtle logical error somewhere and must painstakingly track it down to your untested code.

You might say that production code shouldn’t throw exceptions. This is true, but we’re explicitly not talking about production code here. We’re talking about code that has few to no tests and is acknowledged to be incomplete. If you move code like this into production, then it’s better to crash than to silently corrupt data or impinge the user experience.

A crash will get attention and the code may even be fixed or improved. If you write code that will crash on all but the “happy path” and it never crashes? That’s great. Do not program preemptively defensively in fresh code. If you have established code that interfaces with other (possibly external) components and you sometimes get errors that you can’t work around in any other way, then it’s OK to catch and log those exceptions rather than propagating them. At least you tried.

In the next article, we’ll take a look at how all of these questions and considerations can at all be reconciled with YAGNI. Spoiler alert: we think that they can.

[1] I recently read Erlang and code style by Jesper L. Andersen (Medium), which seems to have less to do with programming Erlang and much more to do with programming properly. The advice contained in it seems to be only for Erlang programmers, but the idea of strictly enforcing APIs between software components is neither new nor language-specific.

Dealing with improper disposal in WCF clients

Published by marco on in Programming

There’s an old problem in generated WCF clients in which the Dispose() method calls Close() on the client irrespective of whether there was a fault. If there was a fault, then the method should call Abort() instead. Failure to do so causes another exception, which masks the original exception. Client code will see the subsequent fault rather than the original one. A developer running the code in debug mode will have be misled as to what really happened.

You can see WCF Clients and the “Broken” IDisposable Implementation by David Barrett for a more in-depth analysis, but that’s the gist of it.

This issue is still present in the ClientBase implementation in .NET 4.5.1. The linked article shows how you can add your own implementation of the Dispose() method in each generated client. An alternative is to use a generic adaptor if you don’t feel like adding a custom dispose to every client you create.[1]

public class SafeClient<T> : IDisposable
  where T : ICommunicationObject, IDisposable
  public SafeClient(T client)
    if (client == null) { throw new ArgumentNullException("client"); }

    Client = client;
  public T Client { get; private set; }

  public void Dispose()

  protected virtual void Dispose(bool disposing)
    if (disposing)
      if (Client != null)
        if (Client.State == CommunicationState.Faulted) 

        Client = default(T);

To use your WCF client safely, you wrap it in the class defined above, as shown below.

using (var safeClient = new SafeClient<SystemLoginServiceClient>(new SystemLoginServiceClient(…)))
  var client = safeClient.Client;
  // Work with "client"

If you can figure out how to initialize your clients without passing parameters to the constructor, you could slim it down by adding a “new” generic constraint to the parameter T in SafeClient and then using the SafeClient as follows:

using (var safeClient = new SafeClient<SystemLoginServiceClient>())
  var client = safeClient.Client;
  // Work with "client"

[1] The code included in this article is a sketch of a solution and has not been tested. It does compile, though.

REST API Status codes (400 vs. 500)

Published by marco on in Programming

In a project that we’re working on, we’re consuming REST APIs delivered by services built by another team working for the same customer. We had a discussion about what were appropriate error codes to return for various situations. The discussion boiled down to: should a service return a 500 error code or a 400 error code when a request cannot be processed?

I took a quick look at the documentation for a couple of the larger REST API providers and they are using the 500 code only for catastrophic failure and using the 400 code for anything related to query-input validation errors.

Microsoft Azure Common REST API Error Codes

Code 400:

  • The requested URI does not represent any resource on the server.
  • One of the request inputs is out of range.
  • One of the request inputs is not valid.
  • A required query parameter was not specified for this request.
  • One of the query parameters specified in the request URI is not supported.
  • An invalid value was specified for one of the query parameters in the request URI.

Code 500:

  • The server encountered an internal error. Please retry the request.
  • The operation could not be completed within the permitted time.
  • The server is currently unable to receive requests. Please retry your request.

Twitter Error Codes & Responses

Code 400:

“The request was invalid or cannot be otherwise served. An accompanying error message will explain further.”

Code 500:

“Something is broken. Please post to the group so the Twitter team can investigate.”

REST API Tutorial HTTP Status Codes

Code 400:

“General error when fulfilling the request would cause an invalid state. Domain validation errors, missing data, etc. are some examples.”

Code 500:

“A generic error message, given when no more specific message is suitable. The general catch-all error when the server-side throws an exception. Use this only for errors that the consumer cannot address from their end—never return this intentionally.”

REST HTTP status codes

“For input validation failure: 400 Bad Request + your optional description. This is suggested in the book “RESTful Web Services”.”