The myth (according to Bob) that being 'first to market' is of the utmost importance.
You have good insight. I agree with you, and Uncle Bob, that "first to market" should not be a company's primary motivation.
startups should quickly produce a minimum viable product and rely heavily on consumer feedback so that they can quickly adapt. This ability to quickly adapt is key, and is actually enhanced by TDD.
100% agree. If I ever create a new product, I plan to approach it with this in mind. Prototypes and minimum viable products have their benefits, but they should never be considered the "end goal". They should always be a single step on the journey towards a well-maintained, easily-extensible, clean and functional system. It sounds like you understand this very well.
I think your interpretation of TDD theory is spot on. I'll end with a single piece of advice, for you and anyone else reading.
As developers, we love to think about the "ideal scenario". Full test coverage, beautifully clean interfaces, proper documentation, etc. There's a reason we love these things - it's because they're proven to be effective, when they exist. Unfortunately, we rarely have time to implement all of our ideals.
When we're faced with deadlines (whether it's from management, another team, ourselves, or other circumstances) we have to pick and choose which best practices we want to follow, and we even have to limit how much time we spend researching all the options. In these scenarios, it's important to understand what each practice brings to the table, and which ones will be the most effective for our project.
And if we are forced to ignore best practices too often, it's important to remember that we can always find another job ;)
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.
You have good insight. I agree with you, and Uncle Bob, that "first to market" should not be a company's primary motivation.
100% agree. If I ever create a new product, I plan to approach it with this in mind. Prototypes and minimum viable products have their benefits, but they should never be considered the "end goal". They should always be a single step on the journey towards a well-maintained, easily-extensible, clean and functional system. It sounds like you understand this very well.
I think your interpretation of TDD theory is spot on. I'll end with a single piece of advice, for you and anyone else reading.
As developers, we love to think about the "ideal scenario". Full test coverage, beautifully clean interfaces, proper documentation, etc. There's a reason we love these things - it's because they're proven to be effective, when they exist. Unfortunately, we rarely have time to implement all of our ideals.
When we're faced with deadlines (whether it's from management, another team, ourselves, or other circumstances) we have to pick and choose which best practices we want to follow, and we even have to limit how much time we spend researching all the options. In these scenarios, it's important to understand what each practice brings to the table, and which ones will be the most effective for our project.
And if we are forced to ignore best practices too often, it's important to remember that we can always find another job ;)