Redbox left PII on decommissioned machines

I worked at RedBox in 2010. C# with embedded Lua for the screens. The intent was to build a flexible architecture for CoinStar to use on many kiosk businesses.

The PII is likely log files that should have been erased nightly, but I don’t remember.

I know the guy that designed the architecture. He’s a friend that I’ve argued with about over-engineering things. He never cared if people understood his work, which is a common theme with old school engineering.

It's not just an 'old school' thing. FFS look at the state of the Javascript ecosystem.

Not an old school engineering. There a fresh engineers rolling of the production line everyday that behaves exactly like this.

I would even venture to say that senior engineers are probably much better at documenting, writing clean code, not over engineer things. My personal experience is that bad engineers move into project management, administration much faster. Which is a problem in itself since they end up being the boss of the engineers that are better than what they are.

There certainly are spots of over-engineered solutions in today’s world, but overall I do believe things like cloud serverless, and domain-driven design (modularization) have reduced complexity in a natural fashion.

These over-engineered systems usually came out of client server architectures using heavy inheritance object pyramids, which we definitely don’t build as much anymore.

> He never cared if people understood his work, which is a common theme with old school engineering.

Not in my experience.

I agree on the management aspect, and even promoting good engineers "too high" on the "parallel promotion track" can effectively take them out of the engineering work just as much as if they went into pure management. "Does the CTO still code at least sometimes?" is the only tell I have for whether a company has fallen into that trap or not.

For the engineers themselves, though, I think it's a mixed bag when it comes to "older" ones. That is, correlations on just age in the field are weak. Sometimes they're great, sometimes they're really meh. Whether something is over-engineered or not really is case-by-case, part of the problem is sometimes something looks over-engineered but is just the normal thing to them by now, nothing special, even though its architecture handles a lot of concerns that a more naive and obviously not over engineered style would have produced. In that case, they're validated sooner or later.

Sometimes they're more up to date about various new things than even the energetic young bucks, sometimes they're too stuck in their ways. I've seen examples of both knowing about modern hardware details (and being able to take advantage of them) and having a stale idea of how CPUs work that wasn't even quite accurate in the 70s. (So, not too different from a lot of fresh engineers who get educated on such simple models.) I've noticed no correlation with age on whether someone has completely mistaken ideas about JVM performance.

Being stuck in their ways in particular applies to things beyond the pure code and coding style -- and it's not necessarily a bad thing. If they've managed well so far without pick-any-of good documentation, good debuggers, good source control, good editors, good open source, methods to thoroughly avoid various causes of engineering pain, etc., why bother doing or taking advantage of those things now? And if they're skilled, they might even be right, it's probably best not to disrupt them if they're not a bus factor risk. But if they're more on the meh side of things overall, they can hold things back too much.

(By "older", I mostly mean those who were practicing since the late 90s/early 2000s. But I keep in mind that the global supply doubles every several years or so, so it's quite possible for someone with only around 5 years of experience to be in the top half of seniority already.)

I never said old. I said old school. Age is irrelevant.

Guys that adhere ruthlessly to their own framework designs without regard for onboarding timeframes.

They truly believe if you can’t understand their framework designs, you’re not smart enough.

I’ve always believed a critical aspect of software architecture is making sure the developers that will maintain it are a part of the design. If they’re junior and mid-level, your architecture better accommodate their skills.