4 ms·

Regardless of the platform, for any application with a non-trivial amount of complexity, iterative development is the best approach. I don't understand how anyo

Regardless of the platform, for any application with a non-trivial amount of complexity, iterative development is the best approach. I don't understand how anyone could "write it all down, read through the code a few times and test" and not produce a buggier application that doesn't meet most expectations. It does help to do some initial design work, create abstractions, loose coupling, etc. Iterative development does not mean jumping into coding without a high level plan on how to create the application pieces and how things would work (or do what's called as "cowboy coding"). With the amount of complexity involved in developing applications, considering the architecture, design, interactions between application components, error handling, different classes of platform APIs, UI, UX, state management, concurrency, hardware configurations to support, and many other things, I doubt if any human could really keep all that in one's head and really work through all the possible ways that assumptions during coding would get beaten, when compared to a real execution of the application and using that practical feedback in changing, fixing and improving things.

z3t4 10y ago
I think everyone prefer iterative development. I love web dev because I can get instant gratifications (no compile time). I think it's mostly because I'm lazy though. I also manage a legacy system where I make hot fixes in production, where setting up a testing environment is not practical. While I do introduce bugs, they are far less because I'm forced to plan carefully, and know how everything works. One problem with development is that it's hard to predict what will happen, and thus it gets difficult to make estimates. But if you carefully analyze and plan, things will go much smoother.
spdionis 10y ago
You are confusing scopes here. The parent almost surely meant those approaches applied to a single task (meaning a few hours to a day of work), not to building an application.
- newscracker 10y ago
  Being pedantic - the parent was commenting on the article, not on a comment here dealing with a single task or one small piece worth a day's work. I see no indication on how you could make a statement saying "...almost surely meant..." Based on the information available, either of our premises could be true.
  - z3t4 10y ago
    The authors main complain was that it takes two minutes to start the emulator. And I agree that it is a Pita. But as a mental exercise or fun experience, you should 1) Picture it in your head 2) Make a plan 3) Write it down 4) Read through it and fix errors 5) Test it on the emulator. You could start with a small ten minute fix, then work your way up. The feeling when it compiles and just works on the first try is amazing.

z3t4 10y ago

I think everyone prefer iterative development. I love web dev because I can get instant gratifications (no compile time). I think it's mostly because I'm lazy though. I also manage a legacy system where I make hot fixes in production, where setting up a testing environment is not practical. While I do introduce bugs, they are far less because I'm forced to plan carefully, and know how everything works. One problem with development is that it's hard to predict what will happen, and thus it gets difficult to make estimates. But if you carefully analyze and plan, things will go much smoother.

spdionis 10y ago

You are confusing scopes here. The parent almost surely meant those approaches applied to a single task (meaning a few hours to a day of work), not to building an application.

newscracker 10y ago
Being pedantic - the parent was commenting on the article, not on a comment here dealing with a single task or one small piece worth a day's work. I see no indication on how you could make a statement saying "...almost surely meant..." Based on the information available, either of our premises could be true.
- z3t4 10y ago
  The authors main complain was that it takes two minutes to start the emulator. And I agree that it is a Pita. But as a mental exercise or fun experience, you should 1) Picture it in your head 2) Make a plan 3) Write it down 4) Read through it and fix errors 5) Test it on the emulator. You could start with a small ten minute fix, then work your way up. The feeling when it compiles and just works on the first try is amazing.