Shift-Left Is Silly

Ok, the idea isn't silly, but…

When I started in this business it was developers, developers, developers and the ubiquitous Ballmer Monkey Dance (I was there for that). Write some code, throw it over to the testers, ship it over their objections, and then release updates. Maybe there was a PM (Program Manager) in there to mention the customer. Then came agile. We renamed our software test engineers (STE) to software development engineers in test (SDET), asked them to do some automation, called the PM a scrum master, then shipped the code. Then came devops, and the operations folks joined the team. The team charter got broader and included observability and alerting. Now they're talking about the wisdom of DecSecOps, saying we need to get security involved earlier. And again, they're not wrong, but…

I'm a Mechanical Engineer by training. Mechanical engineering is _old_. It's as old as the screw, stick (lever), rope, ramp, and wheel. And over those thousands of years mechanical engineering has learned a few things. Not simply, and not without pain, and not without big mistakes (ever seen the video of the Tacoma Narrows Bridge wiggling?), but like the Farmer's guy said, "We know a thing or two because we've seen a thing or two." And one of the most important isn't engineering per-se, it's everything that happens *around* the engineering. From the building the pyramids to the Manhattan project to Apollo, it's not just the results that are impressive, the system required to build them is impressive too. Coordinating 10s of thousands of people in hundreds of locations and when you get done the result works. Learning how to do that is at least as big of an accomplishment as the thing being accomplished. We don't always get it right, but we try.

So what has that got to do with Shift-Left? Well, all Shift-Left is saying is that in software development you can break down a system into components and implement them separately, as long as you think about the entirety at the beginning. You need requirements, designers, engineers (software and hardware), program/project managers, testers, operations, security, supply chain management, and anyone else that might be involved going from an idea to a product.

And that's another way to describe Systems Engineering.