How to build large applications

As programmers, we like to believe we are smart people, so it's hard to admit that something is too big and complex to even think about all at once. But for a large-scale software project it's true, and the sooner you acknowledge your finite brain capacity and start coming up with ways to simplify the problem, the better off you'll be.

The other main thing to realise is that you will spend most of your time changing existing code. Building the initial codebase is just the honeymoon period -- you need to design your code with the idea in mind that, 6 months later you will be sitting in front of it trying to solve some problem without a clue how this particular module works, even though you wrote it yourself.

So, what can we do?

Minimise coupling between unrelated parts of your code. Code is going to change over time in ways you can't anticipate -- there will be showstopper problems integrating with unfamiliar products, requirements changes -- and those will cause ripple-on changes. If you have established stable interfaces and coded to them, you can make any changes you need in the implementation without those changes affecting code that uses the interface. You need to spend time and effort developing interfaces that will stand the test of time -- if an interface needs to change too, you're back to square one.

Establish automated tests that you can use for regression testing. Yes, it's a lot of work up front. But it will pay off in the future when you can make a change, run the tests, and establish that it still works without that anxious feeling of wondering if everything will fall over if you commit your latest change to source control.

Lay off the tricky stuff. Every now and then I see some clever C++ template trick and think, "Wow! That's just what my code needs!" But the truth is, the decrease in how readable and readily understandable the code becomes is often simply not worth the increased genericity. If you're someone like me whose natural inclination is to try to solve every problem in as general a manner as possible, you need to learn to restrain it until you actually come across the need for that general solution. If that need arises, you might have to rewrite some code -- it's no big deal.

Borrowed from tvanfosson:

Start with a small application and say yes everytime someone wants a new feature added.