6 ms·

An alternative: Build a PoC first. The reason coding the shortest path first feels better is that you hit milestones early. However, it is a major generator of

An alternative: Build a PoC first. The reason coding the shortest path first feels better is that you hit milestones early. However, it is a major generator of technical debt, and fleshing out the project is the hard part that takes longer and introduces breaking changes. Taking time to plan, getting the API planned in advance, generalising the code (obviously not TOO much), and so on might feel less rewarding at first, because the early milestones are the hard part. But do it right and you end up seeing everything fall into place in quick succession, according to plan - and that’s a much greater sense of achievement IMO. It is often also a quicker way of seeing large projects to completion, though it doesn’t always feel like it at the time. Building a Proof of Concept allows you to get the best of both worlds. It allows you to be naive, it allows you to write the bare minimum, and it gets something working that others can try out and give feedback on. As a bonus, it doesn’t generate technical debt, because you don’t build on the PoC - you use it as a reference while building the actual thing.

JonChesterfield 3y ago
> because you don’t build on the PoC Ah yes, I remember that idea. Naturally we shipped the proof of concept. Also "it is known" that rewrites from scratch are bad things, so it got iterated on instead of replaced. Based on the internal architecture of other software I've seen I think this is a relatively popular development strategy.
- pyrale 3y ago
  > I think this is a relatively popular development strategy. ...And this is why PoCs should be small-scale but technically sound things, rather than a shortcut competition. People are rarely going to complain about a PoC delivered a week late, but they are definitely going to complain later on, after they ship the PoC against your opinion and development slows down.
  - mejutoco 3y ago
    People can complain about anything. That does not mean they are right. If a PoC is later extended, it will of course have limitations. We do not need to change the meaning of PoC to full product to preemptively solve that. Instead, when a PoC is done everybody involved needs to understand the implications. If people insist on misinterpreting them, that is on them. Those are political problems, not technical ones. They can be solved by aligning incentives. TLDR. A PoC is a PoC, not a full product.
    - pyrale 3y ago
      > Those are political problems, not technical ones. [...] TLDR. A PoC is a PoC, not a full product. Politics eat technnological semantics for breakfast though. It's up to you to decide whether this is a hill you want to die on. > They can be solved by aligning incentives. Often enough, that means shipping the poc.
      - mejutoco 3y ago
        > Instead, when a PoC is done everybody involved needs to understand the implications. > Politics eat technnological semantics for breakfast though. I see where you are coming from, but I have to disagree. I am not debating semantics, but reality. A prototype will always have limitations. That is the definition of a prototype. I understand in reality sometimes it is worth to push through (startup), and sometime it is not needed but it is demanded. I am not starry-eyed, but it is useful to know what the reality is before one tries to bend it or adapt to it. If you want, Nature/laws of physics eats politics for breakfast :) Aligning incentives in this case could mean making the developer have a stake in the outcome (bonus), have competent people and clear deliverables, and bonuses for products that work well/convert. Not just for speed or busyness. Basically you are assuming a sort of feudal relationship between someone handing arbitrary deadlines and (whatever you must do) and someone in charge of implementing it having no say in anything, and obeying blindly. That is not how the best engineering is done. Places exist (I have worked in some of them) where people can be professional, and a lot still gets done at the end of the day, even more than with the stick and harsh words approach. A certain amount of back and forth is healthy and can produce much better outcomes for the company.
  - btbuildem 3y ago
    I strongly disagree, I think you misunderstood the purpose of a PoC We build these things to flesh out ideas, to put something in front of PMs and ideally customers, to get feedback, and to make sure that we have a good bead on what the Most Important Problem is. PoCs are disposable, sticks-and-ductape contraptions to demo features, and maybe have a small subset of users to play with for a limited time. They are by no means starting points for actual development.
  - sumtechguy 3y ago
    Even if you make it clear they will continue to use it. I have one bit of code 'i do not claim any knowledge of' that I bashed out in under 1 day with promises that it will be re-written soon. 5 years on I still get questions about it. I get questions because it is a PoC that does one thing very well and everything else badly.
  - jeromino 3y ago
    By that time the POC shipper got promoted for releasing fast, and no longer does dev on that team, and the replacements get harangued for delivering late. Business doesn't care who created the problem in the first place.
- Etheryte 3y ago
  There is a somewhat malicious compliance way of avoiding this, and that's to write the proof of concept in an obscure language or using some other set of tools that makes it impossible to pick up as-is by the rest of the team. The downside is that it also adds an additional cost to you when building it.
  - ghosty141 3y ago
    Obscure is not even needed sometimes, for embedded stuff you can just use a lang that doesnt run fast enough on the tafget hardware
  - loloquwowndueo 3y ago
    I’ve seen entire teams get fired for using a non-approved language to build the PoC :(
  - ZaoLahma 3y ago
    Does not work and makes life worse. I once in an earlier life worked in a very Java centered company, and we had a C# component that our "normal" Java blob was communicating with that an old team member left behind right before he left the company. So no one in the team wanted to touch the C# parts, but once per year or so we had to when we (sometimes unknowingly) introduced backwards incompatible changes to the API that the C# component was using for communicating with our Java blob. Last thing we were thinking about before I left was... NOT to rewrite the C# parts in Java properly, but to wrap all of it in a thin Java layer that we could use as an adapter when the API inevitably changed.
    - OkayPhysicist 3y ago
      How inflexible do you have to be that nobody on a team bothered to pick up C#? Java and C# are probably the two most similar languages that are still considered distinct.
      - ZaoLahma 3y ago
        It was never about competence. Most of us were of different backgrounds. It was about the need to track down, secure licenses for and install the dev environment that you'd use for those 4-8 hours per year that it took to add support for the new API. The entire company lived in the JVM otherwise.
kristiandupont 3y ago
How do you differentiate? To me, building a PoC is exactly that: create the shortest path, in order to (in)validate the concept.
- atlantic 3y ago
  Exactly. The proof-of-concept app should address the core technical obstacles in the new project, and prove they are surmountable in the simplest possible way.
  - btbuildem 3y ago
    That's a dev-centric perspective. Alternately, a PoC should address the core business and usability questions. Everything else, including technical feasibility, is secondary and trivially solved with enough resources. In the order of importance, the first question is "is this worth doing", only then you ask "how can we do this"
    - atlantic 3y ago
      Good point. I'm a dev, so by the time this kind of project reaches me, the business angle has (presumably) been sorted out, and it's the technical feasibility that is in question.
senel 3y ago
This also helps you think about how feasible the overall project would be in terms of coding.
oweiler 3y ago
Just make sure that it ends in the bin and is not shipped. I often write the PoC as a Kotlin script, with dependencies declared inline with @file, no tests, Just the bare minimum. No one would ask to ship this.
- i-use-nixos-btw 3y ago
  Absolutely. A PoC is supposed to be badly thought out, that’s the point. Get from A to B quickly, in whatever way possible, and then get feedback while building the real deal properly. There has been some pushback against that idea on here, but I’m firm on it. My approach these days is actually to get the PoC done with a lot of assistance from ChatGPT and copilot. It generally works great and fulfils the basic criteria, but isn’t production grade in the slightest. That’s fine - it means I can provide PoCs in the space of an hour or two, and it gives me something to aim for and refer to.
irq-1 3y ago
“Where a new system concept or new technology is used, one has to build a system to throw away, for even the best planning is not so omniscient as to get it right the first time. Hence plan to throw one away; you will, anyhow.” - Fred Brooks

JonChesterfield 3y ago

> because you don’t build on the PoC Ah yes, I remember that idea. Naturally we shipped the proof of concept. Also "it is known" that rewrites from scratch are bad things, so it got iterated on instead of replaced. Based on the internal architecture of other software I've seen I think this is a relatively popular development strategy.

pyrale 3y ago
> I think this is a relatively popular development strategy. ...And this is why PoCs should be small-scale but technically sound things, rather than a shortcut competition. People are rarely going to complain about a PoC delivered a week late, but they are definitely going to complain later on, after they ship the PoC against your opinion and development slows down.
- mejutoco 3y ago
  People can complain about anything. That does not mean they are right. If a PoC is later extended, it will of course have limitations. We do not need to change the meaning of PoC to full product to preemptively solve that. Instead, when a PoC is done everybody involved needs to understand the implications. If people insist on misinterpreting them, that is on them. Those are political problems, not technical ones. They can be solved by aligning incentives. TLDR. A PoC is a PoC, not a full product.
  - pyrale 3y ago
    > Those are political problems, not technical ones. [...] TLDR. A PoC is a PoC, not a full product. Politics eat technnological semantics for breakfast though. It's up to you to decide whether this is a hill you want to die on. > They can be solved by aligning incentives. Often enough, that means shipping the poc.
    - mejutoco 3y ago
      > Instead, when a PoC is done everybody involved needs to understand the implications. > Politics eat technnological semantics for breakfast though. I see where you are coming from, but I have to disagree. I am not debating semantics, but reality. A prototype will always have limitations. That is the definition of a prototype. I understand in reality sometimes it is worth to push through (startup), and sometime it is not needed but it is demanded. I am not starry-eyed, but it is useful to know what the reality is before one tries to bend it or adapt to it. If you want, Nature/laws of physics eats politics for breakfast :) Aligning incentives in this case could mean making the developer have a stake in the outcome (bonus), have competent people and clear deliverables, and bonuses for products that work well/convert. Not just for speed or busyness. Basically you are assuming a sort of feudal relationship between someone handing arbitrary deadlines and (whatever you must do) and someone in charge of implementing it having no say in anything, and obeying blindly. That is not how the best engineering is done. Places exist (I have worked in some of them) where people can be professional, and a lot still gets done at the end of the day, even more than with the stick and harsh words approach. A certain amount of back and forth is healthy and can produce much better outcomes for the company.
- btbuildem 3y ago
  I strongly disagree, I think you misunderstood the purpose of a PoC We build these things to flesh out ideas, to put something in front of PMs and ideally customers, to get feedback, and to make sure that we have a good bead on what the Most Important Problem is. PoCs are disposable, sticks-and-ductape contraptions to demo features, and maybe have a small subset of users to play with for a limited time. They are by no means starting points for actual development.
- sumtechguy 3y ago
  Even if you make it clear they will continue to use it. I have one bit of code 'i do not claim any knowledge of' that I bashed out in under 1 day with promises that it will be re-written soon. 5 years on I still get questions about it. I get questions because it is a PoC that does one thing very well and everything else badly.
- jeromino 3y ago
  By that time the POC shipper got promoted for releasing fast, and no longer does dev on that team, and the replacements get harangued for delivering late. Business doesn't care who created the problem in the first place.
Etheryte 3y ago
There is a somewhat malicious compliance way of avoiding this, and that's to write the proof of concept in an obscure language or using some other set of tools that makes it impossible to pick up as-is by the rest of the team. The downside is that it also adds an additional cost to you when building it.
- ghosty141 3y ago
  Obscure is not even needed sometimes, for embedded stuff you can just use a lang that doesnt run fast enough on the tafget hardware
- loloquwowndueo 3y ago
  I’ve seen entire teams get fired for using a non-approved language to build the PoC :(
- ZaoLahma 3y ago
  Does not work and makes life worse. I once in an earlier life worked in a very Java centered company, and we had a C# component that our "normal" Java blob was communicating with that an old team member left behind right before he left the company. So no one in the team wanted to touch the C# parts, but once per year or so we had to when we (sometimes unknowingly) introduced backwards incompatible changes to the API that the C# component was using for communicating with our Java blob. Last thing we were thinking about before I left was... NOT to rewrite the C# parts in Java properly, but to wrap all of it in a thin Java layer that we could use as an adapter when the API inevitably changed.
  - OkayPhysicist 3y ago
    How inflexible do you have to be that nobody on a team bothered to pick up C#? Java and C# are probably the two most similar languages that are still considered distinct.
    - ZaoLahma 3y ago
      It was never about competence. Most of us were of different backgrounds. It was about the need to track down, secure licenses for and install the dev environment that you'd use for those 4-8 hours per year that it took to add support for the new API. The entire company lived in the JVM otherwise.

kristiandupont 3y ago

How do you differentiate? To me, building a PoC is exactly that: create the shortest path, in order to (in)validate the concept.

atlantic 3y ago
Exactly. The proof-of-concept app should address the core technical obstacles in the new project, and prove they are surmountable in the simplest possible way.
- btbuildem 3y ago
  That's a dev-centric perspective. Alternately, a PoC should address the core business and usability questions. Everything else, including technical feasibility, is secondary and trivially solved with enough resources. In the order of importance, the first question is "is this worth doing", only then you ask "how can we do this"
  - atlantic 3y ago
    Good point. I'm a dev, so by the time this kind of project reaches me, the business angle has (presumably) been sorted out, and it's the technical feasibility that is in question.

senel 3y ago

This also helps you think about how feasible the overall project would be in terms of coding.

oweiler 3y ago

Just make sure that it ends in the bin and is not shipped. I often write the PoC as a Kotlin script, with dependencies declared inline with @file, no tests, Just the bare minimum. No one would ask to ship this.

i-use-nixos-btw 3y ago
Absolutely. A PoC is supposed to be badly thought out, that’s the point. Get from A to B quickly, in whatever way possible, and then get feedback while building the real deal properly. There has been some pushback against that idea on here, but I’m firm on it. My approach these days is actually to get the PoC done with a lot of assistance from ChatGPT and copilot. It generally works great and fulfils the basic criteria, but isn’t production grade in the slightest. That’s fine - it means I can provide PoCs in the space of an hour or two, and it gives me something to aim for and refer to.

irq-1 3y ago

“Where a new system concept or new technology is used, one has to build a system to throw away, for even the best planning is not so omniscient as to get it right the first time. Hence plan to throw one away; you will, anyhow.” - Fred Brooks