One thing I've seen produce terrible software on a consistent basis is the idea that every single problem needs to be solved up-front. I've sat in meetings where discussions were dominated by calling out every hypothetical use-case that "needs" to be accommodated, with little time dedicated to discussing the primary use-case. "Good intentions" win every time. How can you disagree that shipping something that accommodates every possible need and desire is bad? Management loves it! Now let's start discussing a wildly optimistic timeline!
Something I can be heard saying often at work: "Perfect is the enemy of good."
Take your feature and have a well defined minimum viable product. Implement it, write good tests and ship it. Catalogue feature ideas. Prioritize them. Implement features atomically, A/B test them. Customer behavior often defies expectations, so it's important to see how they're using and interacting with your stuff before committing to something. You lose all this when you start with a pile of assumptions and usually end up with a pile of shit.
I agree 100%! one thing that I'd like to add, is that these ideas of keeping the scope narrow and not building more than you have to are concepts that apply at different scales.
It applies on a macro scale when talking through and defining requirements with product management, but also on a micro scale in individual pieces of code. I often comment in code reviews: why all this extra code to handle a special case? Is it something we need to support? Do we know that this is correct way to handle it, or are we just guessing?This can sometimes result in deleting code even though it was already implemented, and our code base is better off because od it...
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
One thing I've seen produce terrible software on a consistent basis is the idea that every single problem needs to be solved up-front. I've sat in meetings where discussions were dominated by calling out every hypothetical use-case that "needs" to be accommodated, with little time dedicated to discussing the primary use-case. "Good intentions" win every time. How can you disagree that shipping something that accommodates every possible need and desire is bad? Management loves it! Now let's start discussing a wildly optimistic timeline!
Something I can be heard saying often at work: "Perfect is the enemy of good."
Take your feature and have a well defined minimum viable product. Implement it, write good tests and ship it. Catalogue feature ideas. Prioritize them. Implement features atomically, A/B test them. Customer behavior often defies expectations, so it's important to see how they're using and interacting with your stuff before committing to something. You lose all this when you start with a pile of assumptions and usually end up with a pile of shit.
I agree 100%! one thing that I'd like to add, is that these ideas of keeping the scope narrow and not building more than you have to are concepts that apply at different scales.
It applies on a macro scale when talking through and defining requirements with product management, but also on a micro scale in individual pieces of code. I often comment in code reviews: why all this extra code to handle a special case? Is it something we need to support? Do we know that this is correct way to handle it, or are we just guessing?This can sometimes result in deleting code even though it was already implemented, and our code base is better off because od it...