REGISTER | LOGIN
Breaking News
News & Analysis

Software Development: Not Written Here Is New Norm

So long, source code
6/16/2015 00:43 AM EDT
8 comments
NO RATINGS
More Related Links
View Comments: Newest First | Oldest First | Threaded View
traneus
User Rank
Author
Graphical top-level tool
traneus   6/16/2015 7:34:38 PM
NO RATINGS
I recall a former coworker using a graphical top-level block-diagram tool for FPGA designs (I never knew the name of that tool): The contents of the top-level blocks were all VHDL, and referenced lower-level VHDL code.

TonyTib
User Rank
Author
Re: In-house versus out-house code
TonyTib   6/16/2015 7:11:24 PM
NO RATINGS
I think graphical/model based programming (such as VisSim or Simulink) works well for programs that model the real world, which would include a lot of embedded devices.


However, I don't think the graphical approach is the best for general programming (including user interfaces, configuration, and much more).  As Brooks says, you cannot completely represent a program with a single graphical view.  Programming is not inherently 2D or even 3D.

And if a program has modules that are simple enough that you can simply snap them together, then you can do it just as easily (and a lot more compactly) with text.

elizabethsimon
User Rank
Author
Re: In-house versus out-house code
elizabethsimon   6/16/2015 5:49:47 PM
NO RATINGS
Yes, the extra up front effort put into a library is well worth it.

One thing that I think would be nice is a tool that would allow firmware to be built in a graphical fashon using pre-existing blocks. Each block would have a "datasheet" and could be "wired up" to form a design. As the amount of code that is generated gets larger, I'd think you'd need a tool like this to at least visualize the overall picture.

Of course I'm an electronics engineer who occasionally does formware so I look at things from that perspective....

 

alex_m1
User Rank
Author
nih
alex_m1   6/16/2015 5:08:23 PM
NO RATINGS
From the article: "It is a fact of life in software development that if you write your code tightly, with no ambiguities and extraneous code, a hacker will have less chance of establishing a beachhead."

Except that it is not true at all.security is a huge task, the only way to win is through mass collaboartion and he only way to so is through smart code reuse. And there are proven  results in the field - in web development ,one of the best ways to build secure sites is using scala lyft(open source) and following it's guidelines, and many critical systems use integrity's safety-critical and secure OS and networking stack which have passed testing by the NSA - to assure high levels of reliability and security.

TonyTib
User Rank
Author
Re: In-house versus out-house code
TonyTib   6/16/2015 3:22:50 PM
NO RATINGS
But the plus is that, with a library that will be re-used many times, that you can spend the time to get it right.  This is especially important for areas that are hard to get right, such as concurrency.  As the Rx (Reactive Extensions for .NET) developers say, we spent years tracking down hard to find concurrency issues so you don't have to.

So think about what makes sense to re-used, and what makes sense to tailor for each project.

And use the right tool for the job.  Although I'm skeptical about "silver bullet" tools, there is definitely a place for things like graphical/model based development.

elizabethsimon
User Rank
Author
Re: In-house versus out-house code
elizabethsimon   6/16/2015 1:41:21 PM
It's difficult enough to reuse in-house code...

In order for code re-use to be successful, the code must be written for re-use and be extremely well documented. Also, as you mentioned, the licensing must be compatable with your other code.  And getting the layers involved is not cheap.

 

betajet
User Rank
Author
In-house versus out-house code
betajet   6/16/2015 10:52:15 AM
NO RATINGS
Reusing code used by other people sounds attractive, but my experience has been that trying to integrate code written by others is a nightmare and keeps getting worse as documentation gets more sparse.  Managers falsely assume that it must take less time to integrate out-house code, but "who hath measured the ground?"

When I think of out-house code, I think of this Brion Shimamoto quote (paraphrased from memory):
It's like taking an undershirt, turning it upside-down, and using it as undershorts.  It works in principle but isn't comfortable.

Brion was talking about using microcode to implement an architecture it wasn't designed for, but I think it applies quite nicely to trying to integrate out-house code.

Another issue that I don't think the article addresses is trying to harmonize the source code licenses of the out-house code you're trying to integrate.  Unless you ignore copyrights -- which is illegal -- all that out-house code has to have compatible licensing.  You'd better have your lawyers review every line of code, or at least every module.  That will save tons of money.

JMO/YMMV

Olaf Barheine
User Rank
Author
Third party code is fine...
Olaf Barheine   6/16/2015 4:33:39 AM
Except it has a poor quality, it hasn't got a good documentation, it has even no documentation, it is written in the wrong programming language (e.g. C++ when you need C), there is no source code available, the source code is written by anybody who obviously doesn't wanted that someone else understands it, the code was changed and adapted to new requirements by generations of developers,... Thus, sometimes it is easier to write software completely new.

Most Recent Comments
VicVat
 
BrainiacV
 
R_Colin_Johnson
 
Jayna Sheats
 
ganderson98001
 
Jayna Sheats
 
R_Colin_Johnson
 
EELoser
 
betajet
Like Us on Facebook
EE Times on Twitter
EE Times Twitter Feed