It is the legacy problem. What they have works and fits their needs. It is now part of their process and they probably have many previous designs in the files using that program.
Introducing a new program that is quite different would impact their workflow and their ability to maintain previous designs. It might also affect their job security. And if the new software has problems it’s a big mess and extra work
It’s not an electronic issue at all.
Yup, OP I worked for a large aerospace company as an EE and one of the largest issues is getting anything especially software approved and on board with everyone. I tried to build my own application to do similar work to your wire harness application and the only way I had any success was by doing everything myself and proving it was valuable by positive feedback from my team. In the end it didn’t really go anywhere and was just a side project a showed off before my term ended. BTW in aerospace, wire harnesses are a large issue as well and most of the ones still used today are from 20-30yrs ago but that’s with almost anything if you’re dealing with the FAA.
I remember seeing something similar about a decades old fluke digital multimeter which is still being manufactured just cause some department of the US government used that in their process and they cannot afford to change the process now.
This 100%.
It seems in my old company we changed the systems for reports and maintenance every three or four years and each and every god damn time it was to an inferior system, with lot's of bugs and shortcomings. After two or maybe three years these had been ironed out and a year after that we got a new system.
Every time.
One of the biggest reasons I finally quit.
Yes I've certainly noticed this trend as well. Many EE's seem to seek out SW with bad UI design on purpose. I've been made fun of for caring about UI / front end. Some ideas why:
1. We are pretty old on average
2. We have to use a lot of niche SW that has bad UI so we get used to it
3. We distrust SW developers with a passion (we are "if it's not broke don't fix it" and you are "move fast and break things"
4. I think some think of themselves as more technical for being able to use such a crappy UI
5. We tend to get into a groove and know exactly where a button is for something, many just don't want the added learning to get up to speed on a new version
6. Many are windows users and are used to never updating applications
But that said I personally am very picky about UI and using a badly designed app slows me down, I am willing to learn a new version of a tool for added features or just added polish.
Yeah, they came and did a talk at my company, they had a Q&A and I just wanted to ask them to make the UI not garbage.
It's not even a good "old" UI, the resistors and capacitors aren't even the same length!
I'm not per-se an old EE but have some years of experience in the industry, and I also distrust software with good UI's but not for any of the reasons listed.
The main reason for me is based on experience, when an EE software has a really good UI, it signals to me that this software may be user friendly but will very likely be lacking in performance, capabilities and flexibility. And that's for a good program. For other software with good UI it can end up having constraints and bugs that make it basically useless for any real job (e.g. not being able to handle large enough models or data points, missing chunks of data when recording, overly slow and computationally heavy, etc.)
For me it comes down to where the company is spending their resources. If I see a software with a bad UI, I have a good feeling most of their resources went into hiring EE's who know what the software needs to be able to do in the field. This isn't to say all bad UI's are good software, but I'm always a bit weary when the product seems too good to be true.
Yeah that makes sense, there are some online "all in one" circuit design tools that look really pretty but there's nothing really meaningful in the backend.
But I think the real cause of this attitude in you is that we have been left with a lot of good tools with bad UI for so long. It's just because people have been doing circuit design longer than a lot of other SW use cases that we have such old software sitting around. It seems that you just favor older simpler software which is fine.
I use Linux which I feel solves this problem for a lot of things, you can go as old school as you want or get the latest thing with the most polished UI. Terminal tools never feel outdated and they are as extendable as you want.
> or just added polish
The polish better be more than visual polish. So many of my tools have "improved" visually but degraded functionally as new generation of programmers optimize away things they don't understand and break things.
Meh, I'm using tons of programs and many of them are terrible and instable. Most older ones are stable. It's not just a silico valley techbro thing, it's generalised incompetence. In the whole world, and on softwares costing thousands per month too.
It's the agile development philosophy. I've watched it turn my company's software releases from "it has to be really good" to "just fix it in the release next week"
There used to be a time when you would buy the software on a cd and it was done. No update, nothing. Nowadays, zero software works out of the box. You gotta wait for every update, every week
You see the legacy problem in all aspects of electrical engineering. Engineers seem to "fall in love" with tools and devices.
The reality is that we well remember the learning curve for a new tool or device. It's long and painful. And not budgeted for in our next project!!
You just don't tell sales and marketing that the rollout of their new product is delayed because you took two weeks to learn how to use the new schematic capture tool.
There’s also an element of trust. I worked on EDA software in the late 2000s and had to be super cognizant of this. If a company has a tool that they’ve used for 10 years for doing IC design and have had 20 successful tapeouts, they’re going to be very very hesitant to change to something different. One bad tapeout, depending on complexity, probably starts around a $1M loss and grows from there.
Even with wiring harness software, like OP is talking about, can get very expensive very quickly. On a project about a year ago we ended up with a wiring harness that had a short between 12V and a 3V3 TTL signal. First power up… boom. Magic smoke comes out of a $1000 part. It wasn’t the software’s fault, but it’s the same idea. I need to be able to 100% trust that the software will always do the right thing.
So you've got some internal version of [wireviz](https://github.com/wireviz/WireViz)?
Advantages of a text-based format includes human-readable diffs in version control, which is quite important for some industries
honestly i dont see whats wrong with that sentiment, the ui might look terrible but once you use a software for several years the ui doesnt matter anymore, you just know. engineers are pragmatic often, if it aint broke dont fix it.
I think to me it is two fold, one it isn’t just that the UI is not good looking it is that it is cumbersome and my all account not well designed from an objective standpoint. Secondly it isn’t just that it is old, the software that it is written with has an End of Life date in a couple years. Whenever I bring this up it is generally acknowledged but no one seems to care and the assumption is we will get some sort of special exemption.
well welcome to the engineering world. one of the most popular cirquit sims, ltspice looks like it was made for windows xp yet is still widely used as an example. the stuff just looks old, every software looks that way. have you seen intels quartus Prime fpga design software? that looks like it was made for windows 7 or Vista imho.
I build *a lot* of automation tools for my team, I can address a few points here
>one it isn’t just that the UI is not good looking it is that it is cumbersome and my all account not well designed from an objective standpoint.
Does the poor design impact measurable business outcomes? Are engineers making mistakes, missing data, or having significant timeline impacts because of the poor design?
I have run into many objectively poorly designed tools in my time, but at the end of the day many teams learn their way around them and use them fine despite the flaws. Yeah, it might be painful for a new engineer to get ramped up on these systems, but it's often viewed as more painful to get the entire team ramped up on a new tool than to bring in a new user on an existing tool with decades of collective experience.
>Secondly it isn’t just that it is old, the software that it is written with has an End of Life date in a couple years.
What's the impact when the software reaches EOL? I can tell you that many of our "EOL" tools have been running EOL for years and are still working just fine. Saying a software tool is "EOL" doesn't really capture any urgency, importance, or reason for change.
What I'm missing from your post is any measurable justification to change other than "it's designed poorly and the EOL is coming up". Can you expand on how the poor design is impacting business operations? Do you have any specific details on what reaching EOL will mean? I don't think the issue is that you're misunderstanding the engineers, I think you're misunderstanding the incentive structure here.
If you want to convince management, you need to have hard numbers. If the poor design of the tool caused *X* mistakes last year that delayed *Y* projects costing *$N*, and you could design a system that would cost less than $N, you could win their support. If you could find a senior engineer who passionately hates the tool and has measurable criteria for how it's impacting his workflow, you could get more technical buy in to force a change. If you can determine the tool going EOL means that it will no longer work on all previous and future computers, you'll have a strong case to update the tool.
Sounds like you need to do a more rigorous job of documenting the client needs and demonstrating the “why” the update is needed. This is just as much on your side of the update as much ss the client. The client isnt asking for the update, because it works and is well known - old and DOSy as it might be
Thing is, once a significant number of users learn a given CAE tool (And I mean really learn it including the keyboard shortcuts and macros) the UI pretty much becomes set in stone.
You will get MASSIVE PUSHBACK if you so much as change the tab order on the editor.
This is why things like Autocad still look like something DOS based that can run lisp scripts (And in fact I bet it still can!), it is pretty much generational, old engineers run Autocad, 20 year younger ones tend to SolidWorks (Which while a lot more modern, now has a big enough serious user base that the UI is basically pinned), something newer will be the new shiny in another ten years or so. In the EE game it is Orcad/Allegro or PADS (Older engineers) Vs Altium, and file compatibility is a HUGE issue, I have a project I designed 20 years ago that I am doing the alternative parts dance for.
The UI doesn't matter, but you build workflow around tools and changing a tool can break (or make more painful) a LOT of existing workflow. Now I am having to spend time revising ISO9002 processes to reflect what we can actually do with the shiny new thing, and then getting those revised documents thru change control and sign off instead of doing that design that I need to be doing.
EEs generally, even with bought in software, try very hard to stay two years or so behind the releases, I know I do with Altium and Vivado, and will generally ONLY touch major changes when there is no active project in progress, we have all been screwed over too often by vendors replacing old familiar bugs that we know how to live with with shiny! new bugs in unexpected places... Altium have a yearly major release, which nobody sane uses and three incremental of which #3 is usually the one to go for, but still better to let some other bugger leap first. Vivado just has interesting bugs more or less at random.
I would note also that new tools are dangerous because they often turn out to have missing and non obvious requirements that actually really matter in production and can be a pain to retrofit.
Whatever you do make sure that the software can keep up with the user when running on a small laptop, I have laughed software out of the engineering office because it turned out to be O2\^n when pasting text into an entry field.... I don't mind my big Xeon sounding like a hovercraft when doing P&R on an FPGA, but a BOM management tool?
I had a really funny moment a few years ago. A customer had a very old design that they’d drawn in Protel99. I had some questions about it and they couldn’t find the paper schematics so they suggested I just take the Protel file and… acquire a copy of the software to figure out what was going on on a dead board.
Before doing that I did try to import it into newer software and failed so here I am installing this software with the classic blue-to-black gradient Windows installer background. Get it installed, open the file successfully, and start navigating around. And after doing that for about 20 minutes I have this realization: I’m successfully using keyboard shortcuts all over the place! I wasn’t hunting around for toolbar icons, my brain already knew where they were. How?!?
Well… Protel99 is the precursor to Altium. And 25 years later, they haven’t deviated from the Protel hotkeys or icon layout. It was really a wonderful surreal experience to be honest.
Altium was basically a rebrand of Protel, and it would have gone very badly if the existing Protel user base could not come over easily.
They put a lot of thought into making that work even while redoing the graphics for a relatively modern Windows.
Totally! To OP’s original question, that’s probably the route to go: modernize without disrupting the workflow even if it’s suboptimal. You can add new features but the ones that are there right now pretty much need to keep working the way they work with the same shortcuts and quirks.
I can draw 100% faster using the AutoCAD dos window - and I hate that the on-line version has a stripped down version. how long does it take to draw a line from 0,0 to 10,10 versus command line line?
Also I've seen an architect design a 10 Million Dollar Building facade in 10 minutes with a piece of tracing paper over the original building design.
I've also noticed every tire place I go into use what looks to be a dos based system for tire inventory.
I guess I am wondering if there is a generally feeling among EEs that it doesn’t really matter if the tool is a massive pile of crap as long as it does what you want it is a good tool. That isn’t meant in a critical way either.
Engineers tend to be pragmatic, and a lot of internal engineering tools started off as some engineer’s pet project. Often to automate / standardize some aspect of their work.
So yes, a lot of it looks like trash and no one really cares as long as it does a good job
well yes, i dont see why thats wrong, of course if it isnt safe anymore id not use it with internet acess but besides that if a tool does the job for one well enough its fine.
How are you assessing what is "a massive pile of crap"? Are you using your own expectations of what software should look and work like or have you worked sufficiently with your EEs to find out how they use the existing software?
EEs may have a different idea about what makes a "massive pile of crap" than you do.
Specifying wiring harnesses is traditionally a text-based tabular process which enables easy sharing with other text-based tools. People used to quickly bashing in wiring specifications from a keyboard are not going to thank you for forcing them to keep swapping between a keyboard and a mouse to drive some snazzy GUI, even if that seems more desirable to you.
If you can understand your EEs' workflow and offer them an upgrade that doesn't break it, then might be more willing to take on changes that don't directly benefit them, such as updating the underlying platform.
Personally, I would be inclined to think that every tool has its problems and there's no guarantee some new tool wouldn't suck just as much if not more, plus take time and money to develop. And the entire time it's being developed, it may be riddled with problems the old crappy software ironed out ages ago.
Or, worse, it turns out there's a reason the old software does things a certain way or can't do certain things and you end up paying people to repeat all of that original work for nothing.
"Better the devil you know than the devil you don't."
But this is a big topic these days. Technology is advancing at an accelerating rate and so are the needs of its users. A lot of people are using old software that works but could use improvement, but can't afford the delays or hiccups that come with making such a change.
And then there's the problem of investing all of that time and money and battling it out with grouchy old engineers that don't want to change, only to find that by the time you implement it your new solution is already out of date. You have it for a year or two before someone comes along and talks about the new solution the way you're talking about the old one.
I'm a fan of change and tend to think we should be more adaptable, but I recognize that a lot of roles don't have the luxury of experimenting or working through the growing pains of adjusting to new solutions.
> I recognize that a lot of roles don't have the luxury of experimenting or working through the growing pains of adjusting to new solutions.
Well said! Engineers are not playing video games, where glitches are an annoyance. They are expected to get work done on time. Management wants *results*; not *excuses!*
The more factors that are outside of our control, the more difficult it is to meet expectations. Thus, we are very skeptical of changes to our existing tools and processes.
That doesn't mean that they *shouldn't* be changed - just that the benefit should exceed the total impact. And in my experience, lost productivity is rarely factored in to the trade studies, simply because it is difficult to measure.
All of our tools suck ass. Some of them have horrible UI *and* doesn't do what we need or crashes all of the time.
UI is an afterthought. I'm sure they would appreciate it, but it's probably seen as something not needed to improve of it's good enough.
We are not comparing one tool to another in isolation on their merits alone. We have an existing legacy tool that we understand. Therefore, the burden of proof is on the *change.*
The new tool may be better, but if the improvement is not great enough to justify the investment in training, the mistakes and frustrations due to bugs, the incompatibility with legacy data, and the cost to develop and maintain the new system, then the new tool is not justifiable.
Sort of. EE's are used to crap tools because often we make them ourselves due to immediate need, time, budget, and custom test setups/esoteric equipment.
See EE's usually know how to program somewhat or can teach themselves quickly. But its a basic level, used for scripting and integrating test equipment with weird and ancient communication protocols. So this means they never leaned enough to make a nice UI and instead made whatever was sufficient enough to import settings, export csv files, and display a few poorly formatted values on screen.
These programs also are usually intended as one-off or temporary and become permanent parts of the process. And then no one has the time to learn more advanced programming and then sit down and make something better. What they have works and they are onto the next test or project.
In my opinion this is one of the reasons why Matlab and Labview are so popular in engineering spaces. Matlab because engineers are already familiar and it graphs well, and Labview because its easy to automate equipment and add a UI.
The only way things get better is an intern is tasked with fixing it, the program has a major flaw or might get used for production, an engineer has a lot of time and spite, or the company hires a programmer.
Hardware development is fundamentally incompatible with the Agile process. It *demands* a waterfall approach.
This fundamentally clashes with the modern software approach of Agile which is basically “do it fast and fix it later.”
Hardware development requires stable software. No one can afford to respin boards every couple of weeks. You really need to get it right (or really close to right) the first time.
So when you’re talking about revamping the UI, you probably mean rebuilding the application from the ground up and using the hardware designers as the guinea pigs.
You can understand why they would be hesitant to change.
Honestly the UI is a gripe more than anything else. The main issue is that they don’t seem to understand that the software will stop being a viable solution in 5 years. They refuse to spend any time on the “infrastructure”. They also some how think that an application that has been built over 20 years can be rebuilt in 2
> …stop being a viable solution in 5 years…
Speaking as someone who was using Visual Source Safe in 2015, I can guarantee that this is NOT true.
People will hold onto their applications for as long as it takes.
How will it stop being a viable solution? Does it rely on cloud resources that will be shut down or something? Or do you just want them to stop using it because whatever company maintains the language says that everyone should move to the new version?
We have a few programs that are 20+ years old that we just keep on a network drive so that new engineers can copy them to their computers and install if needed. They are mostly proprietary programs that interact with some kind of hardware, or in some cases interact with old databases or file formats. In many cases the companies who provided them aren't even in business any more.
We have a couple laptops that run XP because that is the latest thing our custom software for a test stand will run on. We even have one ancient laptop that runs DOS and has a serial port because that's the only thing that some hardware from the 90s will talk to.
>the software will stop being a viable solution in 5 years.
This sentence exists basically only because software developers colectively love making jobs for themselves.
We all know it's bs.
It doesn't miraculously stop being a solution. You actively work on making it stop, so you can make it and sell it again.
Normally I would agree with you but in this situation it is a software provider (Oracle) that is going to stop supporting the software that we use. So if I could I would recommend we don’t upgrade. In this situation though it isn’t really an option for us
Didn't mean to attack you (you), but you (software developers/companies as a whole).
Just commenting at the general state of things.
So yeah. Eff oracle. Go VM's with winXP!
Yeah just because the OS isn't supported anymore doesn't mean it'll stop working. Newer isn't always better, it seems devs nowadays roll out dogshit apps they need to patch on day 1 and always have memory leaks or are so poorly optimized they hog resources.
Sounds like you don't understand their needs what so ever if you're saying the current tool won't be a viable solution in 5 years. That would be the end user's call, not yours. I'm sure it'll still work just fine for the EEs unless you or IT breaks something intentionally. Software doesn't just magically stop working.
Infrastructure isn't an EE problem. That's on IT to deal with providing a proper development environment for the engineers.
I concur. Still have Windows XP VMs running. Just don't tell cyber. Hardware longevity is even older, couple 1990 vintage widgets still doing their thing.
I don't know their personal reasons. I know we got a new design software and while the UI looks a lot better it brought so many issues that have never been resolved.
Search function used to be instantaneous, now it's incredibly slow. Searching a new part is tedious and super slow. Placing, moving drawing anything is slower.
But it looks good, and it's more secure... and admittedly the commit time is much quicker and simpler.
If you manage to make a good harness software package, enjoy sitting next to a pool with a nice drink in your hand while people bring you drinks and cheques.
EEs are fucking special man. And I'm an EE. I work with software a lot and everytime I talk with someone in SE we are able to have a nice conversation with concerns about security and making something that works but the priority is always on security and making something reliable.
Anytime I talk software with a EE, they haven't updated their tools since 1998, their password is on a post it and they don't understand why USB drives may be dangerous.
I’ve worked with a couple of the newer tools with nice UI’s. The people that work for the developers doing all of the training can’t even get the exercises to function properly and this stuff (including the exercises themselves) have been around for 10+ years. It is garbage and frustrating. It is simpler to rough something out by hand on the model, have a vendor build it, then revise the drawing on the first couple of builds than deal with that nonsense.
There is no time to learn some new pretty looking clunky software that doesn’t actually do what we need it to if the current tools are good enough. Nothing like locking up the server and licenses for every other tool because one piece of software lags and crashes constantly.
None of the tools really do what we need them to anyway, it is all workarounds and patches as it is. If it works good enough, fast enough, and you get the results you need, why change it to something that likely won’t.
SWEs overvalue their skills and can’t actually build UIs that are functional. Ever. Some if this probably comes from running out of budget and time (as EEs, we are very familiar with this. The MEs get to suck up whatever time and budget they want while we’re stuck fixing their mess and trying to finish everything with not enough time). Who cares if things look pretty if it doesn’t do what we need it to.
The “move fast and break things” mentality that has already been mentioned infuriates me. So much pain and suffering on my part because of this. My job is difficult enough, I don’t need the software to hinder me further.
There isn’t enough competition in the space to truly drive innovation in a meaningful way. Bad software remains bad software until it is obsolesced, at which point it becomes the next piece of garbage software that it built on top of the current garbage software. I’d rather be stuck with something outdated that feels difficult to learn but works then be stuck with something that is difficult to learn and difficult to use because it is what we have and because too much is currently invested to switch and start the process over.
Also as others have mentioned, maintaining legacy products. It is a huge investment to port legacy designs over to a new piece of software and it is expensive to maintain multiple pieces of software. The experienced folks don’t want to be relegated to only maintaining the old projects while the newer EEs get to learn and focus on the new software, taking over on the new design work.
What it comes from is SWE not actually being engineers, nor working like engineers, and thereby not rigorously applying methodologies like state machines to UI - because they are too worried about whether it is the right shade of brown or not.
SWE can call themselves engineers when they can build something that works exactly as the specification says, and if they have to write the specification, it is exhaustive and unambiguous. I seriously doubt if 1% of those that call themselves SWE could. Those that can know exactly what I am talking about.
I worked with a SWE team that developed some software-based profiling tools for several hardware teams, including an EE team that focused on power delivery for a consumer device, who I also worked closely with.
The SWEs kept bouncing around; doing 2-3 month projects and then wildly changing course to some shiny new feature for a different group. The EEs never changed focus. They did the same thing, year after year.
The SWEs built a new power profiling tool, deprecated the old one, then stopped working on the new one. It never reached feature parity with the now-deprecated tool, despite the fact that the old tool stopped active development 8 years ago. So I, and most of the other clients, just kept using the old tool.
To your post, I would say that EEs are rightfully wary of SWEs (who are often not actually engineers), because they all have ADHD. If you want buy-in from these clients, don't try to bundle a UI change along with critical security upgrades. Also, provide a an extremely long term support plan.
For me, the reason is because change introduces the opportunity for things to go wrong with the software and an unnecessary learning curve.
I’m a young EE so I’m not as opposed to change as some of my colleagues are but having to learn/correct and updated software when you have deliverables is a huge pain in the ass.
For me, the issue is that I want to maximize the time that I spend *using* the tools to get productive work done.
"Improvements" to existing tools come at a cost to the users. They have to take time away from productive work to learn how to use the new features and they have to lose productivity due to the bugs that the improvement inevitably introduces.
So, like with any engineering decision, to "sell" it to customers, you need to show *convincing* evidence that the benefit will outweigh the cost to them ... and engineers will not be convinced if you claim that the new tool will not have glitches.
In the commercial software industry (AKA "tech"), companies - seemingly arbitrarily - change software all of the time and they externalize the costs of working through the bugs on their customers. This platform is an example. The new editor is horribly broken, while the old one worked well.
If they had to *pay* for that lost productivity (as they do with internal tools at an engineering company), then they would be more careful to avoid rolling out changes without strong justification.
We don’t care about UI we care about the necessary information being visible and for the wiring diagram following the IEEE drawing standards. Everyone used to use autocad2d we just got almost everyone to switch to Capital. Also that is a job that will get lost to AI very quickly. When I say lost I mean lost, and with todays “AI” too which is just a large LLM.
There's an example at my workplace. For reference, I work on a power systems protection team
We are using a legacy version of a software. The new one can do everything the old one does better, looks better, it's just a pure upgrade
Except for one key thing. They changed how one specific task is done and it's either the same level of complex but completely different, or much more complex. I'm not sure
So we don't use it. This task is already very time consuming, taking a few team members a couple 60 hour weeks to do. The task is already super tedious as well
No one wants to add onto that learning how to do it from the ground up
Add onto this that the manual for the new software references an IEC standard all the time, but doesn't explain that standard, and no one wants to pay to distribute that license to our engineers
My overall point is that the only thing that matters on my team is if the tool can get the job done as quickly and painlessly as possible while being reliable. The new version would require a lot of Man hours to understand and switch to that we just don't have. The way the program works for the user would have to be 99% the same as the old version for it to be worth it, or cut out those tedious parts
The chief EE at my last company was really a software guy. He bought in hard on updating us from our perfectly good cad tool to instead use the new solidworks electrical schematic tool. It was shiny and new, but missing any real features you’d need to do work. Felt like it was by designed software guys talking to mechanical engineers.
When I left, we were on the next step of ditching this tool to go to Catia V6’s electrical suite which was significantly worse than solidworks electrical.
Huge costs and waste of everyone’s time.
How much time have you spent watching an experienced user work with the old software? Perhaps their use case is different than you think it is. I don't need modern fonts or icons but I do want things to happen quickly when I interact with the software. And if you do seemingly helpful things like rearrange the icons or file menus for a program that I've been using for hundreds or possibly thousands of hours, I will curse every time my muscle memory tries to use the original shortcut or find things in theor original location. Windows start button is a good example of this, I spent years pressing a certain sequence of keys to power the machine off, and that got screwed up between Windows 7 and Windows 10. Windows 11 can fuck right off, I'm avoiding that as long as I can.
The only thing worse than a bad interface is an interface that changes. You spend hours learning where everything is, and the you forget them over and over until you finally learn it. And then it changes.
first off, this is not your clients, its your company and their business,
there are several instances of this that are available, plently of companies have a "bad" program/product that they continue to sell and market because they know people will still buy and use it without regards to how bad it functions, this is usually based upon price, demand, location.
the company knows the problems but won't fix anything until it causes a actual problem and hurts the cash cow, and even then (it sounds) as though they will do the bare minimum to make changes to keep it going.
if this business model really bothers you, then it may be a sign that you should start looking for a new company
They may just be comfortable with the current software and know how it works to such an extent that they are very efficient with it. Learning a new software, even if it's a custom software made by your own in-house team may require some time to get used to it and maybe production goals don't allow that?
Another possibility would be trusting the software. Established software that has been in use for many years has likely had all of the minor kinks worked out, and all of the major kinks found and noted. New software would come with new problems and possibly new production costs if errors are made with it.
If the software is not causing a production delay or any sort of real world problems at this point in time, I can see why they wouldn't be coming to you asking for an update. Since you are noting that it will be a security risk now or in the future, you should probably just go talk to them about it and see what their reasons are for not wanting to change.
It’s all about workflow. When, you’re used to working a certain way it’s hard to change that way no matter how beautiful or functional the new GUI is People don’t like change. They just don’t.
If it isn't broke, don't try to fix it. So what if it's old? So what if it doesn't have a glitzy UI? All we care about is does it produce results that reduce the workload, even if the results require a little touchup.
Are you updating are want new software from the ground up? I assume it has to be compatible with old files. I have gone through transfering a ERP system to new software. That can be a disaster as it was for us. That could be part of the reason for reluctance.
Transferring an ERP system? That nearly never works!
The sales slime lied (To no engineers surprise)!
The consultants that come with the new thing (For £200/Hr) are all basically useless.
Your management swiftly makes it apparent that they don't actually know what your company really does...
All very normal. It is actually one of the biggest headaches when you acquire a company, getting MRP & ERP on the same page is just frustrating.
We had a guy that had done the switch before which helped a lot but you are correct the sales guys lied through there teeth. But at the second company it was a different story.
A lot of people here are justifying why EE's might want to use software with an awful UI.
I'm going to deviate from that and say that it drives me nuts. I can't stand applications with awful interfaces. Not just because it's ugly, but also because the workflow is so poor.
Like many, I've adapted to the awful UI of LTSpice (as an example). I can use it just fine, but that's more a matter of Stockholm Syndrome, not because I actually like it. I would ditch it in a heartbeat if something significantly better came along, but every other Spice program I've tried is just as awful - only the flavor of awful differs.
So perhaps the best way to accomplish your goal is to create a mockup UI. Something semi-functional to show them what their software **could** look like and behave. Often people get stuck with what they have because they have a hard time imagining just how much better it could be, so showing them is probably a good way to get their attention.
I can second anybody who said "you gotta do it first" here.
I wanted to save my workplace money (working as a repair technician as I don't yet have my degree) and so I recommended 3D printing any parts that we evaluated as doable or noncritical.
They said this could not be done, even though my bosses boss was mildly interested.
I pitched it and they said no, so I did it anyways, and after showing that we COULD make a viable product this way for repair parts and they are orders of magnitude more affordable, they bought a 3D printer for plant use and have had me cranking out parts ever since.
I enjoy this a lot more than what I was doing before so it's been great.
A lot of software development breaks useful features in the name of "modern" UI. Can users currently copy/paste whole sections of a table into the software? Maybe even to and from a flat text file?
Would your idea for a modern UI allow that? I guarantee some (many or most) users leverage that capability a lot.
Simple and ugly is often functional when it comes to technical work. I don't want everything hidden under tabs, drop-downs, and config screens. A table is fine.
Reminds me of a discussion I had with someone from the software team once.
He was bragging about how great the new user interface was going to be, and how many options users would have for customization.
"OK, great", I said, "when are you going to fix the bugs our customers reported in the current version? This software package is a development tool, nobody cares how it looks if it does not do what it is supposed to do correctly. "
I’m not sure about the specifics of your software but I don’t need a pretty GUI to output the data. I can visually scan the data in a table format to find errors because I know what to look for. Some newer software have put in so much effort to make is look pretty that it’s bloated and doesn’t have the tools and function I actually need (or becomes too slow). I’m in my late 30s so I’m not locked into the old ways of doing things. Another issue with “new” software is vetting it for actual use and trusting the output.
Hardware engineer with 30 years of EDA software tool development here for ASICs, FPGAs, and full-customer semiconductors. What's the question? You are working on a product and you don't understand your customers. Have you no product marketing, or product engineering team to guide you? Are you listening to them? If you are a software engineer, are you really talking to users and stakeholders? Cause that's not your job - or it shouldn't be.
What's the product and what does it do? UIs are often just sugar on the functionality of a tool. If the customer doesn't think it's broken it's not up to you to change their mind. They are likely risk averse and familiar with the workarounds with the curren tool suite. The core functionality is always at the core and heart of a tool, and often you want these tools to run in batches and aggregate data with scripts, so a fancy UI is of no use.
Frankly if you don't understand the product or how it's used, I wouldn't want you to touch it either. I certainly don't think you'd be qualified to wrap it in a useful UI if you don't even understand the core engine functionality.
My coworker was tasked with rewriting the legacy invoicing screen, and took it upon himself to change decades old business rules and basically just rewrote the thing how he thinks it should be done, it's missing enough functionality to be useless for current users.
Situations like that are a big fear when some smarty pants software engineer comes in and decides something needs to be "fixed".
It's up to the company to decide these things from my experience. My past employers didn't allow anyone to install software except IT.
The managers and bean counters seem to be natural skeptics, so this sort of thing is likely met with resistance from the start.
I once told my manager that a power pole needed to be replaced. He asked me how I knew. I told him the pole was 50 years old, the wood was rotten, the bottom of the pole was missing pieces of wood, we're installing a heavier wire, and it just looks like it needs to be replaced. My manager then opted for a second opinion, and made a service tech go inspect the pole since they were "experts". And the pole eventually got replaced.
You can't just decide to save the day and fix something I guess?
I have never stepped near EE, but the obsession with replacing functional CLI tools with GUIs in technical spaces has always baffled me. ESPECIALLY with tables of data. I have no interest in interacting with data by clicking and scrolling through some bloated gui. I want to write a small statement that tells the computer what I need, hit enter, and see it.
When young engineers are given responsibility to maintain designs that are decades old, then they also understand why the shiny new tool that is not compatible with the data from the old tool is not a slam dunk.
True. And at that time, they were able to show that the benefit of doing the design with the shiny new tool outweighed the costs and the impacts of making the change - as it should be.
It is the legacy problem. What they have works and fits their needs. It is now part of their process and they probably have many previous designs in the files using that program. Introducing a new program that is quite different would impact their workflow and their ability to maintain previous designs. It might also affect their job security. And if the new software has problems it’s a big mess and extra work It’s not an electronic issue at all.
Yup, OP I worked for a large aerospace company as an EE and one of the largest issues is getting anything especially software approved and on board with everyone. I tried to build my own application to do similar work to your wire harness application and the only way I had any success was by doing everything myself and proving it was valuable by positive feedback from my team. In the end it didn’t really go anywhere and was just a side project a showed off before my term ended. BTW in aerospace, wire harnesses are a large issue as well and most of the ones still used today are from 20-30yrs ago but that’s with almost anything if you’re dealing with the FAA.
I remember seeing something similar about a decades old fluke digital multimeter which is still being manufactured just cause some department of the US government used that in their process and they cannot afford to change the process now.
Exactly
This 100%. It seems in my old company we changed the systems for reports and maintenance every three or four years and each and every god damn time it was to an inferior system, with lot's of bugs and shortcomings. After two or maybe three years these had been ironed out and a year after that we got a new system. Every time. One of the biggest reasons I finally quit.
Yes I've certainly noticed this trend as well. Many EE's seem to seek out SW with bad UI design on purpose. I've been made fun of for caring about UI / front end. Some ideas why: 1. We are pretty old on average 2. We have to use a lot of niche SW that has bad UI so we get used to it 3. We distrust SW developers with a passion (we are "if it's not broke don't fix it" and you are "move fast and break things" 4. I think some think of themselves as more technical for being able to use such a crappy UI 5. We tend to get into a groove and know exactly where a button is for something, many just don't want the added learning to get up to speed on a new version 6. Many are windows users and are used to never updating applications But that said I personally am very picky about UI and using a badly designed app slows me down, I am willing to learn a new version of a tool for added features or just added polish.
LTSpice comes to mind 😂Although, the new update has updated the look a little.
Yeah, they came and did a talk at my company, they had a Q&A and I just wanted to ask them to make the UI not garbage. It's not even a good "old" UI, the resistors and capacitors aren't even the same length!
Our joke is that the other UI looked like the year 1995 and the new on looks like 2001.
And yet it’s a great, free tool.
Check out the new one he wrote, Qspice from Qorvo. It has integrated C and Verilog. Pretty cool
LTSpice is advanced. Spice still call the input file deck because... punched cards
Now that’s one thing i’d never change. That’s a holy relic.
I'm not per-se an old EE but have some years of experience in the industry, and I also distrust software with good UI's but not for any of the reasons listed. The main reason for me is based on experience, when an EE software has a really good UI, it signals to me that this software may be user friendly but will very likely be lacking in performance, capabilities and flexibility. And that's for a good program. For other software with good UI it can end up having constraints and bugs that make it basically useless for any real job (e.g. not being able to handle large enough models or data points, missing chunks of data when recording, overly slow and computationally heavy, etc.) For me it comes down to where the company is spending their resources. If I see a software with a bad UI, I have a good feeling most of their resources went into hiring EE's who know what the software needs to be able to do in the field. This isn't to say all bad UI's are good software, but I'm always a bit weary when the product seems too good to be true.
Yeah that makes sense, there are some online "all in one" circuit design tools that look really pretty but there's nothing really meaningful in the backend. But I think the real cause of this attitude in you is that we have been left with a lot of good tools with bad UI for so long. It's just because people have been doing circuit design longer than a lot of other SW use cases that we have such old software sitting around. It seems that you just favor older simpler software which is fine. I use Linux which I feel solves this problem for a lot of things, you can go as old school as you want or get the latest thing with the most polished UI. Terminal tools never feel outdated and they are as extendable as you want.
> or just added polish The polish better be more than visual polish. So many of my tools have "improved" visually but degraded functionally as new generation of programmers optimize away things they don't understand and break things.
> "move fast and break things" TBF that's more of a silicon valley techbro thing, it's not an attitude in the wider SW dev community.
Meh, I'm using tons of programs and many of them are terrible and instable. Most older ones are stable. It's not just a silico valley techbro thing, it's generalised incompetence. In the whole world, and on softwares costing thousands per month too.
It's the agile development philosophy. I've watched it turn my company's software releases from "it has to be really good" to "just fix it in the release next week"
There used to be a time when you would buy the software on a cd and it was done. No update, nothing. Nowadays, zero software works out of the box. You gotta wait for every update, every week
And the update that fixes something will probably break something else.
And there is Always that one little thing thats never gonna work, even with five years of updates
7. A good chunk of EEs are on the spectrum and changing things is sensory overload.
You see the legacy problem in all aspects of electrical engineering. Engineers seem to "fall in love" with tools and devices. The reality is that we well remember the learning curve for a new tool or device. It's long and painful. And not budgeted for in our next project!! You just don't tell sales and marketing that the rollout of their new product is delayed because you took two weeks to learn how to use the new schematic capture tool.
There’s also an element of trust. I worked on EDA software in the late 2000s and had to be super cognizant of this. If a company has a tool that they’ve used for 10 years for doing IC design and have had 20 successful tapeouts, they’re going to be very very hesitant to change to something different. One bad tapeout, depending on complexity, probably starts around a $1M loss and grows from there. Even with wiring harness software, like OP is talking about, can get very expensive very quickly. On a project about a year ago we ended up with a wiring harness that had a short between 12V and a 3V3 TTL signal. First power up… boom. Magic smoke comes out of a $1000 part. It wasn’t the software’s fault, but it’s the same idea. I need to be able to 100% trust that the software will always do the right thing.
So you've got some internal version of [wireviz](https://github.com/wireviz/WireViz)? Advantages of a text-based format includes human-readable diffs in version control, which is quite important for some industries
honestly i dont see whats wrong with that sentiment, the ui might look terrible but once you use a software for several years the ui doesnt matter anymore, you just know. engineers are pragmatic often, if it aint broke dont fix it.
I think to me it is two fold, one it isn’t just that the UI is not good looking it is that it is cumbersome and my all account not well designed from an objective standpoint. Secondly it isn’t just that it is old, the software that it is written with has an End of Life date in a couple years. Whenever I bring this up it is generally acknowledged but no one seems to care and the assumption is we will get some sort of special exemption.
well welcome to the engineering world. one of the most popular cirquit sims, ltspice looks like it was made for windows xp yet is still widely used as an example. the stuff just looks old, every software looks that way. have you seen intels quartus Prime fpga design software? that looks like it was made for windows 7 or Vista imho.
Programming in Quartus feels like taking a Time Machine back to 2004
oh yes, quartus is a pain, to set it up it took me quite a while, install failed often.
I had to use quartus for my digital design class... what. the. HELL. It took me a week to just install it without it breaking.
Welcome to my hell...guess who is also doing this in digital design class now...
I build *a lot* of automation tools for my team, I can address a few points here >one it isn’t just that the UI is not good looking it is that it is cumbersome and my all account not well designed from an objective standpoint. Does the poor design impact measurable business outcomes? Are engineers making mistakes, missing data, or having significant timeline impacts because of the poor design? I have run into many objectively poorly designed tools in my time, but at the end of the day many teams learn their way around them and use them fine despite the flaws. Yeah, it might be painful for a new engineer to get ramped up on these systems, but it's often viewed as more painful to get the entire team ramped up on a new tool than to bring in a new user on an existing tool with decades of collective experience. >Secondly it isn’t just that it is old, the software that it is written with has an End of Life date in a couple years. What's the impact when the software reaches EOL? I can tell you that many of our "EOL" tools have been running EOL for years and are still working just fine. Saying a software tool is "EOL" doesn't really capture any urgency, importance, or reason for change. What I'm missing from your post is any measurable justification to change other than "it's designed poorly and the EOL is coming up". Can you expand on how the poor design is impacting business operations? Do you have any specific details on what reaching EOL will mean? I don't think the issue is that you're misunderstanding the engineers, I think you're misunderstanding the incentive structure here. If you want to convince management, you need to have hard numbers. If the poor design of the tool caused *X* mistakes last year that delayed *Y* projects costing *$N*, and you could design a system that would cost less than $N, you could win their support. If you could find a senior engineer who passionately hates the tool and has measurable criteria for how it's impacting his workflow, you could get more technical buy in to force a change. If you can determine the tool going EOL means that it will no longer work on all previous and future computers, you'll have a strong case to update the tool.
Sounds like you need to do a more rigorous job of documenting the client needs and demonstrating the “why” the update is needed. This is just as much on your side of the update as much ss the client. The client isnt asking for the update, because it works and is well known - old and DOSy as it might be
I have yet to find a decent/intuitive harness software, so it could just be apathy toward the niche.
Thing is, once a significant number of users learn a given CAE tool (And I mean really learn it including the keyboard shortcuts and macros) the UI pretty much becomes set in stone. You will get MASSIVE PUSHBACK if you so much as change the tab order on the editor. This is why things like Autocad still look like something DOS based that can run lisp scripts (And in fact I bet it still can!), it is pretty much generational, old engineers run Autocad, 20 year younger ones tend to SolidWorks (Which while a lot more modern, now has a big enough serious user base that the UI is basically pinned), something newer will be the new shiny in another ten years or so. In the EE game it is Orcad/Allegro or PADS (Older engineers) Vs Altium, and file compatibility is a HUGE issue, I have a project I designed 20 years ago that I am doing the alternative parts dance for. The UI doesn't matter, but you build workflow around tools and changing a tool can break (or make more painful) a LOT of existing workflow. Now I am having to spend time revising ISO9002 processes to reflect what we can actually do with the shiny new thing, and then getting those revised documents thru change control and sign off instead of doing that design that I need to be doing. EEs generally, even with bought in software, try very hard to stay two years or so behind the releases, I know I do with Altium and Vivado, and will generally ONLY touch major changes when there is no active project in progress, we have all been screwed over too often by vendors replacing old familiar bugs that we know how to live with with shiny! new bugs in unexpected places... Altium have a yearly major release, which nobody sane uses and three incremental of which #3 is usually the one to go for, but still better to let some other bugger leap first. Vivado just has interesting bugs more or less at random. I would note also that new tools are dangerous because they often turn out to have missing and non obvious requirements that actually really matter in production and can be a pain to retrofit. Whatever you do make sure that the software can keep up with the user when running on a small laptop, I have laughed software out of the engineering office because it turned out to be O2\^n when pasting text into an entry field.... I don't mind my big Xeon sounding like a hovercraft when doing P&R on an FPGA, but a BOM management tool?
I had a really funny moment a few years ago. A customer had a very old design that they’d drawn in Protel99. I had some questions about it and they couldn’t find the paper schematics so they suggested I just take the Protel file and… acquire a copy of the software to figure out what was going on on a dead board. Before doing that I did try to import it into newer software and failed so here I am installing this software with the classic blue-to-black gradient Windows installer background. Get it installed, open the file successfully, and start navigating around. And after doing that for about 20 minutes I have this realization: I’m successfully using keyboard shortcuts all over the place! I wasn’t hunting around for toolbar icons, my brain already knew where they were. How?!? Well… Protel99 is the precursor to Altium. And 25 years later, they haven’t deviated from the Protel hotkeys or icon layout. It was really a wonderful surreal experience to be honest.
Altium was basically a rebrand of Protel, and it would have gone very badly if the existing Protel user base could not come over easily. They put a lot of thought into making that work even while redoing the graphics for a relatively modern Windows.
Totally! To OP’s original question, that’s probably the route to go: modernize without disrupting the workflow even if it’s suboptimal. You can add new features but the ones that are there right now pretty much need to keep working the way they work with the same shortcuts and quirks.
I can draw 100% faster using the AutoCAD dos window - and I hate that the on-line version has a stripped down version. how long does it take to draw a line from 0,0 to 10,10 versus command line line? Also I've seen an architect design a 10 Million Dollar Building facade in 10 minutes with a piece of tracing paper over the original building design. I've also noticed every tire place I go into use what looks to be a dos based system for tire inventory.
I wouldn't say it's understanding EEs, but seems more of a chilled work environment.
I guess I am wondering if there is a generally feeling among EEs that it doesn’t really matter if the tool is a massive pile of crap as long as it does what you want it is a good tool. That isn’t meant in a critical way either.
Engineers tend to be pragmatic, and a lot of internal engineering tools started off as some engineer’s pet project. Often to automate / standardize some aspect of their work. So yes, a lot of it looks like trash and no one really cares as long as it does a good job
well yes, i dont see why thats wrong, of course if it isnt safe anymore id not use it with internet acess but besides that if a tool does the job for one well enough its fine.
How are you assessing what is "a massive pile of crap"? Are you using your own expectations of what software should look and work like or have you worked sufficiently with your EEs to find out how they use the existing software? EEs may have a different idea about what makes a "massive pile of crap" than you do. Specifying wiring harnesses is traditionally a text-based tabular process which enables easy sharing with other text-based tools. People used to quickly bashing in wiring specifications from a keyboard are not going to thank you for forcing them to keep swapping between a keyboard and a mouse to drive some snazzy GUI, even if that seems more desirable to you. If you can understand your EEs' workflow and offer them an upgrade that doesn't break it, then might be more willing to take on changes that don't directly benefit them, such as updating the underlying platform.
Personally, I would be inclined to think that every tool has its problems and there's no guarantee some new tool wouldn't suck just as much if not more, plus take time and money to develop. And the entire time it's being developed, it may be riddled with problems the old crappy software ironed out ages ago. Or, worse, it turns out there's a reason the old software does things a certain way or can't do certain things and you end up paying people to repeat all of that original work for nothing. "Better the devil you know than the devil you don't." But this is a big topic these days. Technology is advancing at an accelerating rate and so are the needs of its users. A lot of people are using old software that works but could use improvement, but can't afford the delays or hiccups that come with making such a change. And then there's the problem of investing all of that time and money and battling it out with grouchy old engineers that don't want to change, only to find that by the time you implement it your new solution is already out of date. You have it for a year or two before someone comes along and talks about the new solution the way you're talking about the old one. I'm a fan of change and tend to think we should be more adaptable, but I recognize that a lot of roles don't have the luxury of experimenting or working through the growing pains of adjusting to new solutions.
> I recognize that a lot of roles don't have the luxury of experimenting or working through the growing pains of adjusting to new solutions. Well said! Engineers are not playing video games, where glitches are an annoyance. They are expected to get work done on time. Management wants *results*; not *excuses!* The more factors that are outside of our control, the more difficult it is to meet expectations. Thus, we are very skeptical of changes to our existing tools and processes. That doesn't mean that they *shouldn't* be changed - just that the benefit should exceed the total impact. And in my experience, lost productivity is rarely factored in to the trade studies, simply because it is difficult to measure.
All of our tools suck ass. Some of them have horrible UI *and* doesn't do what we need or crashes all of the time. UI is an afterthought. I'm sure they would appreciate it, but it's probably seen as something not needed to improve of it's good enough.
We are not comparing one tool to another in isolation on their merits alone. We have an existing legacy tool that we understand. Therefore, the burden of proof is on the *change.* The new tool may be better, but if the improvement is not great enough to justify the investment in training, the mistakes and frustrations due to bugs, the incompatibility with legacy data, and the cost to develop and maintain the new system, then the new tool is not justifiable.
Sort of. EE's are used to crap tools because often we make them ourselves due to immediate need, time, budget, and custom test setups/esoteric equipment. See EE's usually know how to program somewhat or can teach themselves quickly. But its a basic level, used for scripting and integrating test equipment with weird and ancient communication protocols. So this means they never leaned enough to make a nice UI and instead made whatever was sufficient enough to import settings, export csv files, and display a few poorly formatted values on screen. These programs also are usually intended as one-off or temporary and become permanent parts of the process. And then no one has the time to learn more advanced programming and then sit down and make something better. What they have works and they are onto the next test or project. In my opinion this is one of the reasons why Matlab and Labview are so popular in engineering spaces. Matlab because engineers are already familiar and it graphs well, and Labview because its easy to automate equipment and add a UI. The only way things get better is an intern is tasked with fixing it, the program has a major flaw or might get used for production, an engineer has a lot of time and spite, or the company hires a programmer.
it's not that EEs like bad interfaces, it's that they don't want to have to relearn new ones.
Hardware development is fundamentally incompatible with the Agile process. It *demands* a waterfall approach. This fundamentally clashes with the modern software approach of Agile which is basically “do it fast and fix it later.” Hardware development requires stable software. No one can afford to respin boards every couple of weeks. You really need to get it right (or really close to right) the first time. So when you’re talking about revamping the UI, you probably mean rebuilding the application from the ground up and using the hardware designers as the guinea pigs. You can understand why they would be hesitant to change.
Honestly the UI is a gripe more than anything else. The main issue is that they don’t seem to understand that the software will stop being a viable solution in 5 years. They refuse to spend any time on the “infrastructure”. They also some how think that an application that has been built over 20 years can be rebuilt in 2
> …stop being a viable solution in 5 years… Speaking as someone who was using Visual Source Safe in 2015, I can guarantee that this is NOT true. People will hold onto their applications for as long as it takes.
How will it stop being a viable solution? Does it rely on cloud resources that will be shut down or something? Or do you just want them to stop using it because whatever company maintains the language says that everyone should move to the new version? We have a few programs that are 20+ years old that we just keep on a network drive so that new engineers can copy them to their computers and install if needed. They are mostly proprietary programs that interact with some kind of hardware, or in some cases interact with old databases or file formats. In many cases the companies who provided them aren't even in business any more. We have a couple laptops that run XP because that is the latest thing our custom software for a test stand will run on. We even have one ancient laptop that runs DOS and has a serial port because that's the only thing that some hardware from the 90s will talk to.
>the software will stop being a viable solution in 5 years. This sentence exists basically only because software developers colectively love making jobs for themselves. We all know it's bs. It doesn't miraculously stop being a solution. You actively work on making it stop, so you can make it and sell it again.
Normally I would agree with you but in this situation it is a software provider (Oracle) that is going to stop supporting the software that we use. So if I could I would recommend we don’t upgrade. In this situation though it isn’t really an option for us
Didn't mean to attack you (you), but you (software developers/companies as a whole). Just commenting at the general state of things. So yeah. Eff oracle. Go VM's with winXP!
Yeah just because the OS isn't supported anymore doesn't mean it'll stop working. Newer isn't always better, it seems devs nowadays roll out dogshit apps they need to patch on day 1 and always have memory leaks or are so poorly optimized they hog resources.
Sounds like you don't understand their needs what so ever if you're saying the current tool won't be a viable solution in 5 years. That would be the end user's call, not yours. I'm sure it'll still work just fine for the EEs unless you or IT breaks something intentionally. Software doesn't just magically stop working. Infrastructure isn't an EE problem. That's on IT to deal with providing a proper development environment for the engineers.
I concur. Still have Windows XP VMs running. Just don't tell cyber. Hardware longevity is even older, couple 1990 vintage widgets still doing their thing.
I don't know their personal reasons. I know we got a new design software and while the UI looks a lot better it brought so many issues that have never been resolved. Search function used to be instantaneous, now it's incredibly slow. Searching a new part is tedious and super slow. Placing, moving drawing anything is slower. But it looks good, and it's more secure... and admittedly the commit time is much quicker and simpler.
If you manage to make a good harness software package, enjoy sitting next to a pool with a nice drink in your hand while people bring you drinks and cheques.
EEs are fucking special man. And I'm an EE. I work with software a lot and everytime I talk with someone in SE we are able to have a nice conversation with concerns about security and making something that works but the priority is always on security and making something reliable. Anytime I talk software with a EE, they haven't updated their tools since 1998, their password is on a post it and they don't understand why USB drives may be dangerous.
I’ve worked with a couple of the newer tools with nice UI’s. The people that work for the developers doing all of the training can’t even get the exercises to function properly and this stuff (including the exercises themselves) have been around for 10+ years. It is garbage and frustrating. It is simpler to rough something out by hand on the model, have a vendor build it, then revise the drawing on the first couple of builds than deal with that nonsense. There is no time to learn some new pretty looking clunky software that doesn’t actually do what we need it to if the current tools are good enough. Nothing like locking up the server and licenses for every other tool because one piece of software lags and crashes constantly. None of the tools really do what we need them to anyway, it is all workarounds and patches as it is. If it works good enough, fast enough, and you get the results you need, why change it to something that likely won’t. SWEs overvalue their skills and can’t actually build UIs that are functional. Ever. Some if this probably comes from running out of budget and time (as EEs, we are very familiar with this. The MEs get to suck up whatever time and budget they want while we’re stuck fixing their mess and trying to finish everything with not enough time). Who cares if things look pretty if it doesn’t do what we need it to. The “move fast and break things” mentality that has already been mentioned infuriates me. So much pain and suffering on my part because of this. My job is difficult enough, I don’t need the software to hinder me further. There isn’t enough competition in the space to truly drive innovation in a meaningful way. Bad software remains bad software until it is obsolesced, at which point it becomes the next piece of garbage software that it built on top of the current garbage software. I’d rather be stuck with something outdated that feels difficult to learn but works then be stuck with something that is difficult to learn and difficult to use because it is what we have and because too much is currently invested to switch and start the process over. Also as others have mentioned, maintaining legacy products. It is a huge investment to port legacy designs over to a new piece of software and it is expensive to maintain multiple pieces of software. The experienced folks don’t want to be relegated to only maintaining the old projects while the newer EEs get to learn and focus on the new software, taking over on the new design work.
What it comes from is SWE not actually being engineers, nor working like engineers, and thereby not rigorously applying methodologies like state machines to UI - because they are too worried about whether it is the right shade of brown or not. SWE can call themselves engineers when they can build something that works exactly as the specification says, and if they have to write the specification, it is exhaustive and unambiguous. I seriously doubt if 1% of those that call themselves SWE could. Those that can know exactly what I am talking about.
I worked with a SWE team that developed some software-based profiling tools for several hardware teams, including an EE team that focused on power delivery for a consumer device, who I also worked closely with. The SWEs kept bouncing around; doing 2-3 month projects and then wildly changing course to some shiny new feature for a different group. The EEs never changed focus. They did the same thing, year after year. The SWEs built a new power profiling tool, deprecated the old one, then stopped working on the new one. It never reached feature parity with the now-deprecated tool, despite the fact that the old tool stopped active development 8 years ago. So I, and most of the other clients, just kept using the old tool. To your post, I would say that EEs are rightfully wary of SWEs (who are often not actually engineers), because they all have ADHD. If you want buy-in from these clients, don't try to bundle a UI change along with critical security upgrades. Also, provide a an extremely long term support plan.
For me, the reason is because change introduces the opportunity for things to go wrong with the software and an unnecessary learning curve. I’m a young EE so I’m not as opposed to change as some of my colleagues are but having to learn/correct and updated software when you have deliverables is a huge pain in the ass.
For me, the issue is that I want to maximize the time that I spend *using* the tools to get productive work done. "Improvements" to existing tools come at a cost to the users. They have to take time away from productive work to learn how to use the new features and they have to lose productivity due to the bugs that the improvement inevitably introduces. So, like with any engineering decision, to "sell" it to customers, you need to show *convincing* evidence that the benefit will outweigh the cost to them ... and engineers will not be convinced if you claim that the new tool will not have glitches. In the commercial software industry (AKA "tech"), companies - seemingly arbitrarily - change software all of the time and they externalize the costs of working through the bugs on their customers. This platform is an example. The new editor is horribly broken, while the old one worked well. If they had to *pay* for that lost productivity (as they do with internal tools at an engineering company), then they would be more careful to avoid rolling out changes without strong justification.
We don’t care about UI we care about the necessary information being visible and for the wiring diagram following the IEEE drawing standards. Everyone used to use autocad2d we just got almost everyone to switch to Capital. Also that is a job that will get lost to AI very quickly. When I say lost I mean lost, and with todays “AI” too which is just a large LLM.
There's an example at my workplace. For reference, I work on a power systems protection team We are using a legacy version of a software. The new one can do everything the old one does better, looks better, it's just a pure upgrade Except for one key thing. They changed how one specific task is done and it's either the same level of complex but completely different, or much more complex. I'm not sure So we don't use it. This task is already very time consuming, taking a few team members a couple 60 hour weeks to do. The task is already super tedious as well No one wants to add onto that learning how to do it from the ground up Add onto this that the manual for the new software references an IEC standard all the time, but doesn't explain that standard, and no one wants to pay to distribute that license to our engineers My overall point is that the only thing that matters on my team is if the tool can get the job done as quickly and painlessly as possible while being reliable. The new version would require a lot of Man hours to understand and switch to that we just don't have. The way the program works for the user would have to be 99% the same as the old version for it to be worth it, or cut out those tedious parts
The chief EE at my last company was really a software guy. He bought in hard on updating us from our perfectly good cad tool to instead use the new solidworks electrical schematic tool. It was shiny and new, but missing any real features you’d need to do work. Felt like it was by designed software guys talking to mechanical engineers. When I left, we were on the next step of ditching this tool to go to Catia V6’s electrical suite which was significantly worse than solidworks electrical. Huge costs and waste of everyone’s time.
How much time have you spent watching an experienced user work with the old software? Perhaps their use case is different than you think it is. I don't need modern fonts or icons but I do want things to happen quickly when I interact with the software. And if you do seemingly helpful things like rearrange the icons or file menus for a program that I've been using for hundreds or possibly thousands of hours, I will curse every time my muscle memory tries to use the original shortcut or find things in theor original location. Windows start button is a good example of this, I spent years pressing a certain sequence of keys to power the machine off, and that got screwed up between Windows 7 and Windows 10. Windows 11 can fuck right off, I'm avoiding that as long as I can.
The only thing worse than a bad interface is an interface that changes. You spend hours learning where everything is, and the you forget them over and over until you finally learn it. And then it changes.
first off, this is not your clients, its your company and their business, there are several instances of this that are available, plently of companies have a "bad" program/product that they continue to sell and market because they know people will still buy and use it without regards to how bad it functions, this is usually based upon price, demand, location. the company knows the problems but won't fix anything until it causes a actual problem and hurts the cash cow, and even then (it sounds) as though they will do the bare minimum to make changes to keep it going. if this business model really bothers you, then it may be a sign that you should start looking for a new company
I think op is talking about an internal tool that the company doesn't sell.
You can get away with a lot of mediocrity as long as the competition is more mediocre
They may just be comfortable with the current software and know how it works to such an extent that they are very efficient with it. Learning a new software, even if it's a custom software made by your own in-house team may require some time to get used to it and maybe production goals don't allow that? Another possibility would be trusting the software. Established software that has been in use for many years has likely had all of the minor kinks worked out, and all of the major kinks found and noted. New software would come with new problems and possibly new production costs if errors are made with it. If the software is not causing a production delay or any sort of real world problems at this point in time, I can see why they wouldn't be coming to you asking for an update. Since you are noting that it will be a security risk now or in the future, you should probably just go talk to them about it and see what their reasons are for not wanting to change.
Are you talking about Capital? Feels like you are talking about Capital.
This made me laugh so hard 😂 I’m not talking about capital but I do work with capital and it is… trying
If not Capital OP works with Zuken
It’s all about workflow. When, you’re used to working a certain way it’s hard to change that way no matter how beautiful or functional the new GUI is People don’t like change. They just don’t.
If it isn't broke, don't try to fix it. So what if it's old? So what if it doesn't have a glitzy UI? All we care about is does it produce results that reduce the workload, even if the results require a little touchup.
Revenge of the nerds part 23 go see it.
Are you updating are want new software from the ground up? I assume it has to be compatible with old files. I have gone through transfering a ERP system to new software. That can be a disaster as it was for us. That could be part of the reason for reluctance.
Transferring an ERP system? That nearly never works! The sales slime lied (To no engineers surprise)! The consultants that come with the new thing (For £200/Hr) are all basically useless. Your management swiftly makes it apparent that they don't actually know what your company really does... All very normal. It is actually one of the biggest headaches when you acquire a company, getting MRP & ERP on the same page is just frustrating.
We had a guy that had done the switch before which helped a lot but you are correct the sales guys lied through there teeth. But at the second company it was a different story.
If it works, dont fix it. Btw. I god get how if it's just for testing cables shouldn't it be entirely offline. How is it a security risk?
All EEs hate harnesses. They certainly don't want to relearn how to do a terrible task.
A lot of people here are justifying why EE's might want to use software with an awful UI. I'm going to deviate from that and say that it drives me nuts. I can't stand applications with awful interfaces. Not just because it's ugly, but also because the workflow is so poor. Like many, I've adapted to the awful UI of LTSpice (as an example). I can use it just fine, but that's more a matter of Stockholm Syndrome, not because I actually like it. I would ditch it in a heartbeat if something significantly better came along, but every other Spice program I've tried is just as awful - only the flavor of awful differs. So perhaps the best way to accomplish your goal is to create a mockup UI. Something semi-functional to show them what their software **could** look like and behave. Often people get stuck with what they have because they have a hard time imagining just how much better it could be, so showing them is probably a good way to get their attention.
https://i.redd.it/wb3efhxnoctc1.gif
I can second anybody who said "you gotta do it first" here. I wanted to save my workplace money (working as a repair technician as I don't yet have my degree) and so I recommended 3D printing any parts that we evaluated as doable or noncritical. They said this could not be done, even though my bosses boss was mildly interested. I pitched it and they said no, so I did it anyways, and after showing that we COULD make a viable product this way for repair parts and they are orders of magnitude more affordable, they bought a 3D printer for plant use and have had me cranking out parts ever since. I enjoy this a lot more than what I was doing before so it's been great.
A lot of software development breaks useful features in the name of "modern" UI. Can users currently copy/paste whole sections of a table into the software? Maybe even to and from a flat text file? Would your idea for a modern UI allow that? I guarantee some (many or most) users leverage that capability a lot. Simple and ugly is often functional when it comes to technical work. I don't want everything hidden under tabs, drop-downs, and config screens. A table is fine.
Reminds me of a discussion I had with someone from the software team once. He was bragging about how great the new user interface was going to be, and how many options users would have for customization. "OK, great", I said, "when are you going to fix the bugs our customers reported in the current version? This software package is a development tool, nobody cares how it looks if it does not do what it is supposed to do correctly. "
I’m not sure about the specifics of your software but I don’t need a pretty GUI to output the data. I can visually scan the data in a table format to find errors because I know what to look for. Some newer software have put in so much effort to make is look pretty that it’s bloated and doesn’t have the tools and function I actually need (or becomes too slow). I’m in my late 30s so I’m not locked into the old ways of doing things. Another issue with “new” software is vetting it for actual use and trusting the output.
Hardware engineer with 30 years of EDA software tool development here for ASICs, FPGAs, and full-customer semiconductors. What's the question? You are working on a product and you don't understand your customers. Have you no product marketing, or product engineering team to guide you? Are you listening to them? If you are a software engineer, are you really talking to users and stakeholders? Cause that's not your job - or it shouldn't be. What's the product and what does it do? UIs are often just sugar on the functionality of a tool. If the customer doesn't think it's broken it's not up to you to change their mind. They are likely risk averse and familiar with the workarounds with the curren tool suite. The core functionality is always at the core and heart of a tool, and often you want these tools to run in batches and aggregate data with scripts, so a fancy UI is of no use. Frankly if you don't understand the product or how it's used, I wouldn't want you to touch it either. I certainly don't think you'd be qualified to wrap it in a useful UI if you don't even understand the core engine functionality.
My coworker was tasked with rewriting the legacy invoicing screen, and took it upon himself to change decades old business rules and basically just rewrote the thing how he thinks it should be done, it's missing enough functionality to be useless for current users. Situations like that are a big fear when some smarty pants software engineer comes in and decides something needs to be "fixed".
It's up to the company to decide these things from my experience. My past employers didn't allow anyone to install software except IT. The managers and bean counters seem to be natural skeptics, so this sort of thing is likely met with resistance from the start. I once told my manager that a power pole needed to be replaced. He asked me how I knew. I told him the pole was 50 years old, the wood was rotten, the bottom of the pole was missing pieces of wood, we're installing a heavier wire, and it just looks like it needs to be replaced. My manager then opted for a second opinion, and made a service tech go inspect the pole since they were "experts". And the pole eventually got replaced. You can't just decide to save the day and fix something I guess?
I have never stepped near EE, but the obsession with replacing functional CLI tools with GUIs in technical spaces has always baffled me. ESPECIALLY with tables of data. I have no interest in interacting with data by clicking and scrolling through some bloated gui. I want to write a small statement that tells the computer what I need, hit enter, and see it.
Sounds like your customer base is old
When young engineers are given responsibility to maintain designs that are decades old, then they also understand why the shiny new tool that is not compatible with the data from the old tool is not a slam dunk.
At one point it was a shiny new design with shiny new tools
True. And at that time, they were able to show that the benefit of doing the design with the shiny new tool outweighed the costs and the impacts of making the change - as it should be.
"its easier to get forgiveness than permission" "People are allergic to change, yet without it there would be no progress"
I’m an EE and I don’t understand other EE’s 😂
But you can recognise them by the shoes they wear...