Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Programmers are famously hard to sell software to. Because:

a) They think they could do it themself in a weekend. Even though it took you 5 person years of work.

b) They are used to using lot of free and opensource software and don't expect to pay for software.

Other technical users (chemical engineers, civil engineers etc) are probably easier to sell to. But I don't have any data to back that up.



There’s sometimes some truth to the “I could do it in a weekend” thing (hear me out!).

I think it is often true that 1) a talented programmer 2) can solve their own specific use case 3) in a janky way that is only usable to them, in a weekend.

That’s very far off from a product, but is enough for the programmer to not become a customer.


there was a famous psych test from the early 90s when some social scientists were studying the new breeds of coders. They did a few of them including one where a programming task of ordinary complexity was assigned.. the programmer was asked for an estimate of the time to solve it, then they solved it. IIR a preponderance of results were an estimate of "30 minutes or so" and then the actual wall clock time to a solution was closer to two hours.. many times.

Analysis was that the engrossing and engaging activity of coding directly warped the time-sense of the coder, as a regular phenomenon.

As an aside another test at that time was comparing the production results of someone using a mouse-driven interface versus someone using a keyboard only. The keyboard-only users repeatedly claimed to be faster than any mouse-user, but the timed tests were the opposite, by a large margin.


Really interesting. I always put bad estimates down to individual biases, not something more systematic. I’d be really curious to see if this also is true for bigger tasks and whether it changed over time (at least for me I can honestly say it didn’t), small insights like there might reduce friction when working within a team or with narrow deadlines


As a child, I quickly learned to multiply any of my father’s task time estimates by at least 3.

Unfortunately he had anger issues at the time, so it was a constant cycle of “do this thing, your taking too long, I’m adult throwing a rage tantrum at kids, repeat”.


Yes. But the janky solution they thought they could do in an hour takes 10 hours, and, in retrospect, they would probably still have been better buying the software. ;0)


Civil engineers won't buy from small companies because they don't think you'll be around for long. And then when you sell to Autodesk because nobody is really buying, they will buy and complain forever about the Autodesk price gouging.


Or:

c) They don't trust that the tool will be around for a long time


That is definitely an issue for web software. Less so for desktop software. The software I wrote in 2005 still runs (the licence is perpetual), if you can find an old enough version of Windows.


This is absolutely a thing in 2024. Or less drastically the many examples of a development team being cut, further development being sporadic and bug prone, and a detached and patronizing ticket system for support instituted.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: