I am so relieve that this is not a TDD cult advertising post..
I worked in startups in the last 8+ years, all we did was to deliver fast, cutting corners and do technical debt.
There are cases where these things are ok, you said "pay the price on the longrun". When you develop mostly prototypes, and MVP's and then you patch it up, and then you try something totally different and then you do A/B tests ... that future mostly never comes. I found out other situations (I will write soon a blog post) where if you plan ahead and do unit tests you actually lose time and it doesn't worth it.
Eventually some projects survive, and then the technical debt has it's revenge, but even then you would be amazed how ingenious managers/producers can be to avoid fixing it 😆.
Also there are many cases where the Code Quality can be worst but the Product Quality remains untouched (from the user point of view).
Anyway I agree with your article, but the real world it's harsh and I have found that only a few product owners/producers/managers understand the quality of a good technical team and product, most of my peers haven't found any yet 😟.
Example: they will allow you now 10% of the time to save 60% of the future time to do things better.
I am a Software Dev girl who loves Uncle Bob, is drawn to the human side of software development and clean coded applications, and enjoys acting as a liaison between the business and tech.
I'm not advertising TDD. I just embrace clean code overall and teach my juniors the power of maintainable code ;)
And sometimes it's hard to implement TDD. Especially in legacy applications that weren't meant to be test driven ;)
And to have a good product you need a good team. A good team made of average developers can do more than the bad team made of superstars (I wrote about teamwork on my blog recently here: jumpstart.blog/2017/08/05/software... and here: jumpstart.blog/2017/10/05/a-bunch-...). And I know that word is harsh, but I keep fighting ;)
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.
I am so relieve that this is not a TDD cult advertising post..
I worked in startups in the last 8+ years, all we did was to deliver fast, cutting corners and do technical debt.
There are cases where these things are ok, you said "pay the price on the longrun". When you develop mostly prototypes, and MVP's and then you patch it up, and then you try something totally different and then you do A/B tests ... that future mostly never comes. I found out other situations (I will write soon a blog post) where if you plan ahead and do unit tests you actually lose time and it doesn't worth it.
Eventually some projects survive, and then the technical debt has it's revenge, but even then you would be amazed how ingenious managers/producers can be to avoid fixing it 😆.
Speaking of, I just wrote an article on how I managed to fix technical debt while continue delivering new features.
Also there are many cases where the Code Quality can be worst but the Product Quality remains untouched (from the user point of view).
Anyway I agree with your article, but the real world it's harsh and I have found that only a few product owners/producers/managers understand the quality of a good technical team and product, most of my peers haven't found any yet 😟.
Example: they will allow you now 10% of the time to save 60% of the future time to do things better.
Thanks!
I'm not advertising TDD. I just embrace clean code overall and teach my juniors the power of maintainable code ;)
And sometimes it's hard to implement TDD. Especially in legacy applications that weren't meant to be test driven ;)
And to have a good product you need a good team. A good team made of average developers can do more than the bad team made of superstars (I wrote about teamwork on my blog recently here: jumpstart.blog/2017/08/05/software... and here: jumpstart.blog/2017/10/05/a-bunch-...). And I know that word is harsh, but I keep fighting ;)