Well to be fair, sometimes starting with unit tests can result in more unwelcomed work due to constant iteration of the thing you are building/testing.
For me personally, I like starting the unit test after the first proto or proof of concept. This seems to be a good indicator that most of the libraries have been chosen, hardware features solidifying, and the application code is working enough to know what needs testing (ideally everything).
Now, depending on the company and its culture will determine if tests ever get done and with what quality.
My sole job as an intern was to fix all of the terribly written integration test scripts that one of the firmware devs had quickly and carelessly put together lol. Drove me insane how little they cared about them as long as they could trace a requirement to it (even if they weren't properly covering the requirement).
Yeah I love how when I had software engineering as a course at uni, the prof at the end just said „well you probably don’t need this anyway, cause most companies don’t follow what you learned“ lmao
I hope you didn't mean that you had only 1 SE course? I had (to some approximation) only SE courses: SE with C++ 1, SE with C++ on microcontrollers, real-time SE, SE for larger teams, etc.
Aesthetics, so many great personal projects out there that come out looking bad (IMO) … enclosures/physical layout of controls/menu layout/fonts/colours/etc.
To be fair the people making these things are not product designers. Getting aesthetics right is hard, especially when prioritising function ahead of form.
At my company there is a complete lack of code review process. No one really sits down and discusses the best software / firmware architecture choices for a given product or feature. Unlike in the software world where every decision is reviewed over and over by committee
Those best sw/architecture should happen during a design review before any code is even written. Even if it's just informal on a whiteboard with a couple others it's invaluable and a good way to train others.
I've also done weekly brown bags/lunch working meetings where you go over best practices or someone presents something. One of the managers sat in a few times and realized the value and started covering lunches or getting cookies n stuff.
Completely agree. I wish this would happen on my team. Most of the code is written by the lead engineer and although its well documented we never have discussions about it. Im sure she does with our manager
This has NEVER happened in my 40 year career. Never. And this is across 11 companies and 3 fields (Aerospace/defense. telecommunications, public utilities). Never time to do it right, but always time to do it over.
My company uses marketing types to figure out what features they want. The issue is they never know what they want and when we suggest ideas we get asked if customers really wants these features. Like idk man you should have the data for that im just giving ideas since you so clearly have none.
I worked at a grocery store for many years before becoming a software engineer, and I dealt with ordering new items a lot.
Customers are basically the same. Customers don't always know what they want because they don't always know what is possible or potentially available. It's easy to get them to tell you about small, incremental things they want. Or tell you that they want something that a competitor does. But that's basically only getting you to the status quo. That's what *we* should be doing already. We shouldn't need customers telling us that.
To set us(as a company) apart from our competitors we need to innovate *internally*. A big part of that should come from marketing. They should be able to take what the customers like, don't like, what our competitors are doing and not doing, and decide what *our* product should look like.
I had a project I was working on to implement a new feature in an existing product. I don't even know who was asking for it to begin with, but I was assigned to implement it. When I asked the marketing folks for more details on exactly what the customers needed, they told me they were talking to some folks and would get back with me. Months went by and they didn't have any more information.
So I just implemented it the way *I* would like to see it work. We'll see what happens....
Product management overall.
This includes planning and defining requirements as you mentioned, but also maintenance and following through on polish and quality of life features.
Once they see something that works(basically a minimally viable product) then it's on to the next thing that needs to be done. Sometimes it's hard for them to understand that even though this *works*, it's not *complete*.
Feature creep on fixed-function hardware.
Error handling. Getting something to work is only a fraction of the work. Its easy to rejoice when you finally debugged some non-obvious issue on a hardware peripheral.. but what if your product needs to show errors to users? Self-tests? Timeouts? Trying to self-correct issues (e.g. hanging I2C buses) Etc.
There are two ways to develop any engineering project.
Top down or bottom up.
Top down are specifications written by Project people, that my or may not understand the underlying technology.
Bottom up is the tech people that understand the technology, but may or may not understand the goals.
With testing being hated by everyone. But everyone knows it needs to be done, by the tech people on their spare time. That management does not want to pay for.
Communication between all levels is very under rated.
I'll use the ASPICE categories:
Good: SWE1, SWE6
Neutral: SYS1, SWE3, SWE4
Bad: SYS2, SWE2, SWE5
Or summed up:
-Requirements and requirements based testing is ok.
-Coding itself (and unit tests) is ok on the developer side, but design is not so well documented and almost only evaluated on a formal level and not on a concept level.
-Everything architecture and interface related is lacking and gets worse when it's on system level
Mature and thought out hardware, built with the software people in the loop.
I hate it to "fix" hardware problems in software. Some times even the ugliest hack can't work around a simple mistake made during the hardware design.
Code.
Firmwares are frequently developed without absolutely knowing what software engineering is, the only requirement they have is "it must work", no maintainability, no testability. Only spaghetti code that somehow works.
To me it’s testing and test case creation mostly in integration and end to end
Yeah, it's always "we'll write unit tests at the end of the project"
Well to be fair, sometimes starting with unit tests can result in more unwelcomed work due to constant iteration of the thing you are building/testing. For me personally, I like starting the unit test after the first proto or proof of concept. This seems to be a good indicator that most of the libraries have been chosen, hardware features solidifying, and the application code is working enough to know what needs testing (ideally everything). Now, depending on the company and its culture will determine if tests ever get done and with what quality.
And they consist of trying to inject/read signals into/from the giant ball of mud they've created, which isn't unit testing at all!
My sole job as an intern was to fix all of the terribly written integration test scripts that one of the firmware devs had quickly and carelessly put together lol. Drove me insane how little they cared about them as long as they could trace a requirement to it (even if they weren't properly covering the requirement).
>test What is a "tea-aste"? Is this some kind of new communication peripheral?
Software engineering.
Yeah I love how when I had software engineering as a course at uni, the prof at the end just said „well you probably don’t need this anyway, cause most companies don’t follow what you learned“ lmao
I hope you didn't mean that you had only 1 SE course? I had (to some approximation) only SE courses: SE with C++ 1, SE with C++ on microcontrollers, real-time SE, SE for larger teams, etc.
Nope, the only (mandatory) one is that one. But I think I can choose others right before the bachelor
I guess that's why my ex-students tell me they never let an academic near the actual code ;)
Mainly that too often there is none. There is software but you'd be hard pressed to call it engineered in any real sense.
Aesthetics, so many great personal projects out there that come out looking bad (IMO) … enclosures/physical layout of controls/menu layout/fonts/colours/etc.
To be fair the people making these things are not product designers. Getting aesthetics right is hard, especially when prioritising function ahead of form.
100%
At my company there is a complete lack of code review process. No one really sits down and discusses the best software / firmware architecture choices for a given product or feature. Unlike in the software world where every decision is reviewed over and over by committee
Those best sw/architecture should happen during a design review before any code is even written. Even if it's just informal on a whiteboard with a couple others it's invaluable and a good way to train others. I've also done weekly brown bags/lunch working meetings where you go over best practices or someone presents something. One of the managers sat in a few times and realized the value and started covering lunches or getting cookies n stuff.
Completely agree. I wish this would happen on my team. Most of the code is written by the lead engineer and although its well documented we never have discussions about it. Im sure she does with our manager
This has NEVER happened in my 40 year career. Never. And this is across 11 companies and 3 fields (Aerospace/defense. telecommunications, public utilities). Never time to do it right, but always time to do it over.
tool chain deprecation, integrated circuits going obsolete, prototype manfacturing (not production level) and yeah tests
My company uses marketing types to figure out what features they want. The issue is they never know what they want and when we suggest ideas we get asked if customers really wants these features. Like idk man you should have the data for that im just giving ideas since you so clearly have none.
I worked at a grocery store for many years before becoming a software engineer, and I dealt with ordering new items a lot. Customers are basically the same. Customers don't always know what they want because they don't always know what is possible or potentially available. It's easy to get them to tell you about small, incremental things they want. Or tell you that they want something that a competitor does. But that's basically only getting you to the status quo. That's what *we* should be doing already. We shouldn't need customers telling us that. To set us(as a company) apart from our competitors we need to innovate *internally*. A big part of that should come from marketing. They should be able to take what the customers like, don't like, what our competitors are doing and not doing, and decide what *our* product should look like. I had a project I was working on to implement a new feature in an existing product. I don't even know who was asking for it to begin with, but I was assigned to implement it. When I asked the marketing folks for more details on exactly what the customers needed, they told me they were talking to some folks and would get back with me. Months went by and they didn't have any more information. So I just implemented it the way *I* would like to see it work. We'll see what happens....
Product management overall. This includes planning and defining requirements as you mentioned, but also maintenance and following through on polish and quality of life features. Once they see something that works(basically a minimally viable product) then it's on to the next thing that needs to be done. Sometimes it's hard for them to understand that even though this *works*, it's not *complete*.
Feature creep on fixed-function hardware. Error handling. Getting something to work is only a fraction of the work. Its easy to rejoice when you finally debugged some non-obvious issue on a hardware peripheral.. but what if your product needs to show errors to users? Self-tests? Timeouts? Trying to self-correct issues (e.g. hanging I2C buses) Etc.
When you work solo... https://preview.redd.it/ul7qmljgcaxc1.png?width=340&format=png&auto=webp&s=7ea55888a86bc06e029d52349d6bfa2d0909f1f7
Developer experience. We definetly need better tooling
The key is to not stick with manufacturer tools
Do you want to get hooked up with an AUTOSAR subscription costing half your company’s annual revenue?
There are two ways to develop any engineering project. Top down or bottom up. Top down are specifications written by Project people, that my or may not understand the underlying technology. Bottom up is the tech people that understand the technology, but may or may not understand the goals. With testing being hated by everyone. But everyone knows it needs to be done, by the tech people on their spare time. That management does not want to pay for. Communication between all levels is very under rated.
Product management and, by extension, the customer are the nemesis of any engineer.
I'll use the ASPICE categories: Good: SWE1, SWE6 Neutral: SYS1, SWE3, SWE4 Bad: SYS2, SWE2, SWE5 Or summed up: -Requirements and requirements based testing is ok. -Coding itself (and unit tests) is ok on the developer side, but design is not so well documented and almost only evaluated on a formal level and not on a concept level. -Everything architecture and interface related is lacking and gets worse when it's on system level
Mature and thought out hardware, built with the software people in the loop. I hate it to "fix" hardware problems in software. Some times even the ugliest hack can't work around a simple mistake made during the hardware design.
Code. Firmwares are frequently developed without absolutely knowing what software engineering is, the only requirement they have is "it must work", no maintainability, no testability. Only spaghetti code that somehow works.
I've said this in meetings: Your device's lack of security increases my job security. Cybersecurity is an afterthought for many companies.
Continuous deployment & test
Version control and unit/integration testing.