The graveyard of audio production equipment is littered with the corpses of products that had rock-solid hardware designed by professionals, but firmware written by nincompoops.
It's really frustrating when you buy a blinky-light box that some engineers somewhere likely spent thousands of man-hours on designing the best sounding DAC structure they could for the budget, but then the OS crashes when you accidentally try to load a file that's the wrong format.
To be clear, what I mean by that is they let EEs write the software.
HEY! There's a lot of profoundly good embedded software engineers out there with EE degrees.
-- Tim Wescott Control systems, embedded software and circuit design I'm looking for work! See my website if you're interested http://www.wescottdesign.com
Imagine how frustrating it is for the folks who know how to do it right but are blocked by management, on pain of firing, to do the up-front work before jumping into coding and debug. Particularly when you know that every up-front hour spent shortens the debug time by at least two hours.
-- Tim Wescott Control systems, embedded software and circuit design I'm looking for work! See my website if you're interested http://www.wescottdesign.com
Some are even Chinese!
-- Rick C
First hand experience or do you just like making up straw boogeymen?
-- Rick C
I hear that. I also think designing say a "computer-DAC" box is not an "easier" task than writing the firmware, exactly, but maybe a more "bounded domain." In some sense one computer-DAC-audio-box is a lot like any other, the specifics may vary but the solution will likely take a form that is reminiscent of similar things.
But for the software, does the codebase for say Cubase really resemble the codebase for Cakewalk? Likely not very much, even though they both are pieces of software that at the end of the day are used for the exact same thing.
They sometimes seem scared of newfangled stuff like OOP, "design patterns", "test-driven development", and "agile development."
It's okay. It's really not that scary! You don't even have to be afraid of all that "inheritance" and endless class hierarchy stuff, it's not
1993 and nobody gets paid by number of classes derived from anymore.
When I was in school, CS was taught *in* the school of EE.
As an EE, you learned how to design power supplies AND design programming languages. But, folks opting for the "classic" EE curriculum would spend far more effort in the former while folks opting for the CS focus spent more in the latter.
[In my case, I was interested in computer *hardware* so had to flip a coin as to which focus to pursue]
It is relatively easy to write a specification that defines the hardware's capabilities. Then, hand that off to someone who can implement it without further contact with the-powers-that-be.
And, easy to *verify* compliance to that specification.
Wanna *bet* there was no similarly detailed specification written for the software? Wanna bet the "coder" probably decided what the "program" should do, what the user interface should look like, etc.?
Early on, I opted for fixed cost contracts (instead of T&M) as it gave me a lot more freedom in what I did, how I did it, etc. But, the best aspect was that it forced the client to produce a clean definition of what he wanted/expected -- because that was how we would jointly agree that the contract's terms had been met!
When hammering out details of the "final" spec (always amusing how quickly the client considered the spec "finished" vs. how many holes remained in it!), I would invariably ask the client, "What do you want to happen when occurs?"
"I don't care" was a common reply. Of course, what he meant was "I don't know and I don't want to think about it!"
Of course, *I* know that whatever *I* decide should happen in that situation could easily be considered "wrong" by him when it comes time for sign-off... so, I *do* care about what is written down as the "contractually agreed upon" way of handling that situation.
I would very deliberately and seriously comment, /sotto voce/ "When happens, the device should catch fire/crash/explode/etc..."
Client would heat this (cuz I intended for him to hear it!) and exclaim, "THAT'S not what I want!!"
"Ah, so you *do* care! ..."
Would you sign a contract with a home builder agreeing to a price and delivery date -- but NOT to a detailed description of the structure he was setting out to build? Conversely, would you sign that contract with the home *buyer* without all those details present?
The problem is that since software implementations are ideally straightforward to modify, it's an expectation that it's possible to request modifications during the development process. It's part of the reason that we use software to accomplish tasks in the first place.
The requirements are expected to evolve during the development process; indeed a client may not even know exactly what their requirements are until they see a partially working product of some type.
At least the pure version of "waterfall" design like you might do with hardware isn't really possible anymore with complex pieces of software.
WHen I was in school, Computer Engineering was in the EE department of the College of Engineering. CS was in the LAS (liberal arts and sciences) college[*]. It may even have been in the math department but I don't remember when that changed. But CompE and CS were entirely different things.
[*] A few years before, when my brother was in EE school, CS was in the graduate college. There was no such thing as a BS CS.I took an EE degree but took all of the classes needed for CompE, so I could claim either.
there is also the opposite, where using the latest greatest half done pre-alpha languages, libraries, tools and buzz word development models they only understand half of gets priority over making stuff that actually works
There are probably four or five languages that came out in the past decade that have as their "mission statement" something like "To develop a language which has the ease of use, expressiveness, and safety of an interpreted language, and the execution speed of a compiled language."
People still use C++ a lot...
There is a fad cycle.
People don't like strongly typed languages because they are "too constraining" and "too verbose". So they invent yet another more-or-less untyped language.
They then find that they've lost the ability to: - inspect and draw solid conclusions about other people's codebase - use code-completion to speed typing and avoid mistakes - detect errors at compile time; they have to hope they can detect them at run time before their customers detect them So then they realise the benefits of strongly typed languages, and swap to the latest variant thereof.
Unfortunately by that age, the HR-droids think they are "past sell by date" and so they are shunted into middle-management positions or the dole queue.
First-hand experience. "Tell us you'll get it done by this date, with these resources, or you're fired."
To be fair, I've seen quality efforts shot down at every level in the pipeline -- but it's management's job to understand what it takes to make the next level down care about quality, and what it takes to at least give them room to deliver it.
-- Tim Wescott Control systems, embedded software and circuit design I'm looking for work! See my website if you're interested http://www.wescottdesign.com
When "reward" is tied to the WRONG "results" metric, its too hard to get PHB's to make the "right" decisions.
I watched a *system* (7 figures) shipped off to the customer AS A BOX FULL OF UNASSEMBLED PARTS (nor was the system completely *designed* at time of delivery) -- just so the boss could collect his bonus and promotion (leaving the next guy to take the hit -- reputation and "on the books" -- when the client shipped the box-full-of-parts back, outraged!)
Contrariwise, I've heard tales of customers /asking/ suppliers to ship them empty boxes.
Why? Shipped at the end of the financial year so as to use up a pot of gold, supplier corrected the "omission" at their normal lead time :)
Much like HP describing its desktop computers as "calculators", so as not to invoke customers' IT department's immune system response.
the "auto" automatic type deduction keyword available in C++11 onwards helps cut down on the verbosity a lot; I use it wherever possible, in C++14 it's even available for use to automatically deduce function return types.
In general:
Use stronger types. It should be inherently impossible to have -27000 pieces of gold, or be 34.73 years old, because C++ makes it easy enough to create a near-zero-overhead abstractions of quantities that reject the possibility, ideally with a compile-time error.
I think on a modern desktop environment at least there's little reason to use any underlying fundamental data types other than int32_t, int64_t, double, and std::string.
"What if the character gets really rich though, and int32_t would overflow?" Simple, don't put that much money in the game, it means the game's economy is broken. Or at least put a limit on how much can be stored in one place. Avoiding errors like that should be partly a design decision from the start, not just an implementation problem.
But, there, "everybody" wins; The Next Guy doesn't get left holding the bag so the previous guy could profit!
Or, calling the suspicious looking (XRay) device in your toolkit an "electric wire-wrapping tool" to avoid the attention of the security folks at the airport...
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.