For as long as I can remember, if you needed a transactional and scalable data store, then you would buy a database such as SQL Server and implement your data store on top of that platform. There were already databases fully featured enough and reliable enough that they would likely meet your needs, and be far cheaper than trying to implement your own database. In addition, there was no maintenance headache as the code was owned by an external company who you could take out a support contract with, and this would be cheaper than keeping in-house maintenance staff. The very idea of implementing your own database was laughable.
Nowadays there are far more application platforms than just databases. For example if you want a reliable, scalable messaging hub which allows integration with many current and legacy systems then you can buy BizTalk and implement it on top of that. If you want a portal with document management, simple workflow, and reporting capabilities then you could build on top of SharePoint. In fact, there are so many software platforms now available which provide the same benefits compared to custom code as databases, that enterprise software development is largely an exercise in configuration and use of platforms rather than writing actual code.
My last engagement at Netstore was a three week proof-of-concept application based on BizTalk which handled routing of FX option messages, including complex splitting and aggregation logic, with multiple end points including Oracle, WebSphere MQ and .NET Web Services. Message details such as interested parties and costs were tracked, and could then be viewed in a portal using SQL Server Reporting Services, and sliced and diced using Excel pivot tables. The entire solution contained fewer than 50 lines of custom code. Everything was about configuration and use of the platforms.
Going back five years it would have been unthinkable that three people could implement this type of solution in two weeks (we used the last week for performance tuning) because the platforms just weren't available. However, for the three of us to get to the stage where we could implement the solution in this time has taken years of learning about the technologies and platforms involved. Any coding skills we may have picked up over those years were pretty much irrelevant, because we barely wrote any.
So at one end of the scale we've got people like Eric Lippert who builds compilers and deals with things at a very fundamental and mathematical level, including interview questions about the asymptotic running time of algorithms. Here coding ability is clearly more important than platform knowledge because they build the platforms from scratch, and without people like this we wouldn't have any of the platforms that mean we can build higher level solutions faster and more reliably.
At the other end of the scale there are people like me who don't even know what "asymptotic running time" means but can have your FX option systems communicating reliably in a fortnight. Here product knowledge matters far more than coding ability because understanding the platforms and architectures you're building on top of is far more difficult than any code you're likely to need to write. And if you need something to run faster then just make sure it's architected in such a way that adding more servers improves performance, which saves time on writing more efficient algorithms; servers are usually cheaper than time.
Which leaves us with the somewhat inconclusive conclusion that it depends on your job, and if you've done things right then that depends on what you want to be doing. If not, it's time to start looking for a new one.
Posted
Sep 11 2007, 09:54 PM
by
Greg Beech