Yay, I inherited a project with no documentation that is soon to be out of the prototype phase in a tech stack where I have no experience. It is already sold to customers and they expect it soon.

There are so many bugs, never been code reviewed but the main functionality semi-works :(

  • 5
    That's a proper I'm-the fuck-outtahere moment
  • 3
    I have to agree with @PonySlaystation on this one.

    Before you GTFO make sure you document everything wrong with it and make sure you CYA.

    Last thing you need is the stench of that shit hanging over your head afterwards.
  • 2
    Oh boy.

    I hope you can be honest about your concerns with the company. If they already know the functionality is just semi-working but have hoped it'll be resolved moments before launch - I would actually mention that "This is a new tech stack for me, and a new codebase, so we should obviously expect a lower development speed from now on. We might even move backwards sometimes as I might break features that have been working so far, or need to refactor parts them"
  • 2
    Prototyping? You know what happens with a project at the end of prototype phase? It's scrapped...

    Well... I've never seen one actually scrapped... But software engineering text books tell you to throw it out as soon as you're done prototyping...

    Because it's just there so the team learns valuable lessons... So why the fuck did you inherit a prototype? If you inherited it, it cannot be a prototype
  • 1
    @TheCommoner282 Yeah, you're right. I think of a software prototype similar to what they do when they make the prototype for a mold in manufacturing or something. The prototype can be hackily made with with tape and string. The real product would be inspired by the prototype but rebuilt from scratch.

    @wojtek233: did you really mean "prototype" - or just alpha/beta/work-in-progress?
  • 1
    @jiraTicket The word that our teamlead used was a proof of concept. I'm not exactly sure what the difference between a PoC & prototype is /should be but both should be scrapped, right?

    But yeah, you can check my small post history for more information about the company
  • 0
    @wojtek322 Oh, I see..I assume you're saying the company isn't all that structured, based on your last sentence (combined with the entire thread) :)

    Regarding PoC vs Prototype:

    I couldn't have told you the difference off the cuff, I also felt they might be roughly the same. But after googling I'm reminded there's difference.

    A Prototype is often just a design/UX thing built without proper tech. You could build a clickable Powerpoint to test a new button design.

    A PoC is normally testing if a technical solution is suitable for production.

    So maybe we were not entirely correct @TheCommoner282

    https://codilime.com/blog/... says "a POC can take the form of a working part of the final product, developed with specific technology"
  • 1

    I always understood PoC as a proof that a certain technology meets the base requirements. It is never a production-ready asset, and should not be sold as one.

    A prototype is the next step after PoC. You incorporate frontends and similar... A prototype is something sales can work with. Do expect a prototype to be sold.

    If you just inherited this and it's not something you are familiar with, let your manager know.

    Explain that you'll need time to familiarize yourself with it, and have sales take the hit for selling shit before they should.

    If they don't understand this, all I can say is do a mic drop, walk away and never look back.
  • 0
    @CoreFusionX I’m looking at articles about ”prototype vs PoC” and I don’t see anyone claiming one or the other is the first step.

    They just say a prototype is UI and the PoC is tech

    Sometimes the UI prototype comes first and tou scrap the entire project because users hated the UI prototype so no use writing any code for a solution along those lines

  • 3


    The problem with this interpretation is that it is confused with an MVP.

    MVP require all the rigor of good software design. If this rigor is not applied, we build technical debt. And if this rigor is applied, there is no reason to call it anything but an MVP.

    So, a prototype or POC that isn't scrapped is a debt.

    And I firmly believe that everything else is a definition made up after the fact to justify a decision of not scrapping it.
  • 0

    Never claimed to hold the universal truth, just stated the way *I* understand it.

    In the end, it doesn't really matter as long as expectations are managed adequately, which was the problem from the beginning.
  • 1
    @CoreFusionX Gotcha, hope I don't sound like I'm trying to accuse. I kinda enjoy using DevRant as a way to go off on tangents and talk about interpretations.
  • 0
    @TheCommoner282 I'd agree. An MVP should be production quality.

    While a PoC and a prototype aren't.

    Regardless of the difference between those two - basically they are both not on the same tier as an MPV.

    (But I can kinda see how it would be hard to argue that a functioning PoC that proves something technical like "this package can render html" would necessarily have to be scrapped and rebuilt. But yeah, most likely if the functionality is there - the code quality isn't)
  • 1

    Absolutely not, all good 🙂
  • 0
    The initial project is rather small but the plan was never set in stone. Sure, we had some feature that it has to complete but how, why & how the UX has to be done was never answered. The previous employee worked on it and he finished his PoC or at least the main functionality.

    Now that person has left the company (Thanks to the hiatus in my company that was december / january. The DevOps team went from 10 to 4 people (see prior rant).).

    So the CTO said that he should work on a PoC instead of a MVP to probably have less preasure on that person that might have stayed. He was able to whitelist that feature on the store but a few smaller customers already found it (no idea why a PoC was pushed to the store) and they are now pestering the Support Team why it does not work well. So the CTO wants to polish up the project, rework UX & fix some bugs asap. The code lacks quite a bit of structure.

    So yeah, it's been a clusterfuck to say the least.

    Thanks for letting me rant ^^
  • 1
    @wojtek322 Appreciate the rant. This one was even better than the original post.

    What a nightmare - having a PoC published and then customers with zero of concept of code quality starting to use it and it devolving into "polish the turd" rather than building it properly.

    It's so hard to explain to customers that "I know it seems like some features work but that's just luck, it should be rewritten"

    But customers just go "but it kinda works. just fix these two tiny bugs in a few hours and ship it, stop being such a nerd"
  • 1
    The company created something similar back in the day before I started with pretty much the same name. That product was removed from the store due to store policy being changed and we did no longer comply.

    Said users used the old product and they had to reinstall it from the store and found the new one. The old & new one does have a similar name, similar enough functionality but not the exact same. The new one uses an other product that will be released in 2023.

    So yeah, now those customers have a product that is buggy and barely works without the other product that they don't even have.
Add Comment