4 ms·

You want agile and test driven development. Once you have a working prototype you collect user stories to modify the prototype. Clean up your code and move it

You want agile and test driven development. Once you have a working prototype you collect user stories to modify the prototype. Clean up your code and move it towards solid principals using TDD.

mattdeboard 5y ago
With regard to TDD I have been recommending many videos from this channel lately, and this one seems apt https://youtu.be/yfP_v6qCdcs https://youtu.be/yfP_v6qCdcs OP I agree with malthuswaswrong. About TDD, not malthus, I do not know who that is.
rlayton2 5y ago
Thanks. I do aim for high test coverage, but still not driven by the tests.
- sam_lowry_ 5y ago
  Actually... There are two kinds of tests: tests that encode institutional knowledge and tests to make sure things work as intended. In your case, you need only the later.
lifeplusplus 5y ago
TDD, Agile and Continuous Development all of them are failed ideas and best kept to academic musings. TDD - write test before writing code. Only problem is coding is as much as discovery as implementation. You almost never construct the right structure, functionality and system the first time. It's only after you have played around that you start to understand the system and close in on something concrete. Writing tests in beginning would require you to visualize all the steps, instead of try and see approach. And you can visualize only so much. So TDD will prevent you from approaching to good solution and cause lot of wasted work. Tests should be testing integration or if unit tests then after code has been finalized. Agile - this literally serves no purpose. If you are done with task you can move onto next task. Scoping some set of tasks to some duration of time is pointless exercise as you have no idea how much time tasks are gonna take. Estimates are notoriously bad. Quality suffers, tech debt multiplies and developers become impassionate who have no agency over their work. Agile creates these crude deadlines which means you add this artificial cool down and warm up time. If you finish early you can't start looking into something next, as you don't who will get the ticket. If you are bit late now next sprint is even more loaded. Continuous Development - going back to 1st point, code is experimenting if you are pushing all your changes live 24/7 into master branch then you're going to end up in situation where the old code which you have decided to refactor/discard is now being used by someone else and you need to touch code that you had nothing to do with and have no context about either. If you had pushed only finalized changes then if others were to use your code they'd know it's stable. As for merge conflicts, only difference between CD and branching method is that in CD you just trade solving merge conflict at the end to solving it every day. Git history becomes so convoluted that you don't even know how to undo it because 3 peoples have been working in same file and pushing every few hours.
- UK-Al05 5y ago
  Sounds like your tests are to detail orientated. Tests should test a specific business goal. You know what the goal is before you write any tests right? Otherwise why are you writing any code?
  - lifeplusplus 5y ago
    I don't know what world you live in, but business goals are never "test if a function returns an array of users with their comments sorted by likes". Business goals are more like user should be able to view comments on their profile. Which several layers of abstraction away from what coding is.

You want agile and test driven development. Once you have a working prototype you collect user stories to modify the prototype. Clean up your code and move it towards solid principals using TDD.

mattdeboard 5y ago

With regard to TDD I have been recommending many videos from this channel lately, and this one seems apt https://youtu.be/yfP_v6qCdcs https://youtu.be/yfP_v6qCdcs OP I agree with malthuswaswrong. About TDD, not malthus, I do not know who that is.

rlayton2 5y ago

Thanks. I do aim for high test coverage, but still not driven by the tests.

sam_lowry_ 5y ago
Actually... There are two kinds of tests: tests that encode institutional knowledge and tests to make sure things work as intended. In your case, you need only the later.

lifeplusplus 5y ago

TDD, Agile and Continuous Development all of them are failed ideas and best kept to academic musings. TDD - write test before writing code. Only problem is coding is as much as discovery as implementation. You almost never construct the right structure, functionality and system the first time. It's only after you have played around that you start to understand the system and close in on something concrete. Writing tests in beginning would require you to visualize all the steps, instead of try and see approach. And you can visualize only so much. So TDD will prevent you from approaching to good solution and cause lot of wasted work. Tests should be testing integration or if unit tests then after code has been finalized. Agile - this literally serves no purpose. If you are done with task you can move onto next task. Scoping some set of tasks to some duration of time is pointless exercise as you have no idea how much time tasks are gonna take. Estimates are notoriously bad. Quality suffers, tech debt multiplies and developers become impassionate who have no agency over their work. Agile creates these crude deadlines which means you add this artificial cool down and warm up time. If you finish early you can't start looking into something next, as you don't who will get the ticket. If you are bit late now next sprint is even more loaded. Continuous Development - going back to 1st point, code is experimenting if you are pushing all your changes live 24/7 into master branch then you're going to end up in situation where the old code which you have decided to refactor/discard is now being used by someone else and you need to touch code that you had nothing to do with and have no context about either. If you had pushed only finalized changes then if others were to use your code they'd know it's stable. As for merge conflicts, only difference between CD and branching method is that in CD you just trade solving merge conflict at the end to solving it every day. Git history becomes so convoluted that you don't even know how to undo it because 3 peoples have been working in same file and pushing every few hours.

UK-Al05 5y ago
Sounds like your tests are to detail orientated. Tests should test a specific business goal. You know what the goal is before you write any tests right? Otherwise why are you writing any code?
- lifeplusplus 5y ago
  I don't know what world you live in, but business goals are never "test if a function returns an array of users with their comments sorted by likes". Business goals are more like user should be able to view comments on their profile. Which several layers of abstraction away from what coding is.