I am a programmer with a number of years of experience. I realized I got a certain habit. I'm not sure whether it's really a bad habit or not.

I get a list of tasks to perform for a solution, even small small tasks, for example,

  1. Change resources of this user control
  2. Change size of another one
  3. Add some HTML and coding on another user control

All of these tasks are small. I mean they can be done within 10 minutes, but I got a bad habit of making small changes and then test them again and again in a web browser. Is this a good practice?

Or should I perform them all at once and then test them together?

If it is really a bad habit then how do I rectify it, since it feels like wasting time testing small changes over and over?


6 Answers 6

  • It's a good practice.
  • You are following the scientific method.
  • If you change several things before any testing, then the testing of each will be more difficult, and perhaps not reliable, since preconditions will be more difficult to prepare and the different changes can interact with each other in manners you didn't foresee.
  • The time you feel you are "wasting" now, you will regain later in the intregration, testing and maintaining stages.
  • Way to go.
  • 9
    AFAIK, for UI programming, it is not only good practice, it is the only acceptable practice. That's why software companies created so many What you see is what you get tools for developers working with HTML, CSS, Widget, etc...
    – InformedA
    Commented Aug 2, 2014 at 10:13

Making lots of little changes and testing each one is not a bad thing. It allows you to see the effect of each change, and then when one change causes a problem, it's much easier to know which change caused issues - the most recent one!

If you have a task list with 10 items, and you do all of them at once and then test the page and then notice that the page looks wrong, it might be harder to know which change broke the page.

Of course, it's possible to take this approach to the extreme. Finding balance is the key, and that comes with gaining a better understanding of what you're changing and how the changes might affect each other.


Your question has two parts:

  1. should I perform them all once and then test them together ?

    I assume you are using a VCS.
    And to track, what tasks were done it makes sense to distribute the list of tasks to a list of commits: one task, one commit.

    That makes it easy to manage different versions of the current code base; you could revert to a previous state, cherry-pick the changes you want to enter the main trunk, etc.

    The answer is cleary:

    No, make changes only one by one - one task one commit.

  2. but I got a bad habit of making small small changes and then test them again and again in web browser, is this a good practice ?

    It is a good practice to test code/UI whatever, but it is nonsense to do it over and over again in the browser. There are tools, to do that automatically for you (Selenium, PhantomJS/Casper, ZombieJS)

    The answer for this case is:

    Yes, it is good practice to test software more than once, but use automation

  • 2
    +1, but I disagree with using automation. When I'm developing a new feature, I test both manually and with automation. The manual tests let me be very certain that things are behaving the way I expect them to. It's possible to write an automated test incorrectly, watch it pass and think all is good, then test manually and see that something is amiss.
    – Kevin
    Commented Aug 2, 2014 at 16:10
  • One task one commit sure has the potential to make the VCS log an incomprehensible mess for various definitions of "single task" Commented Aug 4, 2014 at 21:14
  • depends how fine granular you define task ;) or if you wish: one "ticket" one commit/branch. Using git makes this easy Commented Aug 4, 2014 at 21:57
  • 1
    To expand on what Kevin said I believe that if you're adding a new feature that's front end you always have to manually check it(I've yet to find an equiv to TTD for front end work), but you also want your automation suite to help ensure you've not broken existing features.
    – scragar
    Commented Aug 5, 2014 at 9:55
  • @scragar yes. Automation is for regressiontesting. Commented Aug 5, 2014 at 12:00

For any habit a developer has, there are 2 main questions:

  1. How does it influence the quality of the code you make?
  2. How does it influence your productivity?

If the answer to both is "It makes it better", screw habit, teach it to others!
If the answer to one is "Better" and the other "Worse" - it's a style and you have to be conscious about it. It's not always applicable, and you may need to make an effort to suppress it every now and then.
If the answer to both is "Negative" - you've got a serious problem.

Of course for the first 2 cases you should also think about "Can the positive effect be somehow automated or institutionalized?". Maybe it's better to write a test than try out different browsers every time? (Note, I know that it's not that easy to test proper layout in web development, I'm not saying this is always possible or worth the time).

In this particular case, it seems to me that the quality is increased, productivity may be decreased. For small changes it's likely kinda bad (especially if the changes are interrelated), for larger - it's kinda good. As long as you test the end result as well (avoid the "each module was tested and works, so the entire thing works as well, no need to test it!").

Hence - unless 90% of your work day is doing really small changes - it's a perfectly fine habit to have. If your work day is like that, then maybe you might want to review your work style (or work place).


This depends on the domain. For laying out a web page it will work fine and you can get immediate feedback (you can even do it in the browser directly!). Similarly it would work well for anything that doesn't require a long time to initialize. This is preferred since it keeps your mental workload low and reduces the possibility of mistakes.

However, for really big projects where you have to compile the code and the time taken is non-trivial (several minutes), this can result in a lot of down time so you often have to resort to:

  • "parallelizing" your work flow (e.g. work on multiple builds simultaneously), or
  • do as many things as possible in one go, or
  • create a small independent part to work on and integrate into the larger project later.

(There are probably other ways too.)

  • +1 for doing it in the browser directly. I'll often make CSS tweaks right in the browser as a throw away prototype of the real work I'm about to do.
    – RubberDuck
    Commented Mar 27, 2016 at 11:42

As others have stated, this is definitely not a bad habit. I generally prefer to make only a few modifications at once. The only exception is if I have a large list of changes that don't all affect one another (e.g. changes to minor styles or copy, changes on different pages, etc). If you're modifying layouts, stick to making changes one at a time so you can verify everything is 100% in all supported browsers before moving onto the next issue.

Not the answer you're looking for? Browse other questions tagged or ask your own question.