I need more time. The more I gain experience in this industry, the more I realize, time is everything. Nothing else matters. Too often we are worried about adding bells and whistles, marketable features, things to put on the back of the box, and that are ultimately irrelevant.
Do you want to build the best 3d engine out there? Then forget about VSM, SSAO, DOF, SH, CSM, HDR and similar acronyms, none of those should be part of the features of it.
Learn from cameras (I feel like I made this analogy far too many times). What's the difference between a professional camera, and a prosumer or consumer digicam? Let's consider the Canon 7d as a consumer one, the 5d Mark II as a prosumer, and the 1D Mark IV as the professional. The price difference between those is substantial. What would you expect to be the most striking difference between those? The image quality?
Well if so, you would be wrong. In fact, for some uses, one could argue that the 7d even outperforms the other two. Even in the numbers, the 1D manages to be the one with the least megapixels across the three. Why the 1D is so expensive? Probably surprisingly, it's because it's fast. It can shoot 10 fps versus the 3.9 of the 5DMk2, and it flash syncs up to 1/300 of a second, versus the (nominal) 1/200 of the closest rival. It's a camera made for people that can't miss the shot, and that have to work fast, focus fast, and work with flashes against the sun. Photojournalists.
What's the main difference between the 5D and the 7D then? Well, to me the best feature of the 5D is its big viewfinder. Let's go even cheaper, the 550D, that is the most recent breed of the cheapest digital reflex line Canon has. What's the big deal between that one, and its bigger brother? To me is that the more expensive one, has an extra dial on the back, it's faster and easier to change its settings. Ergonomy again.
And so on really, you can go back and forth, compare cheap compacts with professional film cameras. It's not about the number of fancy features. It's about being able to do your job at the best. Quality, durability, ergonomy, speed.
You need to be able to focus on your job. If you're able to iterate fast, if you have the right utilities and services in your framework, then your 3d engine can be as thin as being directly the native API. It doesn't really matter. You can observe that the faster you can change, tinker, experiment, write code, the less you even need anything else.
For example, it's surely handy to have a tool that gathers metrics and displays performance graphs, to be able to understand what's going wrong in your rendering. I love PIX. But would you need it less, if you could just change your rendering on the fly?
What about a debugger? It's a fundamental, fundamental tool, and in no way I'm saying we shouldn't leverage on all kinds of tools... But when you're coding in a scripting language, and you can change things while they're running... Well, then, does using prints to debug code look so horrible?
All that is true especially for the expert. The more experienced you are, the more you don't mind the learning curve. You don't need canned components and automatisms. You don't need babysitting.
A tourist snapping casual pictures may still find handy to have a camera that's capable of putting fancy frames on a sepia-toned image, recognize faces while focusing, and automatically firing the flash when it thinks its necessary. For a professional, being unable to tinker, and having all those useless buttons in the way of his creative thinking, is an hassle.
That said, it does not mean that engineering a compact, consumer digital camera is easy or should not be done. There's a market for that. And we have to cater that market too. Not many (successful) companies are made only by experts in code-crunching. And indeed, in many cases we code to make others work easier, not our own. That might be the right choice sometimes but we should always try to achieve that at no cost for the programmers.
I've already said this a thousands of times, but building a complex data driven tool to make a given workflow easier, while complicating the overall structure of your code, it's a bad choice. Having a thin, fast, robust, high quality infrastructure, with layers on top to ease the most common tasks, is far bettter.