On our way to lunch a collegue of mine asked for my thoughts concerning MatLab-generated code. I repeat my thoughts on the subject here, just for fun.
Even in college, some 16 years or so, I can recall strong opinions on generated code and drag-n-drop programming languages. As a computer scienced major, I shared the same opinions as the majority of my peers; frankly, that drag-n-drop and auto-generated code is sloppy, unmaintainable and for people who can't handle programming in a real programming language.
I find over the past couple years or so, that my opinion on such subjects have changed a bit. My opinion has softened from the defensive stance of yester-years. Present-day however, some of my collegues share my past opinion with the same level of zest and fire as I once had.
My change of opinion started first by not getting emotional on the matter; which is easier said than done by individuals that make their livelihood developing software. Code generators and drag-n-drop utilities can be viewed as a replacement to the software developer of the day. The popularity of Visual Basic is a testimate of such an opinion; VB is marketed as a tool for MBA's to develop software without the presence of software developers. My opinion began to change after I quit taking that personally.
Auto-generated code still has challenges, two of which are maintainability and performance.
One of the first major criticisms of auto-generated code is that the code is unmaintainable. Code generators typically take a model representation, generate a language-specific representation of the model which is then presented to a compiler. It takes little time to form an opinion of the maintainability of this source code if you've ever glanced at the auto-generated C source from many code generators. While the syntax and semantics are valid, they can easily be a contendor for The International Obfuscated C Code Contest http://www.ioccc.org/. The variable naming conventions are cryptic enough to produce a slight migraine. The mere idea of modifying such source, even slightly readily produces a sense of panic. I began becoming less concerned about maintainability when I stopped focusing on the source code and more on the model. The source code is merely a bi-product of the model. Maintainability of the model is the issue, not maintainability of the source code. In actuality, the source code doesn't have to be understandable or maintainable for that matter. The model however has to be.
Performance is the strongest criticism of auto-gen'd code and brings out the strongest feelings in software developers. A quick examination of the generated source code can certainly prove that it can be more memory and cpu intensive than hand-tailored software. It would take little more than a second-year computer science major to produce more efficient code than most code generators. But to put it into perspective, I've witnessed some incredibly memory & cpu-intensive hand-tailored code by very experienced professionals. Wastefullness isn't unique to auto-generated code, or drag-n-drop programming; it is a product of rapid development. Given a relatively complex problem, and a desire to solve it quickly you tend to produce waste; period. Aggressive time constraints tend to lead you to the simplist and readily available solution. Generally speaking, the simplist solutions are typically greedy and therefore wasteful. Before you cry foul, remember what you gained...you gained a working solution in a short time period.
I've witnessed on two seperate occasions real-time, distributed, military systems prototyped in autogenerated code surpassing the re-engineered hand-tailored software developed by experienced, professional developers. The auto-generated code performed system missions faster consistently than the hand-tailored code and also performed more reliably as well. More importantly however is the fact that the auto-generated code was developed quicker and by a significantly smaller team (read that cheaper as well). To be fair however, this team was highly motivated, and were the recognized domain-experts.
Time to throw in the towel and use code generators exclusively? Hardly. I am not implying that code generators are the wave of the future. I'm only saying that you should look at it as another tool in your arsenal. Stop looking at software from a technologist's perspective and start looking at it from a business perspective. If your domain experts are fluent in code generators and less experienced in general-purpose programming languages, consider using the code generators. If your cpu/memory requirements can accomodate the overhead of autogenerated code and you believe that the development effort using code generators will be less than hand-tailoring at least give them a look.
Showing posts with label opinion. Show all posts
Showing posts with label opinion. Show all posts
31 January, 2007
14 January, 2007
Top 5 Technologies That Have Changed My Life
There are no shortages of technologies these days, few of them I could live without; these, I could not live without major inconveniences.
5) Internet
Perhaps a clique...but truth be told, the Internet has changed my life significantly. God bless Al Gore :) Whether at work investigating the proper usage of a STL container, researching competitor products specifics, or just general leisurely browsing for stupid humor tricks. Couple the WWW with a wireless 802.11 connection and an available laptop and you've got yourself a party.
4) Text Messaging
Sure, cell phones change may peoples lives. You can be reached at anytime, anyplace; which brings up all kinds of edicate issues. Sure, cellphones are nice...but what I really love is text messaging. Properly used, you never really have to speak to your wife, nor she to you. Besides, what else can you do during your hours of training or meetings.
3) Tivo
While the remote resembles a phallic symbol; once you get past that you'll learn to love your Tivo. What other product comes with a window sticker that you can proudly display on your car window? Once you've spent some time defining your wishlist and programs you'd like recorded as well as defined the priority of each recording, you're all set. My wife and I must have a couple dozen programs defined in our season pass manager and each night we come home we've got a selection of programs to watch....and can fastforward thorough those pesky commercials. I'd be willing to bet that we even watch less television since we've got our little cable-buddy. We no longer spend time watching shows just 'cause they are on, now we only watch those programs that are really worth watching. An hour program takes ~45 minutes to watch, a 1/2 hour take ~20 minutes; end result is more entertainment in less time.
2) Wikipedia
Rarely has a day gone by when a passing conversation or lunch topic does not result in a peaked curiosity. In the days of yourn, one would normally consider digging out the Brittanica for a full 7 seconds, shrug it off and just go about your day...never to know who "Aqua Lad" was. Fast forward to today and a similar question takes less than 7 seconds to retrieve the answer (or at least someones rendition of the answer) from this God-given website.
1) Google
Last but not least, you have to admit that Google has changed your life if you spend any time rattling on a keyboard. Few other products of our generation warrant it's name morphing into a formal verb. Sure, Yahoo was my search engine of choice during the college years (along with AltaVista), but today Google is first choice in the web searching realm.
That's it boys and girls. My top 5 technologies that have made a significant change to my life.
5) Internet
Perhaps a clique...but truth be told, the Internet has changed my life significantly. God bless Al Gore :) Whether at work investigating the proper usage of a STL container, researching competitor products specifics, or just general leisurely browsing for stupid humor tricks. Couple the WWW with a wireless 802.11 connection and an available laptop and you've got yourself a party.
4) Text Messaging
Sure, cell phones change may peoples lives. You can be reached at anytime, anyplace; which brings up all kinds of edicate issues. Sure, cellphones are nice...but what I really love is text messaging. Properly used, you never really have to speak to your wife, nor she to you. Besides, what else can you do during your hours of training or meetings.
3) Tivo
While the remote resembles a phallic symbol; once you get past that you'll learn to love your Tivo. What other product comes with a window sticker that you can proudly display on your car window? Once you've spent some time defining your wishlist and programs you'd like recorded as well as defined the priority of each recording, you're all set. My wife and I must have a couple dozen programs defined in our season pass manager and each night we come home we've got a selection of programs to watch....and can fastforward thorough those pesky commercials. I'd be willing to bet that we even watch less television since we've got our little cable-buddy. We no longer spend time watching shows just 'cause they are on, now we only watch those programs that are really worth watching. An hour program takes ~45 minutes to watch, a 1/2 hour take ~20 minutes; end result is more entertainment in less time.
2) Wikipedia
Rarely has a day gone by when a passing conversation or lunch topic does not result in a peaked curiosity. In the days of yourn, one would normally consider digging out the Brittanica for a full 7 seconds, shrug it off and just go about your day...never to know who "Aqua Lad" was. Fast forward to today and a similar question takes less than 7 seconds to retrieve the answer (or at least someones rendition of the answer) from this God-given website.
1) Google
Last but not least, you have to admit that Google has changed your life if you spend any time rattling on a keyboard. Few other products of our generation warrant it's name morphing into a formal verb. Sure, Yahoo was my search engine of choice during the college years (along with AltaVista), but today Google is first choice in the web searching realm.
That's it boys and girls. My top 5 technologies that have made a significant change to my life.
09 January, 2007
4 Books Every C++ Developer Should Have On His/Her Shelf
Over the years development languages change from project-to-project. A challenge for learning a language involves selection of what references are worthwhile. Far too often I've made poor selections in textbooks and selecting C++ references some years back was no exception.
I'd like to list the top 4 books that I've selected for my arsenal that I feel are essential to doing proper C++ (in no particular order):
1) The C++ Programming Language - Stroustrup
To understand C++, or any other language, you've gotta understand the language syntax and semantics. The rules...what's allowed and what is not. Who better to inform you of such things than the father of the programming language; nuff said.
2) C++ FAQs 2nd Edition - Marshall Cline
After you know the language syntax and semantics, the next thing you should be educated in is what should you do and what shouldn't you do. Marshall Cline identifies many of the pitfalls of common practices in an educational and surprisingly entertaining manner. I've attended a series of training sessions with the man himself and I highly recommend both the book and the courses if you can get someone else to pay for it :)
3) Effective C++ 3rd Edition - Scott Meyer
I'd consider this book to be the Bible with respect to best C++ programming practices. I cannot say enough good things about this book, but be forwarned...it expects you to understand the language to a fair degree. Don't buy this as your introduction to C++, buy this as a moderately experienced developer.
4) Effective STL - Scott Meyer
What is C++ without the STL.....the equivalent of a three-legged dog; never living up to the potential of a 4-legged dog. Come on, most interesting problem domains are complex enough to benefit from utilizing the STL including a great deal of embedded software products.
These are the books that I'd recommend to anyone developing in C++. I have a set of Sutter and Koenig books available to me and I've heard great things but since I haven't read them personally yet I cannot recommend them yet.
I'd like to list the top 4 books that I've selected for my arsenal that I feel are essential to doing proper C++ (in no particular order):
1) The C++ Programming Language - Stroustrup
To understand C++, or any other language, you've gotta understand the language syntax and semantics. The rules...what's allowed and what is not. Who better to inform you of such things than the father of the programming language; nuff said.
2) C++ FAQs 2nd Edition - Marshall Cline
After you know the language syntax and semantics, the next thing you should be educated in is what should you do and what shouldn't you do. Marshall Cline identifies many of the pitfalls of common practices in an educational and surprisingly entertaining manner. I've attended a series of training sessions with the man himself and I highly recommend both the book and the courses if you can get someone else to pay for it :)
3) Effective C++ 3rd Edition - Scott Meyer
I'd consider this book to be the Bible with respect to best C++ programming practices. I cannot say enough good things about this book, but be forwarned...it expects you to understand the language to a fair degree. Don't buy this as your introduction to C++, buy this as a moderately experienced developer.
4) Effective STL - Scott Meyer
What is C++ without the STL.....the equivalent of a three-legged dog; never living up to the potential of a 4-legged dog. Come on, most interesting problem domains are complex enough to benefit from utilizing the STL including a great deal of embedded software products.
These are the books that I'd recommend to anyone developing in C++. I have a set of Sutter and Koenig books available to me and I've heard great things but since I haven't read them personally yet I cannot recommend them yet.
06 January, 2007
I am the Victim of a Drive-By Coding
I've been a software developer for the past 9 years for various defense organizations.
A common practice, in times of need, is to employ temporary assets in the form of contractor engineers. This practice has time and time again proven to aid in the development of programs that have an aggressive schedule and a budget to accomodate the extensive salaries for contractors.
The typical role of a contractor is that of being brought in at a time of need and after that need has been eliminated the contractor(s) are shortly let go. The loftly salaries of these contractors is justifyable when you consider that they are brought in and placed immediately on 'critical path', and the understanding that they will be eliminated shortly after they are no longer needed. I've worked with dozens of contractors over the years and my opinion of the majority of them is quite positive. Most of them are not what I'd consider to be extraordinarily talented; the majority of contractors are pretty average. This coming from a software engineer that rates himself...average. Besides, on average....people are average. The reason I even mention this is to disolve any delusion that contractors are extraordinarily efficient, knowledgeable or brilliant. No, most are just like you or I.
I notable observation that I've made over these years is a typical side effect of contracted work. Note that typical contractors are involved with a project for a matter of months. Most often, they come in at the preliminary or detailed design phase and are responsible for designing and coding of some defined task(s). Keeping the short duration of involvement in mind, a common side-effect of contractor work is minimal or non-existant documentation in detailed design or the implementation phases of development. I don't necessarily fault contractors for failing to document their design or code. Over the years of playing revolving doors with companies they are never around long enough to see the pain and suffering resulting from updating a design or code that contains no documentation. One of my most recent sorrows entailed reviewing a design for a radio component from a contractor engineer. The majority of the minimal documentation was of the nature of 'do good things here'. I suffered through a code review of this product, and after a numbing 16 hours of reviewing I was near tears. One method in particular spanned approximately 3 pages (or ~120 lines since hardcopy is dead). It took better than an hour studying some of the most complicated code on the planet I finally realized that the method was responsible for scheduling message delivery with a priority scheme where messages intended for a single destination are given priority to those messages intended for multiple destinations. How was I suppose to know of this scheme.....well, not from the non-existent comments, nor from the radio interface control document (the priority scheme wasn't dictated by the hardware)...no, the only way to become enlightened to this design was to read the code.....the hundreds of lines of code....the code that rivals in complexity that of the Apollo space program. Days from now this contractor will be gone and some sap will be responsible for his product. This sap has become me on more than one occasion and I suspect it will once again be me. I look forward to the days of being bombarded with questions about this software component, followed by hours of diving into the code producing the answer and returning for a fresh set of questions. Better yet, fielding the software component will undoubtedly identify errors which will involve hours and hours of unpaid overtime.
I'll end this post with another plea. For God's sake, document your damn code!!
A common practice, in times of need, is to employ temporary assets in the form of contractor engineers. This practice has time and time again proven to aid in the development of programs that have an aggressive schedule and a budget to accomodate the extensive salaries for contractors.
The typical role of a contractor is that of being brought in at a time of need and after that need has been eliminated the contractor(s) are shortly let go. The loftly salaries of these contractors is justifyable when you consider that they are brought in and placed immediately on 'critical path', and the understanding that they will be eliminated shortly after they are no longer needed. I've worked with dozens of contractors over the years and my opinion of the majority of them is quite positive. Most of them are not what I'd consider to be extraordinarily talented; the majority of contractors are pretty average. This coming from a software engineer that rates himself...average. Besides, on average....people are average. The reason I even mention this is to disolve any delusion that contractors are extraordinarily efficient, knowledgeable or brilliant. No, most are just like you or I.
I notable observation that I've made over these years is a typical side effect of contracted work. Note that typical contractors are involved with a project for a matter of months. Most often, they come in at the preliminary or detailed design phase and are responsible for designing and coding of some defined task(s). Keeping the short duration of involvement in mind, a common side-effect of contractor work is minimal or non-existant documentation in detailed design or the implementation phases of development. I don't necessarily fault contractors for failing to document their design or code. Over the years of playing revolving doors with companies they are never around long enough to see the pain and suffering resulting from updating a design or code that contains no documentation. One of my most recent sorrows entailed reviewing a design for a radio component from a contractor engineer. The majority of the minimal documentation was of the nature of 'do good things here'. I suffered through a code review of this product, and after a numbing 16 hours of reviewing I was near tears. One method in particular spanned approximately 3 pages (or ~120 lines since hardcopy is dead). It took better than an hour studying some of the most complicated code on the planet I finally realized that the method was responsible for scheduling message delivery with a priority scheme where messages intended for a single destination are given priority to those messages intended for multiple destinations. How was I suppose to know of this scheme.....well, not from the non-existent comments, nor from the radio interface control document (the priority scheme wasn't dictated by the hardware)...no, the only way to become enlightened to this design was to read the code.....the hundreds of lines of code....the code that rivals in complexity that of the Apollo space program. Days from now this contractor will be gone and some sap will be responsible for his product. This sap has become me on more than one occasion and I suspect it will once again be me. I look forward to the days of being bombarded with questions about this software component, followed by hours of diving into the code producing the answer and returning for a fresh set of questions. Better yet, fielding the software component will undoubtedly identify errors which will involve hours and hours of unpaid overtime.
I'll end this post with another plea. For God's sake, document your damn code!!
Subscribe to:
Posts (Atom)