3 ms·

Software people massively over-classify their work as "R&D" when most of it is basically the equivalent of tuning or plumbing. R&D involves at least a little b

Software people massively over-classify their work as "R&D" when most of it is basically the equivalent of tuning or plumbing. R&D involves at least a little bit of the "R" part, which usually means some risk that the work is worthless. If you are just doing the development part, which is what you are doing when you ask the question "how do I push this metric?", private equity is usually happy to fund that. I generally wouldn't classify those (except for maybe the last one if you are developing fundamentally new user interfaces) as actually being R&D. I also know that the IRS classifies software development as R&D, but we all know those are not the same thing in reality.

lesuorac 2y ago
> I also know that the IRS classifies software development as R&D, but we all know those are not the same thing in reality. I think you may have spent too much time writing software to notice how R&D it is. You can pick whatever citation you want [1] but writing software is a very risky endeavor (in terms of ROI). "Generic IT" or SRE is really not R&D. If your solution to a bug is to "reboot" the device; that's an operational fix. If your solution is instead to read a stacktrace and write some code; that's R&D. [1]: https://www.google.com/search?q=most+software+projects+fail https://www.google.com/search?q=most+software+projects+fail
- pclmulqdq 2y ago
  Setting up shopify integrations, building a domain name registrar, and writing new web templates is not R&D. It carries no technical risk and the product is already known to be valuable. The only chance of failure is that you build it and nobody comes to buy because there's no reason to choose you over all the other people offering the same thing. I am sure that most software projects fail, but I am also sure that as a software developer, almost all of your work ends up in production. Sure, you will have minor technical setbacks, but not on the scale of actual R&D projects. In contrast, people doing R&D in pharma or other similar fields will spend months or years working on a single project that doesn't go anywhere because it is too hard. The same goes for civil engineers building bridges, for example: the work is highly technical, but it is not R&D. I very much disagree with you that pushing a 10-line bugfix is anywhere near R&D. There's no uncertainty, and there is no research. By the way, the act of thinking or problem solving does not make your work R&D. If it did, retail workers and construction workers would be doing a lot of R&D, too.
  - dartos 2y ago
    > In contrast, people doing R&D in pharma or other similar fields will spend months or years working on a single project that doesn't go anywhere because it is too hard. So does your argument boil down to “software moves faster than the sciences, so it’s not R&D?” Initial development isn’t R&D. Like you said, setting up a webpage and hooking up payments isn’t R&D. After a product is established, future work is R&D. A cycle of desired outcome, hypothesis for how to get there, and successive implementations until something sticks or the project fails and the hypothesis is proven wrong.
    - pclmulqdq 2y ago
      No, it's not about things moving fast. It's about projects carrying specific kinds of risk and developing a specific kind of output. Namely technical risk and intellectual property. Technical risk is the risk that your technical development won't pan out. I'm not referring to schedule risk - the risk that it will take longer than you thought - but actual risk that it will never work at all. Intellectual property is a durable, hard-to-copy advantage over your competition. Pharma is a great example because it is a very pure form of R&D - you find a drug, test the shit out of it, those tests mostly go negative, and if you succeed, you have a formula and a manufacturing method that lets you charge extortionate rates. Most software work is not like this at all. And no, ongoing future work is absolutely not guaranteed to be R&D. If anything, it is the opposite: most startups begin with R&D - creating an uncertain product with a (hopefully) durable advantage - and move out of doing R&D as they mature and the competition catches up. That is generally the lifecycle of companies that develop new product categories, from Singer (the first company to produce a sewing machine), to IBM, to Google.

lesuorac 2y ago

> I also know that the IRS classifies software development as R&D, but we all know those are not the same thing in reality. I think you may have spent too much time writing software to notice how R&D it is. You can pick whatever citation you want [1] but writing software is a very risky endeavor (in terms of ROI). "Generic IT" or SRE is really not R&D. If your solution to a bug is to "reboot" the device; that's an operational fix. If your solution is instead to read a stacktrace and write some code; that's R&D. [1]: https://www.google.com/search?q=most+software+projects+fail https://www.google.com/search?q=most+software+projects+fail

pclmulqdq 2y ago
Setting up shopify integrations, building a domain name registrar, and writing new web templates is not R&D. It carries no technical risk and the product is already known to be valuable. The only chance of failure is that you build it and nobody comes to buy because there's no reason to choose you over all the other people offering the same thing. I am sure that most software projects fail, but I am also sure that as a software developer, almost all of your work ends up in production. Sure, you will have minor technical setbacks, but not on the scale of actual R&D projects. In contrast, people doing R&D in pharma or other similar fields will spend months or years working on a single project that doesn't go anywhere because it is too hard. The same goes for civil engineers building bridges, for example: the work is highly technical, but it is not R&D. I very much disagree with you that pushing a 10-line bugfix is anywhere near R&D. There's no uncertainty, and there is no research. By the way, the act of thinking or problem solving does not make your work R&D. If it did, retail workers and construction workers would be doing a lot of R&D, too.
- dartos 2y ago
  > In contrast, people doing R&D in pharma or other similar fields will spend months or years working on a single project that doesn't go anywhere because it is too hard. So does your argument boil down to “software moves faster than the sciences, so it’s not R&D?” Initial development isn’t R&D. Like you said, setting up a webpage and hooking up payments isn’t R&D. After a product is established, future work is R&D. A cycle of desired outcome, hypothesis for how to get there, and successive implementations until something sticks or the project fails and the hypothesis is proven wrong.
  - pclmulqdq 2y ago
    No, it's not about things moving fast. It's about projects carrying specific kinds of risk and developing a specific kind of output. Namely technical risk and intellectual property. Technical risk is the risk that your technical development won't pan out. I'm not referring to schedule risk - the risk that it will take longer than you thought - but actual risk that it will never work at all. Intellectual property is a durable, hard-to-copy advantage over your competition. Pharma is a great example because it is a very pure form of R&D - you find a drug, test the shit out of it, those tests mostly go negative, and if you succeed, you have a formula and a manufacturing method that lets you charge extortionate rates. Most software work is not like this at all. And no, ongoing future work is absolutely not guaranteed to be R&D. If anything, it is the opposite: most startups begin with R&D - creating an uncertain product with a (hopefully) durable advantage - and move out of doing R&D as they mature and the competition catches up. That is generally the lifecycle of companies that develop new product categories, from Singer (the first company to produce a sewing machine), to IBM, to Google.