I've got a problem.

I find really difficult to foresee the effect that my changes to the code will have over the whole application, either when I have to add new features or re-factor it. Very often it is not until testing time that I find out that I should have done things in a different way or that those changes produce an unexpected behavior.

I would like to know how you guys approach changes in the code, how you get to know how those changes will affect your current code, what tips or tricks work best for you, or any recommended readings about the matter.

Any help will be sincerely appreciated!

Thanks a lot guys

4 Answers 4


For me, the answer is getting to know your code base. When you jump in the middle of a project, there are lots of things already in place and you won't know how everything pieces together. The more you work, the more you know about the system and the easier it will be to foresee some of the effects a change might have on your system as a whole.

The other big things is ask other people. Talk to your coworkers about what you want to change and how you think they should be changed. They likely have a better understanding of sections of code you don't spend much time in. They will be able to give you a heads up on if your potential changes might effect their section of the code.

If you are the most senior person on the project, still talk to people. Even if you are the only one on the project, talking out a problem helps. You don't even need a real person to talk to.

Beyond that, take lots of notes. A brain dump on to a piece of paper from yesterday can be very helpful to remind yourself what you were thinking about last time you were working. You can also generate a UML diagram of your code base to see how everything is interconnected. Print that out, date it, and put it on your wall. The date is important because things are always changing and you need to know when it is time to make new notes or diagrams.

  • Hey, I am the one who knows the most about the project i have been working on, and still I find quite hard to picture the outcome that my changes will produce.I mean, I can figure out most of it, but there are always things missing, and I am in need of a better approach, a more methodical way of doing things, or perhaps a bigger brain... Commented Mar 25, 2011 at 19:15
  • @FranciscoSevillano: Edited to include suggestions for when you are the go to person for the project. Commented Mar 25, 2011 at 19:44
  • Thanks! I just read "The Pragmatic Programmer" and indeed I totally agree with rubberducking because it helps me a lot talking out when i get stuck at something, it is just that i don't want to look like a freak talking to an object haha. But sure I am gonna start talking more to people. Thanks for the answers. Commented Mar 26, 2011 at 14:55
  • 1
    For many projects it is at best impractical and prohibitively expensive to "get to know your codebase" when it is significantly large or complex. In those cases you cannot rely on the hope that your knowledge of the codebase is comprehensive enough that haven't broken anything. It does help to get consensus from people who may know different areas, but it is better by far to have a good functional test suite.
    – snakehiss
    Commented Mar 26, 2011 at 15:23

The key comment here is "Very often it is not until testing time that I find out "

What I do is write tests (especially unit tests) myself that check the code before I make the changes. The tests running correctly before and after show that I get the same behaviour.

EDIT after comment from @Robert Harvey - my idea is to give the concept that the OP can find more information.

Look for Test Driven Development for a more complete version of this and for which you can find many more detailed explanations.

  • 2
    Agree with your answer, but you are not describing TDD. TDD is a development methodology that focuses on design via unit tests; what you are describing is simply the practice of wrapping existing functionality in unit tests before modifying it, so that you can prove that you didn't break your original code. Commented Mar 25, 2011 at 16:04
  • Thanks a lot, if i had the privilege, i would vote up the answer Commented Mar 25, 2011 at 19:09
  • 1
    @FranciscoSevillano: You can do one better. If you think this is the best answer to your question, you can accept it. How does accepting an answer work? Commented Mar 25, 2011 at 19:21
  • I certainly agree with you about tests, but since i already use them, I find the answer provided by unholysampler more useful in my particular situation. But thanks! Commented Mar 26, 2011 at 14:54
  • Your comment re not until testing time that I find out implies that you are not using test early enough as testing time is not separate to development under TDD or similar
    – mmmmmm
    Commented Mar 26, 2011 at 14:58

This is, of course, a very common situation. Unexpected breakage is one of the chief indicators of degrading designs. Such breakage is due to couplings that tie modules together that you don't expect to interact with each other. Managing and minimizing those couplings are responsibilities that fall to every programmer. So, someone hasn't been doing their job!

There are quite a few principles that govern the dependencies between modules. One batch that I have a certain attachment to is called "SOLID". You can read about them in a paper called "Principles and Patterns" which you will find in the "Resources" section of cleancoder.com.

Even when you follow these principles assiduously, you will still sometimes experience unexpected breakage. And, of course, you don't find about this breakage until unit test time (if such a time exists). So the solution to that is to make unit test time come early. The earlier the better in fact.

That's why many of us use the discipline of test-driven-development (TDD) which you can find described in a paper entitled "The Bowling Game". This discipline moves unit test time to a very early time. It's so early, in fact, that it comes before you write any production code! When unit test time is that early, you find out about unexpected breakage very quickly.


This is exactly why we do ATDD at my work. Our Acceptance Tests are automated and run with every commit, and it's also expected every developers runs the entire suite before each of their commit. We use them like other shops use unit tests.

  • I didn't even know about the existance of ATDD, I am gonna take a look at it. Thanks! Commented Mar 26, 2011 at 14:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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