[rbongers]

There's a great section in The Practice of Programming where the book describes how you should structure your code to not just be structured nicely now, but to plan for the future; to structure it so that changes are easy, organized, and don't break anything.

It's not exhaustive but it's a powerful general idea and I always like introducing developers to it for the first time.

[commonlisper]

I must say here that I agree this point but one should also exercise caution that they don't go overboard with abstractions while planning for future. Abstractions for future planning should be lean and flexible enough to be extensible.

[jewel]

Sometimes called YAGNI, or You Ain't Gonna Need It.

I've found that the right level of abstraction is the one that saves time and effort and duplication now, for the features you're currently shipping. If you're thinking about hypothetical new features that aren't even on the roadmap then you've gone too far.

As an example, say your embedded program needs to load images, and your standard library only supports raw BMP files. BMP images are going to work great for the time being, since the art team can supply them that way. By all means, add abstraction method around the library method called "load_image" so that you don't have to refactor a million places to replace that library. It'll give you a great place to add error handling, logging, etc.

Beyond a single method to add a point of attack, don't go beyond that and spend the time to add a JPEG and PNG library, don't add support for high bit-depth images, or for grayscale images, or CMYK images. Don't add an abstraction that'll someday be able to load the Nth frame from a video file. Perhaps throw an exception for unusual input, but beyond that don't waste your time.

In my experience having simple, direct code makes it easier to refactor in the future when the need arises. Having too much abstraction or future proofing gets in the way because the future inevitably will bring different changes than what you were expecting.

[ics]

Having not read the book OP mentioned, I would say it's important to emphasize that structure does not necessarily mean abstraction. Starting a new project is more like getting groceries and stocking the pantry than it is starting a stew and agonizing over which type of onions to toss in.

Good abstractions evolve naturally out of good structure.

[pca006132]

Just curious, have you ever seen a project that is structured nicely according to this criteria that you can share?