But yes, four years. That's how long I've been absent from this blog. To be blunt, this blog started as a means to achieve a double goal: share some experiences while at the same time vent some frustrations coming from the frictions that happen in the day to day operations of an IT shop. Mostly centered around the role of databases in the business IT world, but ended up covering all topics that I touched, even tangentially.
I was -naively- expecting to achieve some degree recognition and influence by posting here, but this clearly did not happened. At least as a result of what was written here. And personal life took a few turns and twists that left little time to write anything. But that does not mean the action stopped.
Ah, but this is also a tremendous opportunity to reflect on what four years mean in "technology-time" In summary, from what I see on my sorroudings, there are a few key changes that have operated in these four years.
First, the web and mobile took over almost everything. Outside a few specific domains, no one in his/her right mind even thinks of not doing its application as a web app, preferably one that scales across a range of devices from small smartphones to slightly bigger tablets to full fledged desktop PCs. It is not easy and there are a few trade offs unless you're willing to invest in custom development for a platform. Something that only the people with the bigger pockets do. Everyone else uses the browser as a front end and something else on the back end. Except of course if you're SAP, Oracle, Adobe, AutoDesk, Microsoft or write games.
Second, and related to the first point, speed of development and deployment have become key differentiators in the SW development arena. No business will tolerate the age-old bi-annual development cycle. There is also that thing called DevOps which basically means "Sysadmins can and should write code unless they like their roles to be abstracted away by some big cloud provider in a few config pages"
Everything is converging to a global tendency that tries to automate everything, remove manual -and usually error prone- intervention, scale in all directions and optimize away all the inneficiencies in the development process itself. New methodologies like XP/Scrum/Agile bend the classic waterfall cycle rules in an attempt to extract the most out of each cent invested in people and technology.
Together all those things paint a picture where the classic roles (TI, QA, Ops, DBA, Dev) blend a merge into some sort of team that is required to perform at leves unheard of ten years ago. It is not uncommon to find web-based business doing app deployments four times a day and three week development iterations delivering significant value at a rate previously unthinkable.
Paradoxically, all this means that the classic role of a DBA is simple disappearing. Teams are supposed to have the skills and knowledge to design, mantain and monitor a database without a specific specialized role dedicated to the task. And if your DB does not perform, it is cheaper than ever to scale it up. And most of the time, it works. Problem is, when it fails, it does so spectacularly. And here is the paradox, a developer with solid DB knowledge can make to a team the difference between an unreliable and underperforming app and something that makes customers smile. Hence the paradox, the more you know about DBs, the better developer you become.
So these four years for me have been a transition from a guy who was very good programming but really added value when fiddling with databases to someone whose role and job title is simply a senior developer that happens to have a lot of very useful knowledge about how DBs and SQL works across a few different engines and architectures.
And still enjoys all this quite a bit
