Software Engineering, or not...

[RobCole]

This discussion has wandered a ways from what Jim originally asked. I was going to jump in with some of my experiences with engineers straight out of school telling me that my 20 years of experience didn't matter since I didn't have a degree, but I think we should get back to Jim's question of "what other helpful concepts he might be missing."

So here are some thoughts on concepts we have learned (some of them the hard way):

Yes, source code control is a HUGE step forward.

Requirements gathering becomes very important with larger projects.

Use cases - how will your software actually be used. This is a very important concept. In our earlier days, we designed a lovely system that our customer's managers were exstatic over. The workers in the field cut cables and did general sabotage so they didn't have to use the clumsy system.  We have learned how to build systems that the workers actually want to use (it makes their jobs easier).

Set up code reuse by identifying code that is commonly used and creating a common repository. All of your projects can then use this common repository without copying it all from project to project.

Code reviews to look at code and get many eyes looking at it. It's amazing what other people can see. This is also a great place to find VIs to turn into Common Code.

DESIGN UP FRONT. This can't be emphasized enough. We designed a function of one project and had a design review, re-designed, reviewed,... etc. We were way over budget on design time, but coding time was way under budget. We have never had to go back and revisit that code. It is now used in multiple projects. A good design covers a lot of ground. In fact, I was in charge of that design and then had to go out of town. Another developer picked it up and produced the code in near record time.

So that's just a few concepts that newer developers might find helpful to look into.

     Rob

Message Edited by Robert Cole on 07-03-2009 02:26 PM

[jcarmody]

• I've done OOP in Java and, cough, VB6 but not in LabVIEW.  I'm still trying to decide if I should start with Endevo's toolkit, LVOOP or OpenG stuff.  I've seen a plethora of resources for other approaches.  I'm tempted to start, but haven't been able to decide where/how.
• I'm using SVN (now, with the JKI TortoiseSVN tool) and am feeling comfortable with what I'm doing (although LabVIEW changes a bunch of stuff under-the-hood and I'm not sure how to handle all of that).  I'm going to need to learn how to tag/branch (which?) a version when I get QA approval of my current project.  Learning is good.
• Use-cases & requirements gathering seem pretty obvious but I've not done a good job at this.  I have been careful to ensure that the people using my software have a chance to critique it during development.  They appreciate it and I benefit from their point-of-view.
• I've already told my colleagues & manager that we're going to do code reviews.  Up till now we've been relying on SQA as our second set of eyes.
• I'm itching to use VIPM for reuse.  I've worked with a common folder of reusable pieces, but a common repository adds another layer of difficulty.  It also adds another layer of words I've heard but can't define!  Things like "SVN externals"...
• "Buffer allocations, queues, in-placeness are also CS terms that we need to know."  I'm hip to 2/3 of these, but only know about buffer allocation from what I've read on the forum.  I think I understand that some design-time decisions can cause a buffer allocation where another can avoid it and still provide the same function, however, I don't know what determines this.
  

So, you folks have given me some good answers as to what I should consider.  Now, how about tools?  What do you folks use to accomplish these things?

Message Edited by jcarmody on 07-06-2009 05:56 AM

[RobCole]

Okay, maybe common repository was poor wording. We have one repository with multiple projects in their own directories. So there is the Common directory in the repository along with the other projects. And then a LabVIEW palette made with the common VIs in it (with more sub-palettes for String, Math, Communication, etc. functions).

We tried SVN with LabVIEW and then ditched it. Turns out SVN is not very good at handling binary files (like VIs) for locking and collision avoidance (we have upwards of a dozen developers on a project). We use Perforce for our LabVIEW development. The C#, .NET, Java teams use SVN since it is good at merging text files (Perforce is as well, but it is a little expensive).

Tags (or labels depending on your SCC) are the way to go. Every time that we have a release of a software version, we create a tag/label so we can sync back to exactly what we delivered. Makes support a lot easier when you're looking at exactly what the customer has.

We do very large projects without using OOP. We have enough trouble squeezing our RT programs into the memory space available. OOP is great if you're not using cRIO or Fieldpoint systems.

You definitely have the right idea about bringing a customer in to see how it will work early in the project. Mocking up screens and explaining how you think it will work can be a great tool during requirements gathering as well.

Sounds like you know enough to do modular coding. Take code reviews in smaller chunks. Do a module at a time. Long code reviews tend to be a bit too much for people. When you are integrating all of the modules, already reviewed modules can be passed over (mostly).

Most of this stuff comes with experience. If you are not changing the size of an array or are working with a cluster, then in-place structures are the way to go. Makes cleaner diagrams usually as well.

     Rob

[Ray.R]

Our filters give us different perception of what we see, hear, and in this case, read.

What I got from the article is something I believe to be true.  With experience comes knowledge and wisdom. Unfortunately, it is something that most companies are getting rid of because of salaries and aging staff.

For instance, I have a friend who has reached the 60+ year old mark and has a wealth of knowledge down to the small details of why things should be done in such a way.  He cannot compete with new grads at getting a job because of his senority.  That's rediculous, because who will share that knowledge with the new grads.  Yes, they may be cheap, but they do not yet have all that knowledge.  And the hiring managers do not understand the difference, or value behind the knowledge.  In this case, I am referring to RF design and RF measurements.  It is far more than just connecting an intrument to a signal and relying on the numbers that appear on the screen...  no matter how expensive the instrument is.

I attended a course offered by NI on DAQmx.  The person next to me had an EE degree and a Masters in Computer Engineering.  Never took electronics and did not understand why signal conditioning was important and actually didn't know what it was.  It was expected that with a DAQ board, you simply connect the wires, write software and read whatever you get from the DAQ card and it should be good.

Writing code is one thing.  Writing code that meets all the "good practices" and requirements is another.  But writing code that does exactly what it should be doing by first understanding the environment that it goes in, is something else.  That something else and how to write the code may be learned by oneself, at college, etc and the same for understanding the environment.  It needs to be learned and that knowledge should have value, regardless of age.

The topic applies to more than just software..

R

[tbob]

I totally agree with my good buddy Ray.  Older guys get looked over quite often when applying for a new job.  Hiring managers understand money only, and they think anyone with a degree can get the job done.  One of my former managers had a rude awakening when he cut me and gave my job to a junor engineer.  The guy knew nothing about RF, did not have any programming experience, and he had to be "let go" because he could not perform the job.

Writing a software application is one thing if it does not involve hardware.  But writing an application that interacts with hardware requires special knowledge that most computer science geeks don't have.  In this case, the hiring manager would do better to hire an EE with experience.  Like me and Ray R.  I got lucky when I applied for my present job.  The hiring manager came from the test engineering lines, and he recognized the value of experience.  Most of his employees at the time were young and green.  I was able to bring a wealth of experience to the group.

When making distinctions about software programming, hardware, the type of hardware, or no hardware at all makes a huge difference in who is the better programmer.

[johnsold]

tbob and Ray are pointing out that some good system-level engineering and understanding of the needs of the project are important to its success.  The design tradeoffs between hardware and software cannot be made effectively except by someone who has considerable knowledge of both parts and their capabilities and limitations.

Software engineering is a subset of the project.  Whether adherence to the best practices of software engineering is critically necessary to the success of the project probably depends on how complicated the software will be and what portion of the overall project is software.

Similarly, hardware engineering (electrical, electronics, mechanical, chemical, and others) may be central or peripheral to the total project.

We see many posts where the poster has been frustrated by extensive attempts to compensate in software for the lack of a bias resistor or anti-aliasing filter in the hardware.

If you do not understand your problem, the solution will be much more difficult.

Lynn 

[F._Schubert]

Jim,

what gave me most was starting my reusable library and having it available via the palettes.

As these vi's are constantly used in all running projects, the are pushed to a bug-free state fast. So I didn't use the 'externals' yet, if the code will break, then it is  nature of evolving code. But I also try 'Unit Testing' with these, as well as document the behaviour in all scenarios.

If they are tested in the current projects, they will made public to the team (I will try with the svn server, otherwise I will need to get the VIPM pro).

I really like this custom palette, as the also include the most frequently used build in functions of LV of the same topic.

If you're looking for tools, I'm happy with a bugtracker (I use Mantis, but they are all similar). It's  a cool replacement for todo-lists and keeps me more organized when jumping from project to project back and forth. 

Felix 

[RobCole]

Felix makes a good point about tracking bugs, upgrades, new features, etc. We use an issue tracker called Jira to keep track of all of these. We can have some of the team doing testing and entering issues into the tracker while others of the team are working on bug fixes. you can also enter all of the changes that a customer might like to see and prioritize them.

It's a very helpful system.

     Rob

[jcarmody]

I'm doing Ok with tracking issues/bugs.  I decided a long time ago not to write software with bugs and haven't looked back.  It was one of the best architecture decisions I ever made ;).

How about managing requirements?  I receive a test specification from our Design group and my habit has been to read it and start coding, but I want to get better.  I've started highliting the specific requirements and copying them into a spreadsheet with the intent to use NI Requirements Gateway to track coverage.  Are any of you using this?  What else are you using to ensure your ATE covers all of the requirements in the test spec?

[F._Schubert]

I actually use (misuse) the bug tracker for managing requirements (even the hardware progress).

So I will have

bug #001: Can't measure the voltage

bug #002: Cabeling missing (blocks bug #001)

bug #003: Need shematic for cabeling (blocks bug #003)

When I code, I constantly fill up which behaviour I will want (maybe some GUI design) which will be implemented later on. This way I keep focus on the main line of may story.

That way it's just a well organized TODO-list for which I used paper and pen before. That just produced a lot of paper piles where I never would find the notes for the project I was working on two weeks ago.

Felix