Uhh, please don't listen to any advice in this thread which says "fire your highest performing engineers". You will literally turn your project into a "legacy" system overnight.
You're a manager. Your job is to focus their priorities on business outcomes. If you're not providing focus they will run with whatever pet problems they have with the existing system. That's called doing their job.
I would not worry about style or complexity. Style is irrelevant and complexity is driven by the business case. Don't try to write software that will last 100 years. Its going to be put on maintenance mode and never touched again the second your highest performing engineers leave or are re-orged.
I absolutely agree with the first part of this advice.
As to the assertion that complexity is not worth worrying about, I could not disagree more. I have watched projects fail time after time because of complexity, dependencies, and lack of budget.
Managers should encourage their engineers to spend time trying to simplify architecture and reduce code, infrastructure, and package dependencies. Smart engineers can learn to think simply over time, but this will not happen automatically. (I plead guilty to gravitating toward complexity in the early part of my career, but I have since learned better.)
Managers should place emphasis on using existing patterns wherever possible rather than re-inventing the wheel. Practicing laser focus on delivering value, evaluating solution dependencies with an eye to keeping things simple, and accurately modeling the problem domain in question.
Rather than trying to fight with engineers about implementation approaches, managers should try to guide engineers toward arriving at these conclusions themselves. I have also found that stressing simplicity as a key performance metric for engineers is a useful tool.
> I have also found that stressing simplicity as a key performance metric for engineers is a useful tool.
Some of the smartest engineers I've ever worked with produce code that is so well crafted it feels simple when you look at it, but it's actually extremely clever.
I think the conversation about "clever", "smart", "volatile" programmers tends to align the axis of _code_ complexity with cleverness, but often the cleverness is in finding the perfect simple solution.
"Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better." -- Edsger W. Djikstra
Complexity sells better because it's cheaper. This is not the, "look at this novel abstraction I wrote and proof of its correctness with respect to our specifications," kind of "complexity" that folks often mean. It's the hand-waving, just add the simplest patch you can to make it work for the business problem at hand, type of complexity. The kind of complexity that ends up with giant balls of "really simple" code that nobody understands entirely anymore.
It sells better for all the usual reasons that driving slightly over the speed limit gets you where you're going a little faster. It's only a problem if you get caught or cause a collision.
Your comment touches on the awol concept of clarity in this conversation: "The quality of being coherent and intelligible".
Balls of mud are the very essence of simplicity (in one sense) yet lacking any clarity.
Clarity is a (bad sort of) hot commodity in an immature yet rapidly developing technical field. In our field this is exacerbated by the fact that the entire field can be viewed as a monument to the peter principle (but thankfully the imposter syndrome is there as a collective salve for us all.)
I think highly intelligent engineers that can penetrate the essence of a problem and come up with effective & coherent conceptual models are a valuable but (in places) untimely assets. My recommendation to such engineers (who also wish to be responsible team members) is to recognize the cognitive impedance mismatch and broaden the 'scope' of the solution to include the human element, and descend to norm if necessary. The ultimate goal is to serve a broader goal, and fighting against impedance mismatch is un-/counter-productive.
My personal red line is the 'big ball of mud' teams.
I don't agree with your points about complexity. Some developers will go off task and introduce complexity when it doesn't need to be introduced. You must have seen this in your career.
As a manager, you should be putting up gates against this (code reviews, and politely rejecting proposals to introduce unnecessary complexity)
Given that the OP said that they were working on embedded systems, where reliability, efficiency, and often long support lifetimes are needed, this is very poor advice.
>> Don't try to write software that will last 100 years.
THIS.
I've worked as a developer on huge, multi-year projects and I've worked on rip and tear six month projects and everything in between in the 10 years I've worked as a developer. None of the stuff I ever worked on was never maintained for more than 2-3 years after release before being nuked and built from scratch with some new fangled framework or database or data platform.
When I first started as a developer, building your stuff to withstand the zombie apocalypse was something we all aspired to. We all wanted to be like the Y2K developers. You get called in 30 years after you retired to re-write your code because all these legacy systems are still running on the code you wrote when you were an angsty college graduate at your first development gig.
The truth of the matter is companies don't need something that's bullet proof to last even 5 years any more. I've always felt in some regard, nuking products is done simply for upper management types to prove they're worth keeping around, more than these things need to be rebuilt.
> None of the stuff I ever worked on was never maintained for more than 2-3 years after release before being nuked and built from scratch with some new fangled framework or database or data platform.
OK... but... that's not universal. That's perhaps a symptom of resume-driven-development?
I got a call in 2017 from someone asking about something I'd built in 2003. It was still in use.
I worked with a team in 2015. Looked at their system 2 weeks ago - still using the same base foundation I'd laid out for them.
I'm finishing up a project now rebuilding a system from 2005. There ended up being some IP and legal issues which ended up with "clean room rebuild" as the safest choice. But the system from 2005 was/is still running (for a little while longer).
That you've worked places that rebuild/gut every 2-3 years... I don't know how 'normal' that actually is, save for JS front-end stuff, which seems to almost necessitate it.
>> That you've worked places that rebuild/gut every 2-3 years... I don't know how 'normal' that actually is, save for JS front-end stuff, which seems to almost necessitate it.
I lot of the places had huge portals, e-commerce sites, or multiple transactional application sites. Many of the places I worked transitioned into and out of various platforms.
One place was a huge .Net place, had some run-ins with MS and then decided to move any and all of their stuff completely over to Salesforce. I heard three years later, MS lured them back and they went back to being a full blown .Net shop.
One big motorsports company I worked at had 8 product lines all with an accompanying e-commerce site. They were literally in a 3 year "refresh" cycle. Every three years all the sites would be re-designed, rebuilt and re-released. The company was a huge .Net shop and they always used MS for their DB's and backend. Once libraries like Knockout and Angular got popular, it just became a three year run of JS frameworks/libraries battling it out to see which one we used next. The sites literally went from Knockout to Angular to ReactJS to Vue. By the time they had gotten around to ReactJS, I had already left the company, but the cycles they were on were just crazy and continue to this day.
Another huge corporation I worked for had multiple portals. We literally re-built them all within a 3 year period from scratch, then it was in maintenance mode for a while until we got a new CIO who then decided he wanted to move to a different stack. Rinse, repeat. Less than 5 years, the cycle started all over again.
A health care company I worked for wanted to build a Wellness app for their clients (this was a new thing back then). Their direct competitor had one and they figured they needed one too to keep up. We built that in the span of about 18 months. Gets released, gets rave reviews, we have another year of front-end and DB improvements, everything going smoothly. Apparently the competitor launched a mobile app for their Wellness app. This was about a year before responsive design really took off. They panic, nuke our Wellness app, and then had two teams (one Android, the other iOS) hastily build the app and release it.
Just started working for a huge health care company. First project I was on was to take several different billing systems and create a transactional app for two teams so they could manage everything out of a single app instead of using multiple systems to log into and out of constantly every day. We built that over the course of three years. Then the initiative was to replace ALL the billing systems the team was using with a single system. Apparently the first meeting all the executive types wanted our entire team back on the project to give direction and come up with a dev plan. Again, just about the 5 year mark, all of our work got nuked.
In hindsight, it was never always some new framework. There were consistent external or internal factors (good or bad) that was driving these decisions. Its kind of weird finding out this is by no means normal, but when you spend so many years and the same things keep happening, you just assume this is normal everywhere.
What you’re mentioning is only a particular kind of software, frontend-related. Backend and embedded stuff tends to live for decades.
All major projects I’ve worked on still exist after 10-20 years, with much of the original code still in production. Some of it could use a rewrite, but it works and is being maintained.
To everyone saying "your code doesn't have to last that long", did y'all miss that the OP is talking about embedded C?
There is no nuke and pave with a new framework on an embedded system. At best, you'll see the infrastructure to deliver firmware updates rewritten, but mostly the customer expects the firmware/software to just run until such time as the hardware fails.
I have found that someone that is adding complexity is usually showing off, board, does not understand the requirement, is missing something. I usually curb my own natural tendency to do this by saying 'what is the bare min to do this one thing'. Then write what would need to be done in the comments if we wanted it to do those other 'cool 5 things'. Also if you are using scrum or kanban it is a good place to add a story to say 'lets do those 5 things'. Then see if it ever gets any traction. You can write amazing cool code. But most of the time 3 people will ever us it and they will only use it for that one thing they wanted in the first place.
I have been writing code for 25+ years now. My exp is similar to yours. Very little code survives. One proj I worked on if you still wanted to write on it you would need to know watcom SQL (sybase), MFC 4.0, win98s version of win32, and the quirks of those 3 systems. NO one is going to want to work on that sort of project unless there are many zeros on the per hour cost. That was not a small project either with well over 500 modules and hundreds of screens. I have watched project after project either killed or re-written. Code in most cases does not last that long. Of course there are some exceptions. But that is rare, the common path is most code does not last long.
Thank you. This tone of this thread was so deaf to OP's actual requests, advice on perspective and communication, that I actually started to sweat a little.
I disagree with you. You should fire the engineer strategically. Firing the engineer right away does have risk. But there is a great risk long term if the person is in the team and making the team toxic which will repel engineers with better character and better fit.
In a long run, it will benefit team and organisation if the person is fired. I have seen companies shutdown due to the toxicity induced by engineers like first hand. I have also been part of the interview where I was super excited about the product the org was building but rejected the offer after meeting the team due to the toxicity.
You're a manager. Your job is to focus their priorities on business outcomes. If you're not providing focus they will run with whatever pet problems they have with the existing system. That's called doing their job.
I would not worry about style or complexity. Style is irrelevant and complexity is driven by the business case. Don't try to write software that will last 100 years. Its going to be put on maintenance mode and never touched again the second your highest performing engineers leave or are re-orged.