24

On Marketing Haskell

 2 years ago
source link: http://www.stephendiehl.com/posts/marketing.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

In the last year, there has been a fair bit of discussion about the economics of Haskell ecosystem and the confounding factors that have led to its potential stagnation. At the same time the language and the technology is maturing into the most mature ecosystem we’ve seen to date, with innovation happening left and right across a variety of fronts. Editor tooling is reaching levels of maturity we only dreamed about years ago.

Haskell as an ecosystem sits on a knife-edge, it could easily fall apart leaving only the remains of a very advanced ecosystem behind with no practitioners left to maintain the bit-rotted pieces. Or it could thrive and evolve into a widely used and researched paradigm that continues to refresh and reinvent itself on every new generation of programmers that gets involved. I probably won’t be involved long enough to see what happens but I have a strong inclination to see it on the later path.

However the singular truth remains that unless Haskell sees more industrial use then there can never be any serious progress. Many people have written root-cause analyses on why this is the case, however most of them are very engineering-centric arguments about technical minutia of language extensions and compilers. While there is some truth to the technical deficiencies, I would argue that these are not correlated with industrial success in any meaningful way.

The hard economic truth for engineers is that technical excellence is an overwhelmingly irrelevant factor. The history of our profession is full of cases that are evidence against technical excellence. Javascript as a language largely only came to dominate the browser ecosystem because the Netscape marketing department decided on a clever marketing ploy to circumvent Sun Microsystems and give its own new language cachet by hijacking an existing trend. These kind of marketing tricks are likely the only path to greater adoption.

Persuasion and Decision Makers

There’s a wonderful book given to me by a friend entitled “Christ Was an Ad Man” by Robert Pritikin (ISBN: 9780965906906) which is a realpolitik perspective of the world of advertising and persuasion. It’s a funny read (the title itself is a meta-reference) about an 1980s era ad executive who gives an inside view behind the making of advertising to consumers and the psychology of targeting. The thesis of the book is that the dichotomy between honest advertising and deceptive marketing is an illusion. Instead the world is divided into four quadrants of people across two axises. The first axis is people who are informed enough to make a decision and people are uninformed enough to decide. The second axis is people who are looking to make a decision and people who have already made a decision.

People who have already made a decision and are economically invested in it rarely change their minds about anything; this is readily apparent in high-investment “purchases” such as software. People who are uninformed and haven’t made a decision will either choose randomly or require more information to become informed. Conveying correct Information is time consuming and as a marketer doesn’t give a good return on investment for your time. So then you’re left with the only group that’s actually worth addressing are the people who are informed enough to make a decision but haven’t made up their mind yet. Rather the actual decision you should target your marketing specifically to this group, and through hype and subterfuge based on four factors:

  1. It is memorable
  2. It includes a key benefit
  3. It differentiates
  4. It imparts positivity

Haskell’s Marketing

If you look at comparative discussion about programming languages, you’ll realise that very little higher-level thinking is actually involved. Universities simply don’t give students the cognitive frameworks to do comparative discussions of tools. Instead of our discourse being about semantics, engineering quality, and implementation; we instead discuss our tools in terms of social factors and emotions (i.e. it “feels readable”, “feels usable”, “feels fast”).

Going back to marketing perspective, we have to ask ourselves how exactly has the discourse evolved into how Haskell perceived in the larger programming world. The official site comes with the slogan:

An advanced, purely functional programming language

The slogan is not optimal inside the above matrix because it’s addressing people who are already informed and have already decided. It isn’t memorable, it doesn’t include the key benefits of the tooling or differentiate in any way. This isn’t great marketing.

Outside of the official site, overwhelmingly one narrative dominates all others. Haskell is “correct” and that code in Haskell is more correct than others. This in and of itself would normally be a succinct and good story to tell if it didn’t go completely against the grain of where software has been heading for the last 15 years.

Economics of Correctness

This will be a bitter pill to swallow for many Haskellers but outside of a very few domains, software correctness doesn’t matter. Software deals worth hundreds of millions of dollars are done based on little to no code and are sold as successes even if they fail. Over 80% of enterprise software projects fail or are vastly over budget. Increasing labour costs means that the only thing that matters overwhelmingly is time-to-market at the expense of all else. Managing a software project isn’t about correctness or engineering anymore, it’s about running a risk portfolio of toxic assets. If you’re managing a software project then choice of software tools does matter, but it pales in comparison to simpler ways to mitigate risk:

  1. Offset the risk using as many legal and insurance instruments possible.
  2. Have a high liquidity talent pool.
  3. Factoring software failures into the expectations and economics of projects.
  4. Ability to restart the project with different assumptions and team if it all goes awry.

These factors overwhelmingly dominate the decision making and feed back into the choice of tooling. If the talent pool is illiquid or geographically locked that’s a non-starter. If there isn’t a large corporate vendor to go to sign up for a support contract then that’s a non-starter. If there isn’t a party to sue as an insurance policy against failure, then that’s a non-starter. These are existential problems for small organic ecosystems that don’t have large corporate backing.

The bottomline is that rather than using more correct tools and engineering practices, it is simply far easier and more economical to hedge software risk with non-technical approaches. Combine that with the approach that if you throw enough bodies writing Java at a project for a long period of time it will produce a result or fail with a fairly predictable set of cashflows, that’s a low quantifiable risk that’s very easy for a business to plan for. The economics of corporate software and a management culture that has fully embraced neo-Taylorism is in contradiction with the Haskell narrative of correctness through engineering excellence.

Simple Haskell

There’s been discussions about “Simple Haskell” as a set of best practices to spur more successful industry projects. While I’ve read these arguments and there are some genuinely thoughtful things to be said, I can’t help but feel it’s a bit backwards. What I see is manifestos for engineers writing about problems for other engineers, under the assumption that changing engineering practices will somehow change the situation that gave rise to the problems in the first place.

The fundamental question is how is the community going to present the language that gives it any industrial relevance in the 2020-2030 era. How is the next generation of engineers going to shape the Haskell narrative so that we don’t have to restrict ourselves from the advanced tools we have? We have a very advanced compiler and tools to build correct software, but it’s not enough. We need some equally clever marketing beyond just “correctness”.

In Pritikin’s book there’s one advertising slogan that comes off as most applicable to Haskell.

There is a steak in every hot dog.

You can sell Simple Hot Dogs to the masses, but what is the “steak” for Haskell that makes you buy that brand?


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK