3 ms·

> But if you just started a new project and you are still in a constant state of change ... I don't understand what the rush is all the time. Sit down with a

> But if you just started a new project and you are still in a constant state of change ... I don't understand what the rush is all the time. Sit down with a pad/pen or whiteboard and think about the design. the last mobile project i started, I sat down and wireframed on paper. Tests came naturally and didn't fight the design.

c2352466 10y ago
https://xkcd.com/1445/ https://xkcd.com/1445/
yoodenvranx 10y ago
I think it depends on what type of software you are doing. If it is "just" a mobile project then you can pre-plan most of it. But I come from a more scientific background and most of the stuff I did back at university was pretty much impossible to plan because you did not actually know how you would solve your current problem. Usually you would try several approaches until you find the one that works. In such a situation tests are hard to use because they reduce your flexibility.
- mbrock 10y ago
  You are completely allowed to throw out your tests if you are doing this kind of exploratory programming. Then, tests are simply your hypotheses.
  - maxxxxx 10y ago
    Yes, that's one thing people often forget. It's OK to delete tests that are obsolete.
- blueprint 10y ago
  How do you verify that the lack of understanding of the form of the solution was due to the problem domain (scientific) and not your lack of exactness of confirmation and ability to see what is in the problem due to not actually knowing?
- jsymolon 10y ago
  > ... most of the stuff I did back at university ... I would place that kind of programming in a different class. Small, "one-shot" problems probably don't need a lot of planning. That's the experimental / exploratory class of problems where you're not interested in the correctness of the process but results. AKA risk reduction. For the other classes where there is "The Process" of validation, testing and approvals, a little planning up front saves some churn on the back end. I have the same concern about iterative development. Seems like a lot of teams jump right into a coding sprint/iteration/cycle w/o a plan.
maxxxxx 10y ago
I work in an enterprise environment and with all the stakeholders involved it's impossible to get a decent design upfront. But I still think you can test a lot of things even while change happens. Just avoid getting too detailed.

c2352466 10y ago

https://xkcd.com/1445/ https://xkcd.com/1445/

yoodenvranx 10y ago

I think it depends on what type of software you are doing. If it is "just" a mobile project then you can pre-plan most of it. But I come from a more scientific background and most of the stuff I did back at university was pretty much impossible to plan because you did not actually know how you would solve your current problem. Usually you would try several approaches until you find the one that works. In such a situation tests are hard to use because they reduce your flexibility.

mbrock 10y ago
You are completely allowed to throw out your tests if you are doing this kind of exploratory programming. Then, tests are simply your hypotheses.
- maxxxxx 10y ago
  Yes, that's one thing people often forget. It's OK to delete tests that are obsolete.
blueprint 10y ago
How do you verify that the lack of understanding of the form of the solution was due to the problem domain (scientific) and not your lack of exactness of confirmation and ability to see what is in the problem due to not actually knowing?
jsymolon 10y ago
> ... most of the stuff I did back at university ... I would place that kind of programming in a different class. Small, "one-shot" problems probably don't need a lot of planning. That's the experimental / exploratory class of problems where you're not interested in the correctness of the process but results. AKA risk reduction. For the other classes where there is "The Process" of validation, testing and approvals, a little planning up front saves some churn on the back end. I have the same concern about iterative development. Seems like a lot of teams jump right into a coding sprint/iteration/cycle w/o a plan.

maxxxxx 10y ago

I work in an enterprise environment and with all the stakeholders involved it's impossible to get a decent design upfront. But I still think you can test a lot of things even while change happens. Just avoid getting too detailed.