17 year-old self-taught web developer proficient in Javascript and Go, interested in testing, test driven development, agile, code craftsmanship, Docker, microservices
Sadly, we can't apply TDD to every single project we work on, primarily due to time constraints.
Is that so?
If we spend the time to focus on TDD, our product may not make it to market in time to beat the competition.
This is another subject Bob Martin touches on. The myth (according to Bob) that being 'first to market' is of the utmost importance. "Was Facebook first to market?" he asks. And, of course, neither was Google. But you don't see people walking around using 'Yahoo' as a synonym for internet search or even mentioning MySpace.
It's really a misunderstanding of the Lean startup philosophy, which says that 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.
The word viable is also important here. A minimum viable product (in software), I would argue is not a mess of code that barely works, but a well-done piece of software that is perhaps missing some of the features that would be necessary to call it 'done' or 'ready' from a business perspective.
The only way to go fast is to go well - Bob Martin
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.
Is that so?
This is another subject Bob Martin touches on. The myth (according to Bob) that being 'first to market' is of the utmost importance. "Was Facebook first to market?" he asks. And, of course, neither was Google. But you don't see people walking around using 'Yahoo' as a synonym for internet search or even mentioning MySpace.
It's really a misunderstanding of the Lean startup philosophy, which says that 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.
The word viable is also important here. A minimum viable product (in software), I would argue is not a mess of code that barely works, but a well-done piece of software that is perhaps missing some of the features that would be necessary to call it 'done' or 'ready' from a business perspective.
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 ;)