4 ms·

I can't agree with this more. One company I worked at did proof-of-concept sales to enterprise customers, and as engineers we supported the sales team by adding

I can't agree with this more. One company I worked at did proof-of-concept sales to enterprise customers, and as engineers we supported the sales team by adding additional features the customer may demand before making the sell. Sometimes the sale does not go through, and the implemented feature is of no use to the other enterprise customers we have. It's still there in the codebase as technical debt, and it's difficult to delete since there's no clear boundaries between the useless code and the more frequently used paths. As lines of code increase development velocity decreases. Using a strangler pattern may make this process less painful.

xkcd-sucks 8y ago
>and the implemented feature is of no use to the other enterprise customers we have >As lines of code increase development velocity decreases. How do you make this clear to the CEO......................
bobwaycott 8y ago
Would this be mitigated by setting up custom demos with quickly mocked features on separate branches that can be easily spun up and deleted? I’ve helped clients with similar needs, and it’s so much easier to make a rough working feature branch for something that helps the sales process for a large customer, temporarily run it on a subdomain for demo purposes, and then get rid of it. It still hangs around for a time in a branch, but it only gets merged in when there’s a definitive need for it to be part of the live product. Edit: This doesn’t solve the problem of wasted team effort, obviously. This kind of effort ought to only be taken when you can’t get a potential customer to agree to signing a contract before doing some work on a new feature. But that can be difficult to do sometimes. Marrying sales and development is its own challenge.