2 spelt my name correctly
source | link

I agree with both Daniel HollirankeHollinrake and Ewan, that the first key point why your test-only-if-modify works well so far is:

I am the sole developer on my projects and I am responsible for everything

and that a likely second key point is:

you're producing nice clean code

I do not think TDD brings a huge productivity boost for sole programmers, and it may not hugely improve the quality of your code if you are already writing good clean code.

However, TDD will surely improve the quality of the code of poor / inexperienced / obsolete programmers, especially when the time comes to modify the code without breaking anything else. And even more so if the person modifying the code is not the same person that wrote the code originally or several months have passed in between.

In other words, I think TDD is both good practice to improve the quality of your code (as you acknowledge yourself) but also (and more important) a sort of hedge when you are working with average or mediocre programmers (say, from a different department or a different company) which is a far more common situation than working solo.

I agree with Daniel Holliranke and Ewan that the first key point why your test-only-if-modify works well so far is:

I am the sole developer on my projects and I am responsible for everything

and that a likely second key point is:

you're producing nice clean code

I do not think TDD brings a huge productivity boost for sole programmers, and it may not hugely improve the quality of your code if you are already writing good clean code.

However, TDD will surely improve the quality of the code of poor / inexperienced / obsolete programmers, especially when the time comes to modify the code without breaking anything else. And even more so if the person modifying the code is not the same person that wrote the code originally or several months have passed in between.

In other words, I think TDD is both good practice to improve the quality of your code (as you acknowledge yourself) but also (and more important) a sort of hedge when you are working with average or mediocre programmers (say, from a different department or a different company) which is a far more common situation than working solo.

I agree with both Daniel Hollinrake and Ewan, that the first key point why your test-only-if-modify works well so far is:

I am the sole developer on my projects and I am responsible for everything

and that a likely second key point is:

you're producing nice clean code

I do not think TDD brings a huge productivity boost for sole programmers, and it may not hugely improve the quality of your code if you are already writing good clean code.

However, TDD will surely improve the quality of the code of poor / inexperienced / obsolete programmers, especially when the time comes to modify the code without breaking anything else. And even more so if the person modifying the code is not the same person that wrote the code originally or several months have passed in between.

In other words, I think TDD is both good practice to improve the quality of your code (as you acknowledge yourself) but also (and more important) a sort of hedge when you are working with average or mediocre programmers (say, from a different department or a different company) which is a far more common situation than working solo.

1
source | link

I agree with Daniel Holliranke and Ewan that the first key point why your test-only-if-modify works well so far is:

I am the sole developer on my projects and I am responsible for everything

and that a likely second key point is:

you're producing nice clean code

I do not think TDD brings a huge productivity boost for sole programmers, and it may not hugely improve the quality of your code if you are already writing good clean code.

However, TDD will surely improve the quality of the code of poor / inexperienced / obsolete programmers, especially when the time comes to modify the code without breaking anything else. And even more so if the person modifying the code is not the same person that wrote the code originally or several months have passed in between.

In other words, I think TDD is both good practice to improve the quality of your code (as you acknowledge yourself) but also (and more important) a sort of hedge when you are working with average or mediocre programmers (say, from a different department or a different company) which is a far more common situation than working solo.