It’s been a rainy week here at Fair Pavilion. I haven’t been getting outside much, so here’s a photo from a hike a few weeks ago.
you’re not in the market you think you’re in – you’re in the market your users think you’re in
That’s from a lengthy and soul-searching retrospective on the now-shuttered RethinkDB project.
In many ways it’s an endictment of the developer tools market:
Engineers love building developer tools, so they badly want developer tools companies to thrive.
I am hesitant to dismiss the market entirely – partly because I don’t want to generalize from a single experience, partly because I don’t like saying “it cannot be done”, and partly because there are quite a few exceptions. GitHub, MongoDB, and Docker have built formidable companies. GitLab and Unity seem to be doing well.
If you do set out to build a developer tools company, tread carefully. The market is filled with good alternatives. User expectations are high and prices are low. Think deeply about the value you’re offering to the customer. Remember – wanting the world to be a certain way doesn’t make it so.
As a one-time veteran of a developer tools startup, my view of that market is similarly jaundiced.
Every hacker has a great idea idea for a developer tools startup at some point. But it’s a tough market to succeed in.
- It’s just not as big a market as you think it is. Yes, there is gobs of money in the software industry as a whole. But the money available for tools servicing that industry is orders of magnitude smaller.
- Other shops’ pain points are less similar to yours than you think.
- Everyone looks at your great idea and thinks “oh, I could do that internally, it’s just a simple matter of coding”. The fact that they are wrong does nothing for your bottom line.
- The more desperately a company needs your tools, the more peculiar will be their ball of legacy code and the more unexpected and non-standard will be their workflows. You will dump hundreds of hours into supporting these hard cases, in order to have compelling success stories. But most of that work won’t translate into supporting the next special snowflake.
- The gulf is deceptively wide between “that’s a really cool idea!” and “I’m going to invest time and energy into incorporating it into our processes.”
- If the idea really has legs, the proof will be that everyone else copies it and commoditizes it and it becomes part of the new baseline of tools. Which most likely leaves you back at square one, hopefully having sold your technology to a enterprise dev tool company before the market for it tanked. Of course, if the commoditization happens in the form of a really great Open Source alternative, even that exit may not be an option.
In response to SIGAVDI #26, subscriber Ariel Caplan writes:
From the user’s perspective, the documentation is always right, while the software might be broken. (We developers are often “advanced” users who expect broken documentation, but that’s just a symptom of our flawed perspective.) The further out you get, the more abstract your perspective, the more you see the truth of software.
This is one of the most difficult shifts of perspective for a developer: seeing the software as an opaque artifact defined by user experience, rather than in terms of its internal organization.
For a practical application of this point of view, check out Ariel’s great blog post on “automating empathy” with Apivore and Swagger.
Paul Chiusano asks “If Haskell is so great, why hasn’t it taken over the world?”. I think in this context, Haskell functions as a stand-in for any “clearly superior” programming language which hasn’t seen much uptake. Paul answers:
The simplest explanation is probably that Haskell is not that much better than, say, Java, for many of the software systems people write today. Why might this be?[…] Since most software systems (especially those that span multiple nodes), have a large surface area in contact with the outside world, the code devoted to merely getting information at these boundaries into some more computable form is often the bulk of the work; once the data is in computable form, the actual computation needing to be done is easy. […] If you’re writing a CRUD app, or some other computationally boring system that has a large, complex surface area in contact with the outside world, writing code to deal with that program boundary often dominates the codebase.
This is a big part of why I don’t get especially excited about most new programming languages these days. And particularly, about the kinds of improvements most of the newly-ascendant statically-leaning, functional-influenced languages are focused on delivering.
I liken it to automobile development, circa 2000. Every year, the automakers tweaked their cars. Every year, they really did get a little better. The reliability improved. The safety systems became more effective. The drivetrains became more efficient.
But fundamentally, the car designers were tweaking things that they were good at tweaking: a slightly lighter and stiffer frame. A more intelligent fuel injector. An extra airbag.
I can appreciate this stuff. I can even upgrade my car every few years to take advantage of it. (Well, OK, I can’t because when you have four kids you don’t have the budget for stuff like “new cars”, but I probably would if I could).
But I don’t get excited about it. And neither is most of the rest of the population.
Only in the last few years have I started to see ideas gaining traction from the likes of Tesla and Google which will remake the entire automobile economy. Now that stuff is exciting.
As far as I can tell, most computers scientists are tweaking the language aspects that they are good at tweaking. And for the most part, that means features which improve the experience in the “guts” of a program’s logic. Not so much the experience around its edges.
It’s good, important work. But forgive me if I don’t dance a jig when someone announces that their language supports union types.
Thankfully, there are a few people out there (such as Paul Chiusano, quoted above) who are eying larger steps.
Erik Dietrich has a nice article on communicating with the non-coders on your team:
But your collaboration with the QA folks should go much deeper than simply not snapping at them. QA will wind up signing off on your application after running it through the paces, so, make yourself more efficient by going to them before doing your development. Ask them to show you how they’ll know when the code is good — what tests it will need to pass. Armed with this knowledge, you can leverage their keen eye for issues to guide your development. As an added bonus, enlisting them up front will help you start to reason about an application’s performance with a more removed, more critical eye.
If there’s a trend I’ve seen among people I trust to predict the future of software, it’s that VR/AR is legitimately a Big Deal. It’s also a bit of a scary deal:
Joshua Kopstein of The Intercept warns that “the very systems that enable immersive experiences are already establishing new forms of shockingly intimate surveillance.” As Kopstein foresees it, “the psychological aspects of digital embodiment — combined with the troves of data that consumer VR products can freely mine from our bodies, like head movements and facial expressions — will give corporations and governments unprecedented insight and power over our emotions and physical behavior.”
Kopstein describes a new “emotion detection” analytics industry that uses sensors and head/eye tracking to “unlock human emotion” (as Baton Rouge VR startup Yotta Technologies claims to do). The resulting inner portrait, prized by marketers as well as spooks, will become all the more rich and complete if VR outgrows head-mounted devices (HMDs) and is beamed “straight into the ocular nerve,” as Creative Control director Benjamin Dickinson told us may happen.
Peter Feld asks us to consider the potential for abuse of this unprecedented level of surveillance opportunity.
And now, here’s what’s new with me:
- I’m planning a big thing in collaboration with Thoughtbot’s Upcase. We’re still hammering out details, but if you want to find out more, go here.
- I wrote down some (slightly tongue-in-cheek) guidelines for optimizing software in any programming language.
- For those who enjoy reading about the business/entrepreneurial side of things, I finally wrote up my reasons for abandoning efforts to write my own software to host and deliver RubyTapas.
- I posted another note from the crucible, this one about digging and escaping holes.
Thanks for reading, and as always, keep in touch!