Cars and Software
I remember when lots of people performed basic car repairs. Everybody I knew had some ability to perform basic maintenance and repair on their vehicle. In part this was a bygone era where a car was an extension of your identity and an object of affection but it was enabled by fairly easy to understand and accessible mechanical designs and . . . well . . . cars also used to break down a lot. One hundred thousand miles was considered a well used vehicle near the end of its useful life. Full disclosure: I am old enough to need to scroll down a little to enter my birth year in a drop down.
Today’s vehicles are more complex machines that expose a few easy maintenance items but anything deeper requires special tools and knowledge. The bar has simply been raised on the minimal competence required to do most all repairs. For example, when I was a teen, adjusting the idle speed via a screw on the carburetor was common. The idle speed screw is now replaced along with accelerator cable and replaced with a drive by wire system. The idle speed is now adjusted by the program control module. In summary, it’s much more complicated and no longer DIY.
Today, when your new hybrid grocery getter needs repair you will most likely take it to a professional mechanic - often one with specialized skills. They have the training, experience and tools required to do the job effectively, efficiently and safely.
In case the analogy isn’t obvious, I think software development has gone through a similar transformation. Years ago, software application requirements were much more basic than they are now: feature sets were limited, scale was smaller and reliability was uncommon, just like cars. As our dependency and creativity around software applications has grown substantially, so has the complexity and the difficulty of building and maintaining them.