Software Engineering, or not...

[jcarmody]

Control Engineering (magazine) has an article this month titled "TRUST in software engineering".  It makes the point that:

One of the harsh truths about manufacturing software is that is it not developed by software engineers or computer science majors. We would not regularly ask an electrical engineer to design a mechanical system, or a chemical engineer to design an electrical system, but we often ask mechanical, electrical, and chemical engineers to design and develop software systems.

I've recently been impressed with the idea of being able to build an application in one click and making an executable at the beginning of a project and keeping it working.  I'm working with SCC (SVN) but haven't gotten the trunk/tag/branch concepts down yet, I don't do any regression testing and we reuse code by copying it from one project to the next (and almost NEVER from one engineer to another).  Requirements are not managed; we read the ATP and write code.  I'm thrilled to learn these things and am hungry for more.

I'm wondering if any of you have had similar experiences, and what else I'm missing as a Mechanical Engineer developing test systems for electronic products without a background in Software Engineering or Computer Science.

Message Edited by jcarmody on 06-30-2009 06:38 AM

[Cory_K]

I am currently a university student right now.
I'm working towards my major in Civil Engineering, but I'm also working on a minor in Computer Science.

See, I thought ahead

[Ben]

Your question got me thinking so since my coffee is just starting to work adn I am on vacation, i decided to ramble a bit. Don't read any further if you have better things to do today.

---

jcarmody wrote:

Control Engineering (magazine) has an article this month titled "TRUST in software engineering".  It makes the point that:

One of the harsh truths about manufacturing software is that is it not developed by software engineers or computer science majors. We would not regularly ask an electrical engineer to design a mechanical system, or a chemical engineer to design an electrical system, but we often ask mechanical, electrical, and chemical engineers to design and develop software systems.

I've recently been impressed with the idea of being able to build an application in one click and making an executable at the beginning of a project and keeping it working.  I'm working with SCC (SVN) but haven't gotten the trunk/tag/branch concepts down yet, I don't do any regression testing and we reuse code by copying it from one project to the next (and almost NEVER from one engineer to another).  Requirements are not managed; we read the ATP and write code.  I'm thrilled to learn these things and am hungry for more.

I'm wondering if any of you have had similar experiences, and what else I'm missing as a Mechanical Engineer developing test systems for electronic products without a background in Software Engineering or Computer Science.

Message Edited by jcarmody on 06-30-2009 06:38 AM

---

About twenty years ago I was helping U of Pitt with a bad hard drive (RM-80) that a mainframe (VAX 11/750) booted from. While working there one of the EE-PHDs was badgering me with question about how the computer worked. Computer Science Enginnering had not been invented yet and the world's computer expertise resided mainly inside companies like IBM, DEC, Unisys etc. To learn to how to start with a crash dump (in the old days, when a computer crashed, the entire memory contents were written to disk for later review), a set of microfiche of the OS source code, a print set and an oscilloscope and troubleshoot down to a failing chip in a multi-acre computer room required 6 months of intense 8 hour a day training. The sign over the main entrance to DEC training center in Mass. read "Through these doors pass the greatest computer professionals the world has even known." (Which by the way I think can be applied to our forums ).

That background has prepared me very well for what I do today since modern PCs are just miniature versions of what I ws trained on and my "VAX/VMS Internals and Data Structures" gave me a unique insight into the internal workings of the primative versions of modern OSs (VMS >>>> V+1, M+1, S+1 >>>> WNT >>>> Windows NT).

I mentioned the above (that sounds like bragging, yes I know) to show that I have very little "college learned" computer knowledge beyond an intro to computing course and a boolean logic course I took to add a minor in EE to my Enginnering Physics degree. So technically I have neither of the requirements that quote feel are required. Extending beyond myself, Mike Porter has told me similar stories from his early days of LabVIEW. I am sure that the most traveled amoung us can relate and share similar stories. so ...

Point #1

College is NOT the only source of computer expertise.

"The study of flux through a surface"

I was a non-tradional student (graduated from colege at age 41) so I talked to my preffesors like they were my emplyees (after all, I was paying them to entertain me) and hammered them with questions. So I asked my intro to Engineer proffesor for a generic description of what engineering was and the above quote was his reply. I still think that was a good description of engineering. I found that engineering school was a good introduction to learning how to recognize the "flux" and the "surface" in challenges that come before me and controlling the flow. But ,as many of us have found, the work the "real world" wants done enough to resort to paying us to do is not exactly what we studied in college. At it's best, college is a general introduction with an emphesis in some area.

I have worked with a top-notch CS type (passed his CLA exam within a year of graduating) and am married to one (The Princess earned her master at age 23). Both of them are valuable assets (my wife offers a "dial-an-SQL_Syntax" service) but there formal education did not get them through developing "manufacturing software" without some real world experience and some mentoring. Example: Impeadence mismatches can affect the measurements of high frquency signals such that reflections manifest themselves as "ringing" in an acquired signal. An EE may respond saying its a "bandwidth" issue but a fresh out of the box CS type may wonder what the network or backplane speed has to due with the measurement.

Point #2

Sheep-skins speak of potential and not capabilities

The development of "manufacturing software" is a science that is still in its infancy. It is a science that is devloping faster than schools can keep up. Each manufacturing application is as unique as the product they produce. I developed an app to optimize the yield of DVD production (back when DVD cost about $80 a piece due to only 3 out of 10 worked) and recently consulted precision resistor production. Aside from LV, SPC, and some DAQ hardware the two apps required vastly different expertise. In both cases, I relied on the customer to be the domain expert and I complimented their capabilities. If they had done it themselves, ti probably would have worked, but the apps would have sucked ... been lacking. Without their domain expertise I could have developed a mean app but there would only be a slim chance the product would have woth making.

The web of technology

Over the ages mankind has been reshaping our comunities by moving from being a group with common general skills (everyone gathers the harvest, digs the well, ...) to many smaller groups with very specialized skills. I understand this to have been driven by the growth of our our common written knowledge of the world tempered by our limited capacity to "know all things". We cooperate and rely on others to be experts in their areas and we do our part. This movement toward ever more specialized areas of expertise will only continue as long as there is a tangible benefit to the comunity for a skill. The work of the noble blacksmith (the engineer of their hay-day [carbon "into"/"out of" iron >>> flux through surface]) has moved to more areas of engineering, technology and manufacturing than I can list. None of which can exist in a vacuum absent the others. EG An engineer can only engineer what is technologically possilbe and has funding due to the manufacturing potential. So we have morphed from being individuals that can wonder into the woods and HAVE to find our own food into complex teams (web) that can crank up the air-conditioners and tweak our flux so that food is always easily findable in our refridgerators.

Point #3

Complex challenges require multiple domain expertise

And this is one of the reasons I like the forums here since I can tap into a huge pool of expertise. The above are just my thought as of this AM. I am open to change my mind. What do you think?

Done rambling,

Ben

[Wayne.C]

I have a friend that has a degree in computer science and spends his days designing and writing software for very complex military communications systems.  He has always contended that all code should be designed by a degreed software professional.  All code Anything else is flawed.  My contention is that my stuff works well and my boss is happy.

Message Edited by Wayne.C on 07-01-2009 11:42 AM

[jcarmody]

I don't believe that the point of the article was that we (I received my BSME at age 34) shouldn't be pretending to be Software Engineers, but that we should apply some of their practices.  I started this thread because I was never exposed to the ideas I mentioned, however obvious they might be to others.  I guess it's a case of "when the student is ready, the teacher will appear."  Well, this student is ready!

I agree with your points:

---

Point #1

College is NOT the only source of computer expertise.

---

That's for sure.  I expect that most of us on the forums learned LabVIEW on-the-job; even if some took formal training.  I'd venture a guess that many of us were programming long before being exposed to LabVIEW.  I began programming a Commodore VIC-20 when I was twelve and have been telling anyone that will listen that programming is a useful skill for anyone.  Simply being able to customize an Excel macro will put you ahead of the pack.

---

Point #2

Sheep-skins speak of potential and not capabilities

---

Usually, but we've all met educated idiots folks that have a college degree but aren't capable of very much.  Some of the most valuable people I've worked with were un-degreed.  It's a shame that many employers require one.

---

Point #3

Complex challenges require multiple domain expertise

---

🙂 Perhaps this is an advantage to getting a degree as an old man.

---

And this is one of the reasons I like the forums here since I can tap into a huge pool of expertise.

---

Ditto!  I cruise these forums every day because of the valuable nuggets I find, and I've become an incredibly better developer because of it.  I'm not ready to test for CLA yet, but I will be because of the discussion here!

Thanks LAVA NI Forums!!!

[jcarmody]

---

I have a friend that [...] has always contended that all code should be designed by a degreed software professional.

---

😞

---

My contention is that my stuff works well and my boss is happy.

---

:), but "works well" doesn't require that it is "readable, maintainable & extendable".  I think we can implement things like frequent, automated builds, SCC, unit/regression testing, use-cases, code reviews, blah, blah, blah without being Software Engineers, and that our product will be better for it.

[tbob]

My 2 cents worth (maybe 2.5 cents):

I once had a bad infection in my leg, and started taking antibiotics that I had leftover from a few months before.  The infection got worse (antibiotic was not a strong one) and I had to go to the emergency room.  The doctor there asked me a series of questions, one being had I taken anything for it.  I answered that I had taken an antibiotic.  He then asked me very sarcastically what medical school I went to.  I wanted to tell him off but since I needed the treatment I decided to keep my mouth shut.  My point being that you don't have to have a medical degree to amass some medical knowledge.  I knew I had a bacterial infection and I knew that antibiotics were the normally prescribed medication.  The doctor ended up giving me antibiotics.

Same for any engineering field.  Experience is a much better teacher than any university or any type of school.  We have a guy where I work who has a PhD in Mechanical Engineering.  He learned how to do test engineering, design small circuits, and write software in Labview and in TestStand.  He has become quite proficient.  It doesn't take a degree in computer science to learn how to write good software.  Likewise it doesn't take an electrical engineering degree to learn how to design circuit boards.  I once knew a guy who had no degree, but he was designing RF transceivers, and was one of the best I had seen.  He was self taught.  My dad never went to school, and he could perform arithmetic in his head easily, without paper and pencil (try adding 238 +567 in your head) (you can add left to right, and if you come across a carry, just increase the previous digit by one; the answer is 805, done in my head).

So what I am saying is that although a degree shows that you have the abilities necessary to perform a certain job, not having a degree does not, by any means, disqualify someone with the knowledge and experience from performing just as well as, or better than, a degreed person.  The person who said that any software written by a non computer science person is flawed, well his statement is flawed.

[jcarmody]

What we have here is a failure to communicate...

[Ben]

Sorry Jim I was reply to that quote and not question.

Re the quote:

As Tbob illustrated, stating absolutes "only doctor perscribe drugs" "Only CS type write software" are a mistake for us as a society to quietly accept.

I see staetements like that as being power grabs (if all software written be CS types then higher demand for CS types mean more students running thru their programs, etc.

Importance of CS techniques?

A knowledge of CS concepts is very helpful when developing with LV but not required unless we are attempting to write "perfect code" every time. In the case of manufacturing apps this does come into play. Source Code Control (SCC) is a broad term but boils down to ensuring the right version of everything is deployed together. The tools used to support this effort can range from zip files with notes through the "Big Dday" insisting on a story to go with every tweak. Branching etc are extensions of CS concepts to support apps that under-go changes while being used for production.

Tried and true architectures like producer-consumer and master-slave are concepts I would group under a CS umbrella and are terms used in our replies to "rookies" almost daily here on the forums.

Buffer allocations, queues, in-placeness are also CS terms that we need to know.

Prefecting our LabVIEW skills can be aided by exploring CS concepts!

1) CLA Exam

 As I mentioned in my ealier post a CS background can be very helpful when taking the CLA exam. It is an exam written by CS types  (yes NI is filled with them) and assumes the taker has knowledge of the CS ideas. My co-worker I mentioned previously, was familiar with the terminology and our study sessions were borderline boring for him. I had no flippen idea what a "Use Case" was before I started Googling the phrases in the prep docs.

2) LVOOP

LVOOP has been a hard nut to crack for many of us non-CS types. Let's start with an old joke.

"

A buisness man flies into Seattle (?) and his flight is late. To make his meeting he hires a helicopter to fly him to his meeting. As is generally the case, heavy fog makes it difficult to navigate so the pilot becomes lost in the fog. To get his bearing he slowly reduces altitude unitl they can make out in through the fog an office building. The pilot manuvers over to the building and seeing a person in one of the windows of the building yells;

Pilot:"Where am !?".

The person in the window replies;

Person in window:"In a helicopter."

The pilot hearing this took the copter up and landed it exactly where they where headed.

The customer being very impressed by the pilot's performance asked;

Customer: "How did you know where we were with such a lame answer?"

Pilot: "When I realized the answer was completely correct but totally useless, I knew we must be next to the Microsoft building."

For non-CS types almost all of the documentation for LVOOP falls into this catagory. If we already know OOP (like CS types) then it all makes sense. I had to resort to purchasing and reading a UML book before the beauty and elegence of LVOOP started to reveal itself to me. So to learn LVOOP we will either have to take the plunge or wait for someone to translate it into non-CS for us ( I have been trying!).

So summaring:

CS background not required to stumble by.

CS knowledge very helpful.

CS required is a just a power grab.

Did I "comunicate"?

Ben

[Intaris]

In addition, I would like to stress that SOME knowledge of the underlying hardware (and its limitations) in modern computers is of huge benefit.

Knowing WHY appending to a string is less efficient than replacing into a string is something kind of important once you want to make "good" software.

LV does a good job of shielding us from all that but knowledge of it can still help organise programs so that their efficiency is improved (and possible their robustness also).

Shane.