Why do a lot of electronics engineers end up coding?

[paulca]

At least when you test something before it goes out the door you know it will work.

From the context I assume you are trying to say that when you send hardware out the door you can know that it will work. Was that intended as a joke?

Let me be clearer.  The design functions.  You build it, you test it, you ship it.  Unless it breaks, it will function as designed.  If it breaks, it's broken.

Which reminds me about a previous attack on software, this concept that software should be "done right the first time" and not have any of this non-sense updates.  This works if you fix the environment.  The software will always do what it was intended to do.  It doesn't age, it's caps don't dry out, give it the same environment and it will run as designed and shipped forever.  But that never happens and expecting your 0 gauge train to run your new 1/4 gauge tracks is rather short sighted.

In software we get this type of support ticket all the time:
"I took your 8 bit shift register and put it in a socket for a 16 bit one and it didn't work!"

Of course, it can have genuine bugs.  But so can hardware.

[branjb]

I've had a few jobs out of college now, and while I keep starting off in the EE space, I always get steered into software some how.
I've finally settled on a happy medium of just doing software at work, and doing all my EE at home in the form of hobbies.  Schematic capture/board layout/design is much more enjoyable when you can just choose or change whatever component you want, without having to dig into requirements and show 10 pages and 120 minutes of meetings to get someone to sign off on an ECO.  It's also kept me from burning out on electronics, at home I can't stand writing software; I'd be worried that after 10 years in peer EE I'd get burnt out of doing it, which is where my real passion is.

[tggzzz]

Now tell us how Intel is changing the internal operation of its processors that are out in the field, in response spectre and meltdown.

There is vanishingly little difference between hardware and software.

By changing the microcode.  Which is software.  Can you touch it?  No.  It's software. 

But... I concede your point.  However what impact do those changes have on the hardware beyond it?  Will your USB mouse stop working?  Will your Gfx card stop working? 

Now you could argue it is because the hardware interfaces are better defined and thus Intel can test they don't break said interfaces. 

Not quite. Whether or not it is "microcode" has not been published; Intel even bought Altera so as to merge FPGA technology into their processors.

Either way, Intel is changing the implementation of their API, i.e. the instruction set, in ways that break the system. That's why their changes are being rolled back

There are differences, they are complex.  Software tends to exist in a much more fluid world.  The dependency scope is more diverse.  However the life cycle is much shorter.

Software that works as designed for decades requires a fixed environment, just like hardware.  But fixed environments are not what we have today.  We have a rapidly changing one.  Software that worked 5 years ago on modern computers did not work on computers 5 years before that and it might not work on computers today.

Those are merely differences of scale, not of kind.

[John Heath]

I am sensing a lack of respect for professionally written software. An engineer will write software to take care of business and think that is enough. It is not enough for a business as they want portable software. The meaning of portability software is that you can drop the source code anywhere and they will understand without the need to have it explained in detail. A business does not want to be held for ransom by an engineer because as the source code is unstructured therefore cryptic in it's nature. For a professional writing software to get the job done is a low priority. It would be gigantically stupid to take on a software project if engineers had not already made sure it was doable. The purpose of a professional at software is to translate cryptic software into cognitive structured top down so that the software is portable and therefor the baton can be pasted on to others . An example of professional software is it will always start off simple Do while , input , process , output , end program. In four simple statements the entire program has been divided into three parts of input , process , output. The goals of a professional in software is portability to a common cognitive top down structure that other programmers will recognize and drop to their keens saying thank you. It is not getting it done rather writing code that is portable.

[Howardlong]

In every commercial software project I’ve ever been involved with there are dozens of requirements, portability -may- be one of them. Engineering is all about balancing those sometimes conflicting requirements.

Portabilty is not the same as readability. Furthermore, portability to what and for what purpose? Portability covers many things.

It’s not uncommon to split a project into functional and non-functional requirements, and regrettably many project managers view non-functional items far less importantly to functional items, so things like performance, readability, and security often get bolted on very late in the project or even descoped.

I’ll also add that almost always, getting a product out of the door trumps everything else.

[Karel]

It's ok if you just stick with arguments. No need to be arrogant.
Your opinion is just an opinion, like everybody else.

Arrogant?  You are suggesting that software development is easy.

This is an internet forum. People have opinions. They can and will be different than yours. No need to call it dumb.
It doesn't help the discussion.

Opinion?  I have over 30 years experience with around 16 years professional and hold the position of lead developer.  Billions of dollars have passed through my code and millions of people have used it.  I think that puts weight in my opinion.

Unfortunately, not everybody tells the truth. I could write that I have much more experience than you and that my opinion
is better than yours. No need to call it dumb. Just stick with arguments.

My last paragraph is simply fact, not opinion.  If you can find evidence to deny it then I will accept your "opinion" with more weight.

You make a statement, you proof it.
You can't make a statement and say it's a fact till somebody else proof it isn't.

[paulca]

This is an internet forum. People have opinions. They can and will be different than yours. No need to call it dumb.
It doesn't help the discussion.

Unfortunately, not everybody tells the truth. I could write that I have much more experience than you and that my opinion
is better than yours. No need to call it dumb. Just stick with arguments.

You make a statement, you proof it.
You can't make a statement and say it's a fact till somebody else proof it isn't.

I'm sorry, but I'm tired this millenial attitude that every opinion is as valuable.  Some opinions are dumb when faced against the facts.

I could post my linked in or my CV but I'm prepared to do so.  I will let it pass that you effectively called me a liar.

Do I need to prove the sky is blue?

https://docs.oracle.com/javase/7/docs/api/
https://docs.python.org/2/library/
http://www.cplusplus.com/reference/

I could go on all day, because I can't find a single instruction I could write in any language that will not have a specification behind it.  The annoying ones are the ones that DONT have a well written spec.  Some give you one line at best and you have to trust it's implemented intuitive and does what you expect.

[tggzzz]

I'm sorry, but I'm tired this millenial attitude that every opinion is as valuable.  Some opinions are dumb when faced against the facts.

Agreed. Shame it has to be said, but that is in itself a sign of the times.

I could go on all day, because I can't find a single instruction I could write in any language that will not have a specification behind it.  The annoying ones are the ones that DONT have a well written spec.  Some give you one line at best and you have to trust it's implemented intuitive and does what you expect.

Unfortunately I can, and there is an entire class of such languages that are seductively fashionable: DSLs. Lemma: a compsci graduate that can't work on compilers will yearn to create their own DSL.

Most DSLs:

• start out being small languages for limited purposes, often to allow "easy scripting" of operations written in a conventional well-understood language
• end up as cancerous growths as new features are added
• the misfeatures interact in unexpected ways
• the original designer perpetrator doesn't fully understand their creation, leading to "operational semantics"[1]
• there's no tool support
• if you can hire anybody to develop/maintain such stuff, you have to spend time/money training them

There are some well-considered DSLs (e.g. for FSMs), but they still suffer from the tooling and maintenance problems.

Usually a decent DSLibrary is preferable to a DSLanguage.

[1] a.k.a. suck it and see

[filssavi]

In every commercial software project I’ve ever been involved with there are dozens of requirements, portability -may- be one of them. Engineering is all about balancing those sometimes conflicting requirements.

Portabilty is not the same as readability. Furthermore, portability to what and for what purpose? Portability covers many things.

It’s not uncommon to split a project into functional and non-functional requirements, and regrettably many project managers view non-functional items far less importantly to functional items, so things like performance, readability, and security often get bolted on very late in the project or even descoped.

I’ll also add that almost always, getting a product out of the door trumps everything else.

the problem is in the last sentence...

It seams to me that getting a product out of the door doesn't only trump portability and other non-functional requirements...
it often trumps getting the product working as it should

there could will very well be specifications describing every code path in the program, I don't know that, but I argue that bugs will most definitely not be as coded to a spec

so in the end what I as a end user am left with?

A very expensive software (MATLAB) that does not work because of bugs in a primary feature(launching simulink simulation through a script) that was working flawlessly in the previous release that has me cursing and swearing for almost 2 days as i try to find a way to make said feature work again and at last having to resort to installing the previous release to be able to work, this is just one of the countless times this has happened

Now I don't know if all of this is due to a management decision to ship the product anyhow or if it has just gone through the cracks due to a lack of any meaningfull QA worth it's name or else and I frankly don't care...

if i pay for a product it has to do what it says on the tin (ok marketing wank aside), I can gloss over the occasional bug but that is about it, if a touted feature does not work after 2 days of trying as per what the manual says and the software spews out some criptic ungooglable internal error I get pissed of to whoever wrote, tested and sold the dang thing.

And also as with everything the more I pay for a software the more i expect it to work flawlessly

if a 400$ rigol scope is slow and has some of the features are buggy I can gloss over it
if the same happens with a 20,000$ lecroy there is not a chance in hell i let it slip

[paulca]

On specs...

I had a grr moment in work on Thursday.  I wanted to do a quick unit test for a timer.  It's school boy stuff.

auditCounter.startTheClock();
// do something
auditCounter.stopTheClock();

Now, I knew peril lay ahead, but I thought I would give a unit test a go.

Code: [Select]

auditCounter.startTheClock();
Thread.sleep(1234);
auditCounter.stopTheClock();

assertEquals( 1234, auditCounter.getTimeMillis() );

Now I was expecting a failure with 1235 millis, maybe, but no.  I got 1233 about 10% of the time.

So I checked the spec of Thread.sleep() and to paraphrase:

"We have no idea how long it will sleep for, YMMV.  It's all them hardware guys fault."

(Actual spec):

Causes the currently executing thread to sleep (temporarily cease execution) for the specified number of milliseconds, subject to the precision and accuracy of system timers and schedulers. The thread does not lose ownership of any monitors.

Source: https://docs.oracle.com/javase/8/docs/api/java/lang/Thread.html#sleep-long-

A few disclaimers.... testing timing is always tricky.  Thread.sleep() has never guaranteed how long it will sleep for.  I was running it on a virtual instance which means virtualisation of the CPU timers which is always plagued with inaccuracies.  Timer accuracy on 32bit intel was only 100Hz.  I believe on 64bit it's still only 1000Hz.  If you want finer grained timers you need to use hardware RTCs or calibrated CPU delay loops.

I grumbled, muttered, oFFS, decided to revert to, "Testing timers is a fools errand." and deleted the test.  I did consider leaving it for the next guy along knowing it would fail 10-20% of the time, but I'd too nice for that.

I replaced it with a test without a sleep and checked it too less than 1 millisecond.  Even that could fail in a tiny random number of cases, though highly unlikely.

EDIT: Of course... this timer is non-critical.  All it does it output for audit purposes how long the job took in seconds.

[paulca]

Sorry to dilute the topic, but on that unit test and since software quality has been aggressed here on topic.

The purpose of a unit test is not just to demonstrate your code works.  The purpose of a unit test is to know your code still works when someone else has been in rummaging around and changing things.

In the example I gave above my "took less than a millisecond" is a dangling live wire.  If someone were to come in later and want micro second timing or single second timing and make changes to the start and stop methods, my unit test may not fail when they change the resolution of what start and stop use and not updated getTimeMillis() - they may not use it or care for it.

Thus a better "botch" around timer inaccuracies would be to sleep for say, 3 milliseconds and check that getTimeMillis() returns somewhere between 1 and 4 milliseconds.

Another approach is to remove the sensing from the timer class entirely and pass the current system millisecond counter into the start and stop methods, so the unit test can inject test values instead of relying on the system timers.  Of course that moves the problem to the method that uses the start and stop methods.

Testing is not always as easy as it seems.  Dates, times, timers and other "not entirely deterministic" things are always difficult.  If I had £1 for everytime I have had to fix a unit test from an American because they hard code date/times in EST, I'd be rich.

[tggzzz]

A few disclaimers.... testing timing is always tricky.

It is worse than that.

If you are testing timers then it is a red flag since it usually indicates bodged system design, analogous to having monostables or chains of inverters in a digital circuit, or select-on-test components in an analogue circuit.

Testing timing is more difficult than most people imagine: you really need multiple executions under representative conditions, and to plot the PDF/CDF of the timing distribution.

[Howardlong]

I’ll also add that almost always, getting a product out of the door trumps everything else.

the problem is in the last sentence...

It seams to me that getting a product out of the door doesn't only trump portability and other non-functional requirements...
it often trumps getting the product working as it should

I didn't say I agreed with it! ;-)

[paulca]

A few disclaimers.... testing timing is always tricky.

It is worse than that.

If you are testing timers then it is a red flag since it usually indicates bodged system design, analogous to having monostables or chains of inverters in a digital circuit, or select-on-test components in an analogue circuit.

Testing timing is more difficult than most people imagine: you really need multiple executions under representative conditions, and to plot the PDF/CDF of the timing distribution.

In fairness, I'm not actually testing the timing.  I'm just testing that the code counts and returns milliseconds between start and stop.  Not that the timing is accurate.

[John Heath]

In every commercial software project I’ve ever been involved with there are dozens of requirements, portability -may- be one of them. Engineering is all about balancing those sometimes conflicting requirements.

Portabilty is not the same as readability. Furthermore, portability to what and for what purpose? Portability covers many things.

It’s not uncommon to split a project into functional and non-functional requirements, and regrettably many project managers view non-functional items far less importantly to functional items, so things like performance, readability, and security often get bolted on very late in the project or even descoped.

I’ll also add that almost always, getting a product out of the door trumps everything else.

I should say the word portability is one that I use in a descriptive way. My meaning was top down program structure using variables with long names to make it as easy as possible for the next guy to understand. This opens the door for team work. For example I could emial my "structured" source code and ask you for advise on this or that.  As long as the code is structured you can see what I am doing with a quick glance.

There is also the issue of the length of a program. With thousands of lines one can get lost in their own code. This is when the structure KISS philosophy pays off. KISS is short for Keep It Simple Stupid.

out the door trumps everything. I would add out the door and making a profit trumps everything else with focus on makes a profit. Not easy considering the apps on my phone and computer are all free downloads.

The internet connects so many bright minds from around the world all armed with a common android operating system. This leads to excellence in software. My phone is also a GPS. There is a ton of code in that puppy and it is free. Good for me but where is the profit for the bright sparks that wrote code?

[paulca]

Top down design is less useful these days.  Bottom up is sometimes more useful.

Certainly in the OOP paradigm software isn't really seen as a hierarchy of operations that break down from very high level blocks into finer and finer details.  That technique dates back to JSP (Jackson Structured Programming) but it becomes brittle and confusing when considering asynchronous operations and concurrency and given that a lot of code written today has some form of network in the mix or multi-threading, top down design is awkward and doesn't really portray the neatness and understandably suggested.

In OOP sofware is seen more as a peer network on collaborating "objects".  Objects should be encapsulated and private about their details.  They offer a service via a contract (interface) and as long as they full fill that contract everything is grand.

Objects are often then grafted into design pattern building blocks.  Design patterns being the results of academic analysis of common programming problems.  An example is the Factory Pattern which allows you to decouple the implementation of an interface from it's actual code, so the later can be swapped at run time or at least without code change.  This concept is then adapted and extended to give us "Dependency Injection" to meet the "Inversion of control" or "Inverse dependency" structures, where classes/objects do not depend on fixed individual collaborating instance peers, but the outside code provides the implementation to the object.  Hence "dependency injection".  It is highly useful for creating test harnesses or stubbing out components with fixed known quantities to isolate test scope.  A popular example would be replacing a DAO (Data Access Object) with one that returns hard coded values, rather than test the database as well (that would be done elsewhere).

So, maybe you can come to see that the question: "Where is the top?" is highly ambiguous and not very easy to answer.  There are many tops.  Just following from the "int main()" method down will not lead you to all entry points either.

Certainly, "Top down design" is a useful tool in the box and would be used when breaking down a complex operation or behaviour, but it's just one tool.  Bottom up design, test driven development, object analysis, dictionary analysis, flow charts, sequence diagrams... it's a rather big tool box.

[paulca]

I'm sorry, but I'm tired this millenial attitude that every opinion is as valuable.  Some opinions are dumb when faced against the facts.

Agreed. Shame it has to be said, but that is in itself a sign of the times.

It should be noted, of course, that calling an opinion out as "dumb" when levelled against the facts is not the same as calling the person who voiced that opinion dumb.  That may or may not be the case .  The origin of the opinion may simply be giving his honest opinion while not armed with all the facts, from his own point of view.  However it still stands that from the perspective of a more informed stand point, the opinion itself can be dumb.

[John Coloccia]

At least when you test something before it goes out the door you know it will work.

From the context I assume you are trying to say that when you send hardware out the door you can know that it will work. Was that intended as a joke?

Let me be clearer.  The design functions.  You build it, you test it, you ship it.  Unless it breaks, it will function as designed.  If it breaks, it's broken.

Which reminds me about a previous attack on software, this concept that software should be "done right the first time" and not have any of this non-sense updates.  This works if you fix the environment.  The software will always do what it was intended to do.  It doesn't age, it's caps don't dry out, give it the same environment and it will run as designed and shipped forever.  But that never happens and expecting your 0 gauge train to run your new 1/4 gauge tracks is rather short sighted.

In software we get this type of support ticket all the time:
"I took your 8 bit shift register and put it in a socket for a 16 bit one and it didn't work!"

Of course, it can have genuine bugs.  But so can hardware.

I think most EEs just don't grasp the actual complexity of most software (to be fair, many SEs don't either). I'm not talking about a writing a little firmware to blink lights, drive steppers, etc. I'm talking about real software that takes a large team to write, is 50,000 lines+ (often into the 100,000s or even millions), interacts with many different pieces of hardware and/or other software and services, etc.

It's not reasonable to expect that 100,000 lines of software will ever be perfect. The best you can do is what we do with safety critical software, and even this takes an order of magnitude more time and resources than normal software (and often more). You can test the software to the software requirement and show that it does, indeed, satisfy the requirements, and that it does nothing that operates outside of the requirements. It's enormously time consuming and expensive, but we do it all the time. That's how cars and airplanes, running millions of lines of software, operate day in and day out without killing people.

It still doesn't address errors in the requirements. Garbage in, garbage out.

But comparing electrical engineers and software engineers is a pointless exercise. I'm trained as an SE, but I've played on both sides at one time or another. EEs have their own problems to contend with that makes the job difficult and requires creativity and knowledge to solve, but in terms of sheer complexity there is really nothing at the board level that EEs do that come close to even simple software projects. I'm not talking about how hard the job is, or how much intelligence or knowledge you need, or anything like that. I'm just talking complexity in terms of connections and logic. Most boards have very little logic on them, and for good reason.

The simple truth is that it's FAR more efficient to build the electronics as simply as possible, and bury as much complexity as possible in the software/firmware. So to answer the OP, if you're going to be a modern EE, you'd better know how to write some software because most of your boards that do something interesting will have programmable components on them, and the best EEs will be able to test their boards and maybe even write some simple driver software, just like the best SEs (at least low level guys) are able to do basic hardware/electrical debugging and rework. And if it's a really simple project, maybe you just do the whole thing yourself. A lot of times, they either get bored, the EE work drys up or they just decide they like software better, and boom...they're doing software. I've seen it happens many, many times.

And for those who think there's a "push it out the door" mentality, or some other nonsense going on in the software industry, you can whine all you want but by the time you wake up in the morning, microwave your oatmeal, watch the news, check EEVBlog and drive to work, you've already interacted with software that extends for hundreds of millions of lines. HUNDREDS of millions of lines. How many bugs did you find? Overall, I think that's pretty damn impressive.

[John Heath]

Top down design is less useful these days.  Bottom up is sometimes more useful.

Certainly in the OOP paradigm software isn't really seen as a hierarchy of operations that break down from very high level blocks into finer and finer details.  That technique dates back to JSP (Jackson Structured Programming) but it becomes brittle and confusing when considering asynchronous operations and concurrency and given that a lot of code written today has some form of network in the mix or multi-threading, top down design is awkward and doesn't really portray the neatness and understandably suggested.

In OOP sofware is seen more as a peer network on collaborating "objects".  Objects should be encapsulated and private about their details.  They offer a service via a contract (interface) and as long as they full fill that contract everything is grand.

Objects are often then grafted into design pattern building blocks.  Design patterns being the results of academic analysis of common programming problems.  An example is the Factory Pattern which allows you to decouple the implementation of an interface from it's actual code, so the later can be swapped at run time or at least without code change.  This concept is then adapted and extended to give us "Dependency Injection" to meet the "Inversion of control" or "Inverse dependency" structures, where classes/objects do not depend on fixed individual collaborating instance peers, but the outside code provides the implementation to the object.  Hence "dependency injection".  It is highly useful for creating test harnesses or stubbing out components with fixed known quantities to isolate test scope.  A popular example would be replacing a DAO (Data Access Object) with one that returns hard coded values, rather than test the database as well (that would be done elsewhere).

So, maybe you can come to see that the question: "Where is the top?" is highly ambiguous and not very easy to answer.  There are many tops.  Just following from the "int main()" method down will not lead you to all entry points either.

Certainly, "Top down design" is a useful tool in the box and would be used when breaking down a complex operation or behaviour, but it's just one tool.  Bottom up design, test driven development, object analysis, dictionary analysis, flow charts, sequence diagrams... it's a rather big tool box.

Well said and I see your point. If the software is more along the lines of a ROM state machine then what is input and what is output is blurred. A bunch of knee jerk bottom up instructions that are state of system dependent. My hat goes off to you. I would not enjoy writing that type of code where the friendly structure of input , process , output is lost. I want the safe shores of the Jackson world where my noodle can think with some clarity.

[paulca]

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.

[fourtytwo42]

I don't know if it's just me, but I've observed that a lot of electronics engineers (either recent graduates or not) seem to end up in jobs where the majority of their work involves coding. I'm not talking about just firmware, but even getting into application development, Python, web development...anything not involving electronics. Some of my uni friends since graduating, whilst trying to get into electronics design, a lot of them ended up working as software engineers. Some of them even started in an electronics design role, but transitioned over into programming. Is there a reason for this? Is electronics as a job becoming almost 'obsolete' since there's so much we can do with code when it comes to an ARM board or an FPGA, that designing electronics isn't as highly valued anymore, where you can just use a stock standard circuit to get what you want done? Is electronics the sort of field that runs the risk of being out sourced to another country?

I work as an electronics/hardware engineer for the record, and I enjoy it, but I also find myself wanting to get involved with coding a lot more lately.

Because we got bored listening to our software colegues going on about how complicated there jobs were 

[bd139]

To be fair most of the really complicated things I've seen in the software sector were founded on the shoulders of massive fuck ups, usually by inexperienced engineers.

[T3sl4co1l]

I've seen a lot of hardware designs that followed the same methodology.  You'd be a fool to think that there are no other fools in any given discipline.

Any fool can mash things together at random; it takes wisdom to optimize a design, to find the insight that allows reduction.

Tim

[John Coloccia]

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.

More or less, this is THE software problem that always has to be solved. Whether you do a lot with the data or a little, organizing and managing the data is what makes or breaks a design. Every major problem I've ever run into with a software design is that I have data HERE, it needs to get THERE, and there's no good way of getting it there. Most everything else is child's play. The nine pound hammer for fixing this is to simply make everything global, and for tiny projects that's actually a great solution, but for anything more than flipping a few bits here and there that gets out of hand almost immediately.

Whenever I start a new project, I spend a little bit of timing playing with any new technologies or risk areas, and then I dive into defining my data types and getting the data paths correct. It boring and it's difficult...it requires looking at the entire system as a whole. But once that's in place, everything else always seems to design itself.

[paulca]

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.