I think this strategy can work at all scales, from a line of code, method, class all the way up to a product, or even a business.
The trick is to balance "Just Good Enough" with "Not Good Enough (Yet)"
"Time, Quality, Cost - Pick 2" is not a static choice, it's a constant dynamic trade off!
I find that three things really help:
1. Maintain a backlog of structured tasks (ie. a tree)
Note down anything, however large or small, that should be done when you spot it. However always strive to work on whatever task pushes you fastest forward.
I use Jira and the Structure plugin to do this, as I'm up to about 2100 issues large and small on a solo project I've been working on for a few years.
Doing this means you relax / de-stress about worrying about the details: "Well I'll get to that if/when it becomes important".
2. Maintain a set of reasonable tests.
No need to be 100% coverage (until MVP?)
Make sure you have unit tests for complex methods and classes.
Make sure you have some system tests for the whole system "works" as you expect at the given point.
Add more tests as you add new or change existing functionality.
Doing this fights the feeling that your project cannot possibly work well enough or as expected: "Well it seems to be mostly working so far."
3. Don't be afraid to refactor at any scale.
Often you'll find that the fast progression means you've learned something that requires you to refactor some code you hastily wrote earlier. This is good! Do it!
Because of 2, you should not be too afraid to even attempt very large scale refactoring if that's required to progress (if not, add it to your list and move on). I am about to finish a huge six month refactoring (planned) because I made something "good enough" while I learned what I really needed to implement.
Doing this fights the feeling that your project is spiralling out of control into a tangled mess of rubber bands, duct tape and super glue. It restores sanity and pride: "Well I'm no longer embarassed to submit this to GitHub or code review."
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.
Great conversation starter and I heartily agree.
I think this strategy can work at all scales, from a line of code, method, class all the way up to a product, or even a business.
The trick is to balance "Just Good Enough" with "Not Good Enough (Yet)"
"Time, Quality, Cost - Pick 2" is not a static choice, it's a constant dynamic trade off!
I find that three things really help:
1. Maintain a backlog of structured tasks (ie. a tree)
Note down anything, however large or small, that should be done when you spot it. However always strive to work on whatever task pushes you fastest forward.
I use Jira and the Structure plugin to do this, as I'm up to about 2100 issues large and small on a solo project I've been working on for a few years.
Doing this means you relax / de-stress about worrying about the details: "Well I'll get to that if/when it becomes important".
2. Maintain a set of reasonable tests.
No need to be 100% coverage (until MVP?)
Make sure you have unit tests for complex methods and classes.
Make sure you have some system tests for the whole system "works" as you expect at the given point.
Add more tests as you add new or change existing functionality.
Doing this fights the feeling that your project cannot possibly work well enough or as expected: "Well it seems to be mostly working so far."
3. Don't be afraid to refactor at any scale.
Often you'll find that the fast progression means you've learned something that requires you to refactor some code you hastily wrote earlier. This is good! Do it!
Because of 2, you should not be too afraid to even attempt very large scale refactoring if that's required to progress (if not, add it to your list and move on). I am about to finish a huge six month refactoring (planned) because I made something "good enough" while I learned what I really needed to implement.
Doing this fights the feeling that your project is spiralling out of control into a tangled mess of rubber bands, duct tape and super glue. It restores sanity and pride: "Well I'm no longer embarassed to submit this to GitHub or code review."