Why do a lot of electronics engineers end up coding?

[John Coloccia]

Similar thing, but I was talking about actual "databases".  Consider an optical network management tool.  Pick data up from a incoming SNMP scanner, form it into entities and put it in a database.  Another part picks it up from the database, forms it into JSON and sends it to the front end via a REST API.  The front end consumes the JSON and create an Angular scope, the angular scope fills in the blanks in HTML.

I think the problem you are describing is moving data around in memory.  If a function in the Nth layer needs the customers locale to calculate tax on an order item, how do you get the data down through all N layers of function calls.

This problem is different in the OOP world.  The TAXCalculator object will be provided a reference to another object that knows where to get the customers locale.  That object will be injected by configuration.  As an back-of-envelope example:

Code: [Select]

class TaxCalculator {
    @Inject
    private CustomerManager custManager;

    public void calculateTax(List<OrderItem> orderItems) {
        Customer cust = custManager.getCurrentCustomer();
        Locale custLocale;
        if( cust != null ) {
            custLocale = cust.getLocale();
        } else {
           // panic and run round the room with your hands in the air.
        }
        for( OrderItem orderItem : orderItems ) {
            orderItem.calculateTax(custLocale);
        }
    }
}

interface CustomerMangager {
    public Customer getCurrentCustomer();
}

interface Customer {
    public Locale getLocale();
}
Depenency injection is fairly cool but it can be overused and can end up with very messy config.  However it allows you to profile the sofware and change inner components from config.  It also allows you to wire things directly into the Nth layer without having to pass the data all the way there, or make it global.

Remember in the OOP world the data and the code/behaviours are encapsulated together.  You don't consider data/variables and functions as separate things.  There are no such thing as data tables etc.

With C++/C#, the way I would generally solve more complex problems is at configuration time, with class factories and named objects. At initialization time, everyone just finds whatever objects they need. If Object A needs Object B, it just have a reference to a particular object B's name. But it's one more thing to build and debug.

Fortunately C++ and C# have all sorts of tools to make this easy. In the dark ages (20 years ago) there was an awful lot of stuff you had to build in C++ to make this work.

[tggzzz]

Depenency injection is fairly cool but it can be overused and can end up with very messy config.  However it allows you to profile the sofware and change inner components from config.  It also allows you to wire things directly into the Nth layer without having to pass the data all the way there, or make it global.

And that config is normally in a different language (e.g.XML) to the language used for the components (e.g. Java). That buggers the IDE's ability to tell you "what objects are invoked this object" and "what objects can invoke this object" (where object == instance of this class!).

If you think about it, DI is little more than a replication of the hardware way of thinking: a cabinet "wires together" several racks, a rack "wires together" several PCBs,  a PCB "wires together" several ICs,  an IC "wires together" several transistors.

If you then allow the (top level) cabinet creator to have direct access to the (inner components) config registers in a IC, you have the starting point for some config hell and interesting product liability discussions! "...but your system installer configed the IC's outputs to be HVCMOS not LVDS..."

TANSTAAFL. Pick your failure modes.

[paulca]

With C++/C#, the way I would generally solve more complex problems is at configuration time, with class factories and named objects. At initialization time, everyone just finds whatever objects they need. If Object A needs Object B, it just have a reference to a particular object B's name. But it's one more thing to build and debug.

More or less the same thing.  I have used named object factories in C++ before.

In some enterprise setups the objects might not be local.  Things like Corba, EJB or Microservice architecture the objects or services might be remote.  You use a registry service to find them.  You can even plug that into DNS and DHCP and let your objects go roaming around the world.

You can see this can be a nightmare to debug though

[paulca]

Generally software development these days is running into an interesting era where so many things have been done before and open sourced that often the first thing you do is decide what framework or engine you will use as the basic architecture.  Say for Java that might be "Spring" and the relevant, to your project, modules and sub-frameworks.

You then hang your stuff off that framework, hoping you don't run into any, "What do you mean I can't do X?" problems.

The downside with this approach is you get "Sledge hammer to crack a nut" everywhere.  Enterprise Java programmers become obsessed with reusing frameworks and design patterns out of their tool box or JAR library for everything.  So they end up solving simple problems with design patterns created for much more complicated problems.  This makes the software a lot more complex than it needed to be and a lot harder to support.

Completely off topic, but my day just took a turn for the worst:

internal compiler error: Segmentation fault

That's not going to be good.

[bd139]

Just a point earlier about dependency injection. You usually don’t configure it these days. It configures itself! You just write objects and use them. You only ask the container for an object at the entry point.

Frameworks I’m a fan of. Because someone else has done the hard work. I want to deliver business value and that doesn’t come from writing glue.

Enjoy your compiler error. I’m trying to persuade FreeRTOS to target something on ARM. I am considering giving up and moving the hardware to PIC24 and writing it in assembly.

[paulca]

Just a point earlier about dependency injection. You usually don’t configure it these days. It configures itself! You just write objects and use them. You only ask the container for an object at the entry point.

Frameworks I’m a fan of. Because someone else has done the hard work. I want to deliver business value and that doesn’t come from writing glue.

Enjoy your compiler error. I’m trying to persuade FreeRTOS to target something on ARM. I am considering giving up and moving the hardware to PIC24 and writing it in assembly.

Yep and you only need to tell the DI framework which type you want if there is more than one.  If it's fixed you can usually do:

@Inject(qualifier="ThatOne")

Of course for unit tests or integration tests you can override the qualifiers, I believe.

My bug bear is with people overusing complicated problem solving design patterns to solve simple problems.

I once worked on a project as a low latency C++ engineer and when the last person in a Java project left they dumped the project on my desk to support.  A behemoth of a java app that used every bell and whistle they could.  There was even dozens of examples of "Hobby Horsing", where they had used simple problems to delibrately design complex solutions to "play" with them.

My favourite was the double nested visitor pattern to select from 4 order types and 3 time limits on orders.  Visitor pattern is great for large diverse object lists with dozens or types that can be "plugged" at run time, so you don't know the types.  Not for a matrix of 12 known combinations.

Some parts of the software if you CTRL+Clicked a method, Eclipse would freeze for nearly a minute and present you with a list of 30 or 40 implementations.  The logic to select which one was a rat's nest of patterns.  In the end I used a break point and stepped in, but that required I build up a complicated test harness to replicate the original issue.

I called the developer many, many names those days.

There are people I know who would frown on any of the following:

if(...){
} else if (...) {
}

switch() { // anything }

if( a instanceof B ) {

}

"Do it with polymorphism and patterns man  if statements are so brittle and instanceof is an anti pattern!"

[bd139]

Agree. That particular case is why I like the pattern matching stuff in c#. https://docs.microsoft.com/en-us/dotnet/csharp/pattern-matching

The OO side of things works best for small concerns like iteration and algorithms. The actual system is served better by passing value objects around and using the classes merely for decomposition and encapsulation of dependencies. Much less coupling if implementation doesn’t cross boundaries. Also it’s a hell of a lot easier to test a concern reliably if the implementation doesn’t fly around across all isolation boundaries.

[John Heath]

Bottom up is sometimes used for OOP Design by starting with individual objects, behaviours and how they interact and building up the network of peers gradually, that then gives you ideas for your overall code architecture.  I don't think a lot of OOP developers think about it that way.  Maybe some of the more academically learned ones.  It's like designing a schematic by dropping the "main chip" in the centre and spreading the schematic out around it and making overall board layout, PSU etc as it presents itself to you.

The other "bottom up" concept is in analysis.  A taught, but seldom used water fall analysis method in OOP is to get a  written requirement summary text from a good business analyst and the customer.  It's often in shared language, which is just customer domain language but with strict terms definitions.  You then look for nouns and verbs and pull them out as objects and methods/behaviours, being careful to avoid "System" entities.  These form sentences in natural language, The requirement "A document can printed."  Translates almost directly to a Document.print() method.  These then get rattled around UML design software, almost like an EDA program.  Associations, collaborations and aggregations are linked out between them, so called class diagrams.  You can then generate object diagrams to show actual instances working together and then sequence diagrams to show the individual collaborations.   So you are starting with the core bottom objects and building up to seeing the overall picture.  On a big design you could have hundreds of views of the same underlying model.  Kind of like a 100+ page schematic.  These tools will then even go as far as generating your empty code files... or reverse engineering existing class files back to UML models. 

Thankfully I have not had to lead or be that senior in such a large scale design, few do.  Most of the stuff I have worked in has been dividable into sets of much smaller components that interact via the database.  State machine like, but just moving data through a pipeline sequence.  Picking up data in one state, processing and putting it back one step further on.  Small simple components makes work easier to divide up and give out to junior engineers and testers.

Today I find a whole load of software I have written or seen involves picking data up from one place, doing very little to it and putting it back somewhere else in a different format.  It's quite tedious.  The analogy is reading a UART line and sending barely altered, slightly processed, SPI.

Speaking of changing data formats I am surprised it works at times. I suspect you can shine some light on this. am example. I have a micro that only knows how to communicate in RS232. Other than 232 standards , 3 wire in this case , the mirco is as dumb as a bag of nails. Unfortunately third parties want the micro on their network with a proper IP address. To further complicate things they want to run fiber as the distance is over 300 meter just outside copper standards. The end result is RS 232 to patch cable adapter and then a patch cable to fiber adapter. It does not end their as when arriving it has to do these magic trick in reverse with fiber to patch cable adapter followed by patch cable to 232 standard. This whole process is transparent to the dumb as a bag of nails micro who thinks he is talking to a 232 interface. I have done this a few times but when sitting back and thinking of all the pins that had to be put in place just right the pull off the magic is impressive. A 232 is limited to 50 feet according to it's standard. In real life 232 will go well over 300 meters at a 9600 baud. In short the patch and fiber adapters were not needed as 232 direct will get your there. The only reason for all the adapters with their magic tricks was the politics of doing it by the book.

[T3sl4co1l]

Relevant:

[SilverSolder]

Seems to me that the trend towards using more comprehensive frameworks has a downside:  the learning curve.

For example, if you take some test instrument from the 80's or 90's,  getting it to work on GPIB is usually a very quick job,  sometimes the characters you need to send to the instrument to persuade it to do simple things is printed on a sticker under the device...   within a few hours, you can set up and automate a reasonably complex test environment just using single character ASCII commands.

Compare that to modern products, where you have to jump through a few more hoops to get anything out of it (the flip side, of course, is that once you do, it can do a lot more).

Perhaps there is room in the world for both approaches?

[RoGeorge]

 

[bd139]

That's apart from us engineers who were intelligent enough to work out there was more money cruising along with one eye shut and slacking 3 days a week writing software instead

[paulca]

The job definitions are a bit dated.  "Programmers" are people who type code in based on a VERY, VERY detailed spec.  They do not make design decisions or actually engineer solutions.  Software Engineer is the more well paid title for those who do the later as well as write code.

The analogue with a CNC machine should make it more obvious.  The design engineer works out all the settings required, the programmer just types that into the machine.

The term is very dated to the days when we didn't have new real time, code, run, test cycle on development machines.

[hans]

I personally like to think there is a difference "developers" and "engineers", although in some cases the region is very unclear. In college, the software development I see is very mediocre to autistic to excellent. And then there is a course called "Advanced Programming", intended for people who don't know how to program and need to learn it; which in my opinion was a bit deceiving.

I think one further interesting point to make about unit testing is that it also gives room to deviate from only happy path testing. What does my software do when a certain collection does not contain all arguments to get started (e.g. some input JSON data)? Or some day you spot a bug that highlighted some faulty dependence between A and event B; let's write a test that reproduces this fault, and make sure it stays fixed in future revisions.

Although EE and SW are quite different fields; I do honestly think that both share some merits. It's relatively easy to get some piece of software to function and do a job. But to get it reliable, be safe, pass all regulations and maintainable is a completely what makes it challenging.
For example: in electronics it's also relatively easy to get something functional. But then optimizing for cost, power consumption, passing CE (electrical safety, isolation, EMI, ESD), temperature cycling, hot plugging power and connections, deploying at customer while offering solutions for remote testing and debugging.. So much extra "engineering" left to do from the core concept..

I think this also mostly separates hobby from "work". I like playing around with technology and concepts. But to some degree the "engineering aspect" to me is just work.. a grind. I don't mind it, but I do notice that in hobby projects I tend to lose interest once I reach some of the first milestones I had set, as it feels like I've accomplished what I set out to do. I would probably need to double the time spend in order to make it usable and stable on a day to day basis. But for "tinkering" this suffices. Not if you deploy a piece of hardware or software on the other side of the world, and the product needs to work because it's use is only relevant for 2 weeks per year.

[romhunter]

Here's my 2 cents: Harware or software (or firmware which is kinda between those 2), they are just method to solve problems. No matter what you do, in the end it all is about implementing idea and solving problem. I am an undergraduate EE, but I do a tons of software, coding in C#, using python to automate some boring task, java to build android app, verilog to describe logic chip, etc... And I also am capable of using register, and understand hardware clearly, which is one thing a lot of EE nowaday can't (library... yuck). Most people end up coding because they're scare of hardware. When you screw up doing software, you can always roll back, having backup, or maybe fix the damn bug in the last second. No such thing happen with hardware. Also hardware require tools, experience, and a moutain of patience (ever see a badly connect test lead? Guarantee to make one get mad)

[paulca]

(ever see a badly connect test lead? Guarantee to make one get mad)

Ever do this:

if( foo = bar ) {
   doSomethingThatNeverHappens();
}

And scratch your head, curse, rewrite half the unit of work and only then do you spot the missing =.  DOH!  Java at least doesn't premit this syntax an assignment is not considered a boolean expression.

[bd139]

I do those intentionally to confuse people sometimes

[paulca]

I do those intentionally to confuse people sometimes

Yes, smart arse coding can be fun.   My favourite for messing with people in C is to use roll overs or precision loses as a feature.

That and using raw logic expressions instead of if statements.  This is common in shell and perl, but less so in HLLs.

doSomething() && reportSuccess() || reportFailure() && DEBUG && outputDiagnostics();

It is however considered bad practice though.  A lot of high level languges will give you an error which paraphrases as "Please don't be a dick."

[paulca]

Actually I think this is one difference between software and electrical engineering.    If the funky logic expression above works in electronics, no matter how much rigor your need to understand why, regarding operator precidence and logical sequence evaluation, then it will be used.

In software there are perfectly functional and legal code syntax and techniques that we would avoid because they make the code harder to understand for little or no gain.

I have many times in my career called out a bit of code for being "smug" or "smart arse" and in my more senior role today, unless the developer can justify the need for it to be that way I would have it rewritten more explicitly and readable.

[T3sl4co1l]

Actually I think this is one difference between software and electrical engineering.    If the funky logic expression above works in electronics, no matter how much rigor your need to understand why, regarding operator precidence and logical sequence evaluation, then it will be used.

I slightly disagree -- there are exceptions:

If you expect your design to pass review, don't be a dick.   Typical environment being, one pass, design it and build it, and be done.  A lot of lower quantity products are designed this way, and a lot of contract design is done this way.  It's just cheaper overall (lower risk / rework / respin) to execute a canonical, RTL-level (if you will) design.

If you feel there's a strong motivation to optimize the design, early (warning signs: early optimization!), at the expense of clarity, you'd better write a description to make it clear how your ratsnest is supposed to work.  Even so, this is risky, as a lot of engineers without experience in such circuits, will tend to take your description at face value, and not try to check it themselves.  Result: little actual review accomplished.  (Bonus points for running a simulation, though.)

Whereas, if the design is incremental (improving on an existing design, optimizing, cost reducing), and typically in higher quantity production (so that the savings is worthwhile), you can get into cheaper parts and more quirky circuits.  You probably also have the luxury of running a prototype, so that the design review need not be as strict, and so that the engineers involved can all get a feel for how the circuit works, on the bench.

Tim