>> I spent a week putting too much time into a web game about Dogecoin. ... I can go from concept to product pretty damn quick.
I hear this pretty often, typically from very talented developers who have never shipped traditional commercial software as a product (which is definitely a dying breed). I don't care how good you are, you shipped a PoC in a week, not a product. It's great that your self reflection has identified what you're both good at and want to do, but a lot happens outside of writing code to create a product and this can take a long time. I've built a few in my career where I had involvement in the entire process, and typically the difference between when we're "done coding" to when the product is completed is 4x. I'm slow so maybe you can get this down to 3x, but I'm not convinced.
If I had one dream for software development the field and craft it's that we would build less, better.
The majority of the article is about how the author spent significant time working on mature products, not just doing little green field apps. It sounds like they definitely know the difference between a proof of concept and an actual product.
Besides, the only difference between the two is whether it has customers, it’s not engineering milestone that makes a POC a product.
> it’s not engineering milestone that makes a POC a product
My first reaction to this statement was, "no that's wrong." But then on reflection, I think that it might be accurate. HOWEVER,
> Besides, the only difference between the two is whether it has customers
This is wrong.
The difference between a proof of concept and a product, is that a product is assumed to be reasonably safe. A proof of concept can be barely held together by string and tape. Because it's just trying to gage the reactions of the stakeholders. Or even exploring the feasibility of the idea itself.
A product had better get the edge cases cleaned up. If you write an email client that sends the user's password to some random URL, then that's okay because it's just a proof of concept. Nobody should be using it yet. On the other hand, if Microsoft's Outlook sends your password off to some random URL, then that's a serious problem. Because Outlook is a product.
Proof of concept has a "use at your own risk" or "for demos only" attached to it.
Product has a moral and ethical obligation of the manufacturer attached to it. It had better be reasonably safe to use for the intended (or reasonably accidental) usages.
I see what you're saying, I just don't view it like that. There isn't any definitive way to say something is or isn't a product versus a proof of concept, my criterion included (it having customers).
Sure, maybe there are some really polished proofs of concept, and maybe there are absolutely horrendous products. Using your example of Outlook sending passwords, that doesn't suddenly mean it isn't a product and was reverted back to merely a POC. It's just a shit product.
Fortunately, it doesn't really matter. I just think folks shouldn't be so quick to shoot down one's accomplishments. Imagine seeing someone pursue their dreams and work on stuff they love, and the audiences reaction is "well, it's actually not a _real_ product." That's just lame.
> never shipped traditional commercial software as a product (which is definitely a dying breed).
And why might that be? Isn't it because people realized they make way more money charging for PoCs shipped in a week than "products" polished over several years?
Nobody cares what your engineering methodology is like if it doesn't print money.
It is a good thing. Even shitty software was underpriced back then. Developers and tech companies deserve massive ROI for the work they do. In an alternative world the Linux Foundation would have become the first trillion dollar company.
The fact that shitty software companies are raising massive valuations now should signal that the actual, real useful software companies are massively undervalued.
Sounds like classic gatekeeping to me. Do you get to decide what is a POC and a product? What qualifies something to be one over the other? Tests? Some other technical aspect that feels "producty"?
While you are busy building slowly entire companies are being built quickly. Perfectly? No. But your product probably isnt either.
A proof of concept becomes a product when the manufacturer sells it to clients with the expectation that it is reasonably safe to use.
Now. If it turns out that the product isn't reasonably safe to use and it hurts people, then the manufacturer has a moral and ethical obligation to cover the damage.
"reasonably safe" is often decided by the court system after a manufacturer hurts people with their products.
I hear this pretty often, typically from very talented developers who have never shipped traditional commercial software as a product (which is definitely a dying breed). I don't care how good you are, you shipped a PoC in a week, not a product. It's great that your self reflection has identified what you're both good at and want to do, but a lot happens outside of writing code to create a product and this can take a long time. I've built a few in my career where I had involvement in the entire process, and typically the difference between when we're "done coding" to when the product is completed is 4x. I'm slow so maybe you can get this down to 3x, but I'm not convinced.
If I had one dream for software development the field and craft it's that we would build less, better.