Steve Jones - SSC Editor (1/24/2013)
rharderwijk (1/24/2013)
I partially agree.Yes, developers should be develop software that can scale up and down as needed, but they still have to worry about the underlying 'hardware'. I put that between quotes, as using a cloud service does not mean you can just write any code. Suboptimal code can mean buying new bigger hardware, or purchasing more compute cycles, and both can be quite expensive.
I'm not sure that's worrying about the hardware. I think that's more writing better code, that efficiently uses whatever it's running on.
I'm going to have to agree with rharderwijk. As an analogy, let's translate:
'Development shouldn't be concerned about the size or care of physical machines'
to
'Development shouldn't be concerned about the size or care of databases'
and see how that feels. Using, say, LINQ with all defaults and letting the software auto-build your table structures is essentially the same as letting the "service" do the same kinds of things.
First, it depends very much on what type of development, what industry, what resources are available, prioritization of requirements, performance targets now and in the future, product/project total lifespan, etc. If the developer/developer's employer doesn't care, then no, physical hardware, database engine, etc. may not matter much - this is the "take the defaults" approach.
For some kinds of development, it really does matter - can you use AES-NI instructions or not? Do you have X amount of storage available? Are there different kinds of storage, with different speeds? Are there added costs to certain things?
Creating an app that stores a handful of recipes for one user is not the same as a realtime control system for a pacemaker, which in turn is not the same as an enterprise HR platform (where "enterprise" is defined as 300,000 current employees).
Further, knowing about hardware allows you to have the option of choosing tradeoffs yourself - what's the native word size, and are there instructions that are much faster/slower, for instance. Not knowing about hardware means you cannot control those tradeoffs... and you may not even be aware of their existence.