Discussion Page: Software Development Paradigm TrapI wrote an article, first published in Embedded Systems Design, entitled "Escape the Software Development Paradigm Trap." The point of the article was to argue that the demands of software development have outgrown the tools, processes and paradigms long employed, and that we need some radical re-thinking of how technology products are developed. Among more general suggestions I specifically proposed dividing development into larger numbers of more autonomous processing elements... an idea which has met with reactions as mixed as I had expected! Some of the readers have allowed me to post their comments on this site; here they are... James S. Gibbons - 5/15/2006 I just finished reading your article... I tend to agree with some of it but feel that there are basic differences between SW and HW engineering that make it hard to compare the two... [read] Dr. Carl Dreher - 5/18/2006 I've been thinking a great deal about the one-process-one-processor architecture... I've come to the conclusion it won't help (much)... Where the debugging headaches start are in how the processes interact, the architecture and the inter-process communications. Those type of bugs will not be eliminated by adding processors... [read] Alain Gronner - 5/26/2006 ...It could indeed be beneficial to the industry as a whole to do away with custom coding of each program and instead use a standard set of key functional blocks to implement the desired program. This would, I expect, have a result similar to the earlier shift to logic IC technology by hardware designers... [read] David A. Land - 5/31/2006 ...It is my experience with many multidisciplinary projects over four decades that if everyone has as their primary focus the success of the Thing instead of the methodology used to create the Thing, project milestones, QA benchmarks, and product release schedules pretty much take care of themselves... [read] John Stanton - 6/1/2006 ...We have, however, used the general principle to create some highly reliable pieces of software by discarding the use of "black box" software modules and coding from the ground up, building our own certified modules as we go...The projects completed in a quite reasonable time frame and deployed as fast or faster than those cobbled together from available parts... [read] Dennis Ruffer - 6/1/2006 ...I see complexity where simplicity is needed and few people daring to break out of the box of the traditional paradigms... [read] Mitch Barnett - 6/1/2006 ...Brad Cox, the inventor of Objective-C, had a similar view of reusable libraries and components that mirrored the hardware world. He even called them software IC's... [read] Brendan Rankin - 6/9/2006 ...I know of several customers that have used discrete [Altera] SoPC Builder sub-systems for each part of their overall design... It isn't easy (yet) to design this way, but each customer that's been through this process is now reaping the rewards of this sort of system modularization... [read] Peter Wolstenholme - 6/13/2006 ...A new software development paradigm has already been developed, in fact, mainly by Ferdinand Wagner... The idea is to take the behaviour of software, well-separated from all data processing, and express it as finite state machines... [read] Wayne Albin - 8/1/2006 ...good solutions to many of the problems of reliable embedded software. What was missing was a way to add robust redundancy... [read] John Taylor - 8/3/2006 ...Is it wrong of me to want perfection from this project? Is it wrong of me to expect perfection from this project? Invariably, the answer is no!... [read] Roy J. Tellason - 8/3/2006 Have you ever read Eric S. Raymond's The Art of Unix Programming? It seems to me that he does address a fair number of the issues that you talk about in this article, in the Unix context. [read] Bandit - 8/4/2006 The multi-uP approach is very appealing and you point out the issue of debugging. This is a critical aspect to SoC - will we be able to build the tools and processes to allow us to debug the darn thing? [read] Francois Audeon - 8/4/2006 Why does mechanical engineering perform better than us? I think there are three major reasons... [read] Greg Nelson - 8/4/2006 I believe specifications become even more critical and difficult in light of interacting processors with additional interfaces between them... [read] Larry Dickson - 8/4/2006 There are a few (largely orphaned) software communities that have been doing this sort of thing successfully for 20 years. They solved the problem of how to make software processes behave strictly as separate processors... [read] Steve Fairhead - 8/5/2006 I have a particular style in designing software. It involves aiming for the simplest possible solutions. The trick is to partition correctly, whether in software or in hardware... [read] Chris Gates - 8/9/2006 ...The current state of affairs and where you propose to go is such a wide gulf, that I don't see how any one company could possibly take us there... [read] Greg Nelson - 8/18/2006 ...The ideal of "correct design" would conquer the old "garbage in, garbage out" rule. But I believe the only way this is possible is to be able to unerringly identify at least one of "garbage in" or "garbage out" and flag it... [read] I have some suggested links for Further Reading on this topic. |