3 ms·

> Too many people believe that aiming for good software quality means you need to fully adopt that new technology, whether it’s microservices, GraphQL, or distr

> Too many people believe that aiming for good software quality means you need to fully adopt that new technology, whether it’s microservices, GraphQL, or distributed tracing. You’re not done until you’ve switched fully over to the ideal technology. This. We are constantly presented with new and shiny things. And then, barely a year later, there is the next ideal technology. And the next, and the next, and the next. We have seen this with everyhing: Languages, coding standards, paradigms, editors, organisational methodology, interview methodology, frameworks, databases, security, design basics,...the list is endless. But here is some truth: C is still written. As is pure JS. Imperative/Prodecural code never went away. Websites on servers we can physically touch are still deployed. People still write working implementations for almost everything under the sun from scratch. Information-Dense, slim, efficient interfaces that get jobs done are still there. As are monolithic architectures. Good 'ol RDBMS still work great. bash is still the dominant shell. grep/cut/awk are still great for analysing logs. Water still flows downhill. "new" and "better" are 2 different words, with different meanings. Something that's new could be better. But he fact that it's new, in itself, doesn't automagically make it better. And even if its better in one scenario, its doesn't have to be better in all scenarios.

pjmlp 5y ago
Indeed, that is why even though I regulary rant about C or its influence in C++/Objective-C, I am not naive to think it is going to go away until we switch to something radically different in computing models (away from UNIX, quantum, whatever), hence why at the same time there is a very big value in achieving some improved security while using those languages, regardless that we still cannot make it 100%, 90% there is better than nothing.
dahart 5y ago
> new, in itself, doesn't automagically make it better. Indeed. It’s often the case that new is worse, and the authors and influencers pushing the new don’t know it yet, or sometimes they do but they downplay that knowing it will take time to get better, and underestimate how long. The reason old defaults to better is simply because it’s been used more, it automatically solves more problems because by the time it’s old it’s been built to solve more problems and it’s weaknesses have been fixed or patched or shimmed or worked around. Old isn’t automagically better either, of course, and things can get too old and too shimmed, but if the new thing is solving the same problems and being compared to something well tested and used by many, it’s very unlikely to be better until it starts getting old. Maybe we should take a minute to ask: better for who? Better for customers is different than better for programmers. New is both more fun and easier to maintain. New is better for programmers. Old is better for customers, it’s more stable and changes more slowly. There is something pretty important to be said for being an early participant in a project, programmers who are involved in building and integrating new things automatically become more productive than programmers who get hired to maintain old things. I’ve seen this first-hand in several different ways, the most stark of which was selling a company to programmers better than me, but took years to become productive because they didn’t know how everything worked and didn’t want to break anything. There is also something to be said for replacing old with new. I’ve seen first hand teams tear down old engines because they felt crufty to build new ones, with the promise that it was going to be fast and easy and that they learned their mistakes the first time. Two completely separate companies launched into a 1 year rewrite that ended up taking 5 years, costing tens of millions, and making a good deal of the same mistakes over again before they were done. Both cases were failures to evaluate how well things were working in the old system, they were blinded to the overall success by the long list of rather minor problems.

pjmlp 5y ago

Indeed, that is why even though I regulary rant about C or its influence in C++/Objective-C, I am not naive to think it is going to go away until we switch to something radically different in computing models (away from UNIX, quantum, whatever), hence why at the same time there is a very big value in achieving some improved security while using those languages, regardless that we still cannot make it 100%, 90% there is better than nothing.

dahart 5y ago

> new, in itself, doesn't automagically make it better. Indeed. It’s often the case that new is worse, and the authors and influencers pushing the new don’t know it yet, or sometimes they do but they downplay that knowing it will take time to get better, and underestimate how long. The reason old defaults to better is simply because it’s been used more, it automatically solves more problems because by the time it’s old it’s been built to solve more problems and it’s weaknesses have been fixed or patched or shimmed or worked around. Old isn’t automagically better either, of course, and things can get too old and too shimmed, but if the new thing is solving the same problems and being compared to something well tested and used by many, it’s very unlikely to be better until it starts getting old. Maybe we should take a minute to ask: better for who? Better for customers is different than better for programmers. New is both more fun and easier to maintain. New is better for programmers. Old is better for customers, it’s more stable and changes more slowly. There is something pretty important to be said for being an early participant in a project, programmers who are involved in building and integrating new things automatically become more productive than programmers who get hired to maintain old things. I’ve seen this first-hand in several different ways, the most stark of which was selling a company to programmers better than me, but took years to become productive because they didn’t know how everything worked and didn’t want to break anything. There is also something to be said for replacing old with new. I’ve seen first hand teams tear down old engines because they felt crufty to build new ones, with the promise that it was going to be fast and easy and that they learned their mistakes the first time. Two completely separate companies launched into a 1 year rewrite that ended up taking 5 years, costing tens of millions, and making a good deal of the same mistakes over again before they were done. Both cases were failures to evaluate how well things were working in the old system, they were blinded to the overall success by the long list of rather minor problems.