4 ms·
I've done this a number of times, it seems to work quite well, and I don't think of it as malicious. A "softer" way of handling this is to assign the prototypi
by btbuildem 3y ago
I've done this a number of times, it seems to work quite well, and I don't think of it as malicious.
A "softer" way of handling this is to assign the prototyping / PoC development to a different team. The tribality / process worship / power dynamics between teams virtually guarantee that no code will be reused between the PoC and prod.
- auggierose 3y agoYou also lose knowledge gained through building the PoC.
- btbuildem 3y agoI think that depends on why you built the PoC in the first place. Looking through the comments here I get the impression most people are looking at it as "is this technically feasible", while in my experience a PoC / prototype is usually made for business / usability validation ("is this valuable / will people use it").
- delecti 3y agoDo you have experience with that second approach actually working? I'm currently stuck maintaining and upgrading multiple microservices that are a total mess because nobody understood how they were built, and we just had to cope with their weird spaghetti.
- btbuildem 3y agoThe way I've seen it work is that the PoC defines the features, then the dev team breaks this down and implements it any way they see fit. It's up to the teams to maintain their best practices and interoperability of the different solutions. Whomever built the PoC doesn't face any of these constraints, their focus is to help finalize the functional spec.