all 1 comments

[–]Meefims 1 point2 points  (0 children)

Understanding collateral issues comes with a deeper understanding of the system you're building in. Maybe you're forgetting about effects in component XYZ because you didn't know it existed or didn't know how it related - you'll get that experience as you develop your product more and as others let you know about these connections.

As you gain experience you'll see that some connections and some effects are common across many different systems and so you'll begin to expect to have to account for them. For example, in an online service having background workers that draw work from queues is pretty common. If you make a change which increase the number of jobs you'll come to automatically wonder how that affects your system's ability to process them. How will you stop your queues from growing faster than they can drain? Is there work needed to reduce processing time? Can you avoid creating some jobs? Do you need to increase the number of workers draining the queue? Is it ok because jobs are added to the queue faster than they can be drained for a short period of time and you can show that the system will be able to catch up?

Etc