Stone knives and bear skins – there is no money in tools
queue.acm.org
queue.acm.org
The article does actually say that in highly specialised niches tool making is fantastically lucrative. So, don't mistake the headline for ground truth.
Also there is good reason to believe tool making since flint knapping has been high status, and demands surplus production to liberate skilled labour to making tools which have immensely high use value: tools are magnifiers of human productivity and are worth a lot.
The point is that when commodities are cheap, and tools like gdb can be considered a commodity, the relative advantage of "a better one" has to be weighed up with using a screwdriver as a hammer. Thus printf() debugging.
But not every kind of tool. A gdb replacement would be a hard sell unless it managed to actually perform miracles. But specialty tools of the sort that can save a relatively small group of devs major pain and/or time? There's good money in that for a small business. That the market is too small to be attractive to large companies is just gravy.
I hope https://www.replay.io/ succeeds.
Couldn't a succesful actor say the same? "I know there's money in acting, because I've been making money acting for a long time".
And yet we'd instantly understand that doesn't refute the sense the statement was meant, and that acting isn't really the field you wanna pursue if you want to make money".
Same for any other niche endeavor, where there are thousands more lucrative fields and niches, and much fewer succesful examples compared to other areas.
That depends on the person. By the same token, software engineering isn’t the right field for the average person (because most people don’t have the knack for coding), and yet some people find they do have that talent.
A career is like dating, it’s mostly about finding a good fit, which means you also need to know yourself. Once you do, you may find a ‘bad’ niche is actually the right one for you.
Yes, that's the fallacy/issue I was addressing.
It's a market, and we try to evaluate it as a market, and talk about its characteristics.
Not about whether "if you're the next Brad Pitt you'd make millions".
That a general statement about the statistical properties of something (in this case, the IT tooling market) is refuted by pointing out individual counter-examples. Those can only refuse absolute statements.
Though I'm afraid this is not even a logical error. Instead it's a reading comprehension error, people read "there's no money in tooling", and think the author means "nobody made or makes money from selling tooling".
The latter (absolute statement) is not what TFA means, nobody claimed is the case, and is totally irrelevant to what's discussed. As are counter-examples to it (everybody already knows there are counter-examples).
Some are succesful in any crap market, where the chances are that most will go under or utterly fail, and where the conditions and average salaries and profit margins and such are attrocious.
"Some are succesful" as some kind of retort basically translate to "I don't care about market conditions, I have confidence in myself and I know I'll be one of the succesful ones".
Which is all well and good, but it doesn't say anything about one's chances of success, or that job market's behavior in general. Besides, historically it's what every fresh-eyed kid fresh off the bus from Nebraska, still waiting tables 20 years later, believed too.
Sure, many people suffer from self delusion, but that doesnt mean that their individual characteristics are meaningless.
If Jeff Bezos wanted to make tools, with all the power and money he has, he would have a much better chance than the average market participant.
Yes. That even one person makes money doing a thing is strong evidence that it's possible to make money doing that thing. Whether or not doing that thing is something you should do is an entirely different question.
Which would be relevant if the question at stake was whether it's "possible or not".
As opposed to the question whether people should focus on that market as a good market, where relatively more opportunities and money are than other IT areas.
Or did you thought those writing the post didn't already know several examples of companies making money selling tooling, and they didn't change their point, because the possibility of it was never what they were talking about?
Then you have the people who sold shovels and pickaxes to prospectors during the Gold Rush
Similarly a lathe or vertical mill is "a machine tool". They're ideally suited for a very specific task in the process of making a thing. It's possible for something to be both a machine and a tool.
If we're being pedantic, the ASML tools (and indeed any modern wafer fabrication equipment) are also robots.
More related to the business of tool making broadly, however, the entire industry of semiconductor wafer fabrication equipment (WFE) is quite profitable and margins tend to be generous. Much of the industry is very technical and does involve "bleeding edge technology", but not all of it. The publicly traded Japanese company Disco makes tools for wafer grinding[1], which are not really any more complex than your typical computer-controlled metal cutting machine tools, yet they are quite profitable[2]. Just look at those headline margin figures!
It seems to be a matter of niche and competition.
[1]: https://www.disco.co.jp/eg/products/grinder/dfg8560.html
[2]: https://www.disco.co.jp/eg/ir/library/doc/film/20230420.pdf
"You made a general argument. Here's a single counter-example, on a very tiny niche, compared to thousands of examples in your favor, making much more money in other areas of IT".
I called out an exception. I like the article. I think the point is well made. I would say it a bit differently: commodities are very hard to make profitably once the exemplar is good enough, and cheap enough. If you seek higher utility then don't be surprised if the people who use your Tool/Machine/Robot balk at the price, when their goal is met by the lower utility commodity.
If you don't care about lead and tolerance, those fake resistors are just fine for hobbyist use. If your project needs lead free and 0.001% then you really need to pay the premium for originals, not fakes.
And ASML is a niche, but an example of a generic problem in their line of reasoning. For almost any "industry" you care to mention from coathanger bending to lobster fishing, there is somebody making good profit selling what the coathanger-wrangler, or fisherman would call "a tool"
ie: cute argument, but actually... sorry.. niches are everywhere.
It's almost as if this missed the point of TFA entirely, and as if "things are sold in that field and there are some player making lots of money in it" is useless by itself for evaluating a field/niche regarding to its money making opportunities.
Let me introduce you to a wonderful concept: https://en.wikipedia.org/wiki/Opportunity_cost
Not bad for shitposting eh?
UV lithography is the only way to make advanced chips required for various other tools and appliances, but an OS debugger (as the author puts it) is just a nicer printf.
There's big money in one, and small money in the other.
It's just that the fruit in software tools doesn't hang so low, I think.
There is no money in tools because employers (and to some extent employees) don't value them. Also, folks who make tools maybe value them too much? And maybe tools are too easy to copy?
I remember decades ago when purify came out. I tried the demo at work on a project I was working on. Within a few hours, I found an enormous number memory errors. It was enormously helpful. Purify had a high per-seat license cost, and work wouldn't buy it.
Many current employers are a little smarter about things, but I mainly see things like code coverage tools and version control systems, but no real spending on more personal/fashionable tools, even if employees are more efficient.
I think tools that might work better would be those employees bought them themselves - think jetbrains - and priced accordingly. The analogy might be auto mechanics building up their collection from snap-on.
also, warts and all, linux is a nice environment because you can get to the bottom of most things and tools might be less industrial quality, but there are plenty of them.
When your time is worth $0, a product must be 10x better to be worth paying 10x as much. When your time costs $200,000/yr, a 1% improvement is trivially worth $2,000/yr.
People in software do not internalize this because we can build our own tools. We can solve the problem given time unlike say a chemist who can not build a reaction vessel. When we were poor, we built our own tools and we keep that habit even after we have money and our time is valuable.
It is absolutely ridiculous; the average janitor spends more on tools than a software developer. Truck drivers, secretarys, artists, mechanics, all spend more on tools even though their time is significantly less costly on average. In every other engineering profession companys literally spend $30,000, $100,000, and more a year keeping their high value workers productive.
Only in software do we think that $3,000/yr for Visual Studio, the tool that you literally use the entire time when doing Windows development, or $99 per year to do iOS development are “steep” costs. $99 is like one hour of time; it is ludicrously cheap.
$25,000/yr for a 25% productivity improvement is a no-brainer. The problem is that software people think it is obviously wrong, but the business people think it is obviously right. We do not need to struggle with hand trowels, the smart business people want to give us excavators, we just need to stop telling them no.
Most tools in those other professions don't have that problem. Once you buy them, they're generally static.
But yeah, your point about devs being hilariously stingy and not valuing their time is pretty spot on. I just don't think that's the main reason they don't want to buy commercial tooling.
Those are extremes but even simple things like getting a $100 plugin to parse a particular data format ends up being a time-wasting process that far exceeds the cost of the plugin, and if drawn out enough, the savings it would have produced over building it ourselves. As a result, building it ourselves tends to end up being the default choice.
Developer time is so expensive it is insane to spend more than a few minutes thinking about a $100 purchase. Your team should have thousands of dollars of open budget per member per year for tooling or critical purchases. Obviously it needs to be rectified regularly to evaluate if the purchases are actually worthwhile, but needing complex process for trivial expenditures like $1,000 is insane.
The funniest thing is that operations, cloud deployment, and data science teams do get serious tooling budget. Even though the fields are relatively adjacent and usually include some degree of software development, the fact that they are less capable of building their own tools means they get orders of magnitude more tooling spend.
Everybody knows that developer time is too valuable to spend when we can just throw more machines and tools at the problem. But in actual software development, we just forget that and go right back to wasting valuable developer time by cheaping out on tools. It is amazing.
It is about time we get some respect for our time and demand tooling budgets.
This is a lesson in life that most people really only realize once they start getting old and see more and more people around them die.
Time is money, and as we get older we (hopefully) have more money but we only lose and lose whatever time we have left. Money is theoretically infinite, time is finite. You can borrow money, but you can't borrow time.
At a certain point in life, paying money to save your time (aka use someone else's time) is worth it no matter how expensive it is.
For any given task you'll find 5 commercial solutions that basically make it 1-click, if you're lucky a few FOSS equivalents, and 5000 abandoned github repos that implement one or two specific features in the commercial ones.
Devs(In general, not myself) don't want debuggers, they want printf. They might want Linux, but they probably like their own DIY hobby OS more.
> People in software do not internalize this because we can build our own tools.
I think there's another aspect. Those tools are doing things we can do anyway. Here's a story of something I did recently:
I wanted to download a series from viki.com. They have switched from just sending you the video file to sending you an encrypted video file along with the encryption key. This is "more secure".
So, there's a process involving detecting your own request for the encryption key so you can replay it and get the response, decrypting the video file, decrypting the audio file, and then muxing them together with the unencrypted subtitle file using ffmpeg. After figuring this all out (which took a significant chunk of time), I could manually run the process in 5 minutes for one video.
I wrote a powershell script to automate all the parts of it that weren't finding the URL of the three media streams, detecting the request for the encryption key or echoing the request and getting the key. Those stayed manual. But the script handled downloading, decryption, and assembly and it cut my time per video from 5 minutes to 2 minutes. That's a 60% decrease! But it's also easy to say "hey, 5 minutes was already pretty fast; what do I care about 3 minutes?". The payoff from automation only looks good if you're doing a lot of it.
(The automation also made it obviously worthwhile to go nuts on adding metadata to the final video file, where that would have been more annoying in the all-manual process.)
My employer paid for both. But we sold even more expensive development software ourselves, and bought very expensive workstation and server hardware to run it on, so we were accustomed to the price points.
I like that great software is now open source, and most any kid or adult around the world can run it on a cheap decade-old PC. But I do miss some things about that software development era.
Jobs posted to HN by start ups are frequently comical in this regard. On one hand they claim to be solving tough problems and hiring only the sharpest people around, but more than half the time the hiring criteria just the same tool insanity as the corporate world. If I can make more doing half the work and dealing with the same stupidity in the corporate world then why would I want to work your start up? Maybe I just like being punished.
Talking bad about some tools often brings upon the same emotional fire as burning holy scripture in public. For many developers if not for certain tools, for example Java Spring or the big JavaScript frameworks, they could not program at all. They simply lack the skills to practice without such tools.
In these cases tools are more than valued. They are as essential to air and food. Its unfortunate, because economically that value is entirely artificial. An employer can easily eliminate these large tools, eliminate half the associated jobs, retrain the rest of the staff to move forward without those tools and pocket the difference without lose of productivity.
I don't think there's a day that goes by that I don't wish I had those capabilities again.
But, operating systems also have another important function: they have to defend against malicious software. In the days of Macsbug, every program had full read/write access to every other program's heap. That would be horrifying today. Every tactic that's been developed in the name of secure computing has made OS-level debugging significantly harder.
It was also a time when any consumer could issue a system interrupt with the same two keystrokes because it was built into mac OS, and see the cpu registers and enter hex to change the program flow. Since there was not as clean a system/program barrier as there was today and single threaded OS (I think?), before OS 8 the system froze all the time because of apps, and even non-expert users memorized the hex code for the system exit() trap.
Really? Is this only Linux (which gets a lot of eyeballs)? Mac OS? Maybe he's only talking about the kernel?
That's not new. The first user-space driver development was for the Michigan Terminal System on the System/360 model 67. That was the first computer with virtualization hardware. People have been doing this in IBM land for over half a century.
"Eh?" said the prospect. "What? Who cares how much pain the engineers are in? Its their job to endure pain."
Clearly, the founders hadn't fully perfected their sales pitch....
Tools in the "real world" generally work on one protocol: physics.
Yes.. there are standards and industries and the like in physical tools, but those are much more static and unchanging. Because physics and material world. A tool will generally be relevant until it wears out, and often/sometimes is useful for decades after "obsolescence".
In software, where (looks at the Javascript ecosystem) things change in a year. Sometimes less. Version churn and feature churn means your tool is obsolete/useless (if you are lucky) within 3-4 years. Often less.
In regular tools, it is pretty clear the distinction between a tool and the end product.
But in software, a tool is SOFTWARE, with all the problems of software: version churn, feature drift, underlying OS support, and all the other quicksand.
Tool markets are also inherently a fraction the endproduct market: The produced product volume is say 10x to 100x the value of the cost of the tool in the physical world before it needs replacement or wears out. Software being what it is, you can get 100000x - infinite the tool. That value proposition means the market for the tool is the inverse of the value factor of the tool. In software, you would get one tool and use it for 100000 products / views / etc. So the market for it is lower.
Perplexingly to my point about software tools going out of support, is that REALLY established tools are long lived and never wear out. So a hot gee-whiz tool will be competing against well-featured tools (often free after a while because tool vendors go out of business and open source it), so there isn't much gee-whiz anymore.
OpenAI is an interesting "tool". We'll see where it goes commercially. But most tools have reproducibility. AI tools do not, at least currently they don't.
Free software tools seem more durable, because the user population sustains it generally with contributions, bug reports, feedback, and demand. And sometimes the minimal money to support the org. And sometimes marketing.
Software is also generally about building a bandwagon. Gatekeeping tools are not good for bandwagon building. So software tools are generally free to make jumping on the bandwagon easier.
https://lwn.net/Articles/270089/
Linus Torvalds, in paraphrase:
> I happen to believe that stone knives and bear skins force people to think about their problem on a different level.
This is exactly as ridiculous as it sounds.
If your goal is putting venison on the table tonight, vs understanding deer behavior and herd migration and when deer are even in the area in enough numbers and so can even be thought of as a viable food source, a stone knife and a bear skin as tools might promote (or force through necessity) better understanding than a hunting rifle and a large puffy jacket.
That doesn't mean it's "better" or that everyone should be using shitty tools, but it is food for thought, and that perhaps doing it a few times is a learning experience that isn't all negative.
Tools that force you to hold a model of what's going on in your head and reason about its state require you to think completely differently than tools which hold the state or context for you outside of your head. Think about how different it feels to compose a message in your head, or with a pencil and paper, compared to using a word processor. You can even notice this effect by just typing text with your eyes closed as compared to staring at the screen as you type. The amount of context in your head affects how you think about things. At least for me, the tools I use greatly affect how much context I absorb into my head, and as a result what kind of theory generation and problem solving I can do, especially when a problem is hard enough that it requires several sessions of debugging.
I've tried it and it is really hard to get even the most basic debug output - a symbol'd stack trace of a crash.
If you can't get it at runtime, you need a kernel dump, and trying to get one is a mess. Once you have it, it is hard to match up the dump to the symbols. I believe some of the tools were kernel-version specific and I think when kernel 5 came out they didn't work.
I can't speak for other distros, but you install the relevant debuginfo(symbol files) and then use your tooling, and its been pretty straight forward, at least for the last 10 years.
Hit me up if you ever need assistance doing it on standard x86-64, I'll do what i can to help.
That suggests he's saying there is not upside in a portfolio of tool companies. Following average VC advice gives average VC results. If everyone listened to this kind of stuff we'd be awash is generic SaaS CRM stuff...oh