August 30, 2024 at 12:00 am
Comments posted to this topic are about the item Trying New Technology
August 30, 2024 at 6:34 am
Speaking from the viewpoint of spending my entire career in IT and now retired, I totally agree with Steve.
Sometimes the new shiny can give a significant advantage to IT. Sometimes. Most times it becomes a support millstone that slows down getting the day job done.
The job of IT is to support the business, help make it easier to run and to help make it grow. IT is also horribly expensive, so it needs to focus on its main job so it is seen by the C-level people as succeeding in making the business easier to run and larger.
New shiny very seldom helps. But new shiny needs to be explored and tested, because once in a while it will totally make a big difference. Just remember that the new shiny that does not stand out during your exploration and testing is unlikely to be more than a support millstone if put into Production.
Then there are the Point releases for software that has been adopted. Unfortunately part of adopting software means keeping up to date with updates and fixes, even if there is little obvious advantage in doing so. The moral is: be careful and be lucky, and keep your skills and resume up to date in case corporate care and luck go awol.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
August 30, 2024 at 3:51 pm
Whole heartedly agree. TOGAF used to list a set of architectural principles that included "Controlling the technical complexity".
Ed's comments remind me of Fred P Brooks paper No Silver Bullet.
My take is that an organisation should seek to build pools of expertise to address pockets of ignorance. I've seen the adoption of shiny-shiny build pools of ignorance with pockets of...... well not exactly expertise.
I've also seen essential knowledge lost to the organisation frighteningly quickly in periods of high staff turn-over. I can remember one developer, as the only one who knew anything about a particular system, fight off any change requests until he could hand in his notice.
Developers rail against the "Merchants of Complexity" made for entertaining reading. It also dovetails with advice from Dr Venkat Subramaniam.
It is worth factoring in how long you want to work for an organisation and in what capacity. If you find yourself looking after a niche technology then you are vulnerable for two reasons
August 30, 2024 at 6:02 pm
I do think some things can be hard, and there is value in frameworks to a point. Certainly auth is hard. Not for DHH, but it is for many people and they mess it up. However, you should limit how many dependencies you have in your software, especially at today's pace of change.
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply