4 ms·
Quality assurance and software engineering can be applied everywhere, no matter the processes you use to create and deliver the code. Methods and tools would b
by hinata08 4y ago
Quality assurance and software engineering can be applied everywhere, no matter the processes you use to create and deliver the code.
Methods and tools would be different, depending on context, but ANY serious company ought to do quality management
At the very least, know your code, think a few moves ahead, make sure you deliver a safe code, and apply some amount of ISO9001 at the company level (and hopefully much more at any other level)
Also, a security analysis is mandatory for both industrial code and for IT applications, thanks to standards, laws like the GDPR its principle of privacy by design, and contractual requirements from serious partners. You risk a lot if your code leaks customer data or crashes a plane.
it's the same for having 'specifications'.
Call them functional and safety requirements, tickets, personas, user stories, or any name, but you have to do them to be able to work with the devs, and describe to your customer and users what you have actually developed.
the 'lots of things [that] cannot be' scare me as a junior engineer.
I feel like they are made by these shady companies that offer 2 interns and a junior, to get you a turnkey solution within 12 hours. It also gives me back bad memories of homework made at the last minute in uni, and I would never do that again.
And as far as I saw in both cases, the resulting software is painful to use or to evolve afterwards.
- PaulDavisThe1st 4y ago> describe to your customer and users what you have actually developed. In the domain I work in, what customers want (and what we provide) changes monthly at worst, annually at best. And in many cases, customers do not know what they want until they have already used some existing version, and is subject to continual revision as their understanding of their own goals evolves. This is true for more or less all software used in "creative" fields.
- hinata08 4y agoI don't understand how this practice makes your modern code more reliable, sorry I was replying to >Are modern codebases with modern practices less buggy than the ones from 20 years ago? I understood that @NayamAmarshe acknowledged about new practices and tools introduced after my examples, in the 80s, 90s, and early 2000s (mostly with agile everywhere, and v-methods becoming a red flag on a resume and in business meetings). It seemed to be the essence of their question. So all I was saying was that codes from back then where capable of being safe. Reliability wasn't invented by modern practices. Modern practices have only changed the development process, as you mentioned. Not the safety. And if it did, it affected safety, as doing provably safe code with new practices is still being researched at the academic level. (check out the case of functional safety vs/with agile methods) Can you explain how do you make your code less buggy, than a code from 20 years ago, with practices from back then ?
- PaulDavisThe1st 4y agoMy point was that you cannot use the software development processes used in planes and transportation systems in every area of software development. Those processes are extremely reliant on a fully-determined specification, and these do not exist for all (maybe even most?) areas. If you're inevitably locked into a cycle of evolving customer expectations and desires, it is extremely hard and possibly impossible to, for example, build a full coverage testing harness.
- hinata08 4y agoyup, 21st century practices for 21st century business needs but they don't make the code less buggy per se. They just allow to patch it faster.