Building for the 99% Developers

2. You probably notice macs more because of their uniform branding, compared to a mish-mash of different looking other laptops.

3. Is it not enough to watch and listen to a keynote without pulling out a laptop?

On my previous job, I had been working for 15 years on the development of a complex business system. It included desktop apps, mobile apps, webs, on-premises and clouds. Throughout the years, we have introduced many then cutting-edge technologies for new products within the system. Some technologies before they were cool. But, the fine-working-already-done products, we kept supporting with the original technology for the lifetime of the product.

The point is that many new tools and technologies bring a very limited value to the finished working products.

Now, I am a maker of the new development tools. So, I am eager to push them to the world, but wouldn't like to be perceived as an "architecture astronaut". Your opinion helps in understanding how and why engineers choose new tools and technologies.

It just boggles the mind, but fair enough seems like a marketing failure rather than a technology one.

Logical database backups (I'd point to mysqldump/mydumper & myloader if we were talking about mysql), combined with physical snapshots & copies of the binary files.

500 GiB is a lot, but not too out there these days.

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.