As I stated in a previous entry, I've recently got back from an SPIE conference. This has been the first I've ever attended and with luck this won't be the last.
An interesting event that occur ed at this conference was the presentation of a technique for 'head-locating' in infrared camera images. While the technique didn't exactly blow my skirt up...while I have some experience in computer vision that isn't my current focus. What did however get my attention was the presenter....a grade school kid with an internship with Johns Hopkins. Not only did he author the paper, he presented as well and by all rights did so with more enthusiasm and professionalism that many of the adults.
Sure, the kid can locate a humans head in a busy scene....he can use terms like 'modality' and solve differential equations....but dollars to donuts he's never seen a boobie first-hand.
That is the only comfort that lets me sleep at night.
15 April, 2007
Minnesota Bound
I am currently en route from Orlando, FL on my way back from an SPIE conference where a colleague authored and presented a paper. I tagged along as a result of my co-author status.....senor' coat-tails has been the title that comes to mind.
A number of interesting topics were presented, primarily concerned with wireless communications and fields of study concerning sensors. An observation worth noting was the evident differences in the disciplines of the presenters and how it affected the detail of the topic and the presentation style.
As I've said in the past, I am a software engineer by trade, having a BS and MS degree in Computer Science. Both school and industry alike, I've been surrounded by individuals both in Comp Sci as well as other engineering disciplines such as physics, electrical as well as mechanical engineering and the differences in the disciplines are very evident.
As much as a person wishes not to admit it....computer science is still a 'soft' science. Sure, it is far more disciplined than the likes of some other engineering persuasions, but is still far less structured as the likes of pure mathematics, physics, optics, electrical or mechanical engineering. The majority of the presentations were conducted by doctorates of physics, electrical or optical engineering, but every once in a while you'd get a computer science major up there and the presentation took a different tone. The best way I can say it is that the logic was softer or more fuzzy. Most presentations from more formal disciplines would be followed with mathematical description of the technology. Computer science presentations rarely had such formality, with the occasional exception to a presenter that had an undergrad degree in a more disciplined major and a PhD in computer science.
Am I knocking Comp Sci...to a degree I am doing just that. With the minor exception to those that pursue theoretical computer science focuses which are more in line with formal mathematics the majority of us still groan in the presence of a formal proof, a detailed description of the fundamental technology in the only pure language...mathematics. As a result, I think we give up the things that could make our discipline more successful. I can, for one, say that if we took a more structured look at proving techniques on paper rather than jump in and start coding we may have less error-prone technologies.
I'm not touting that we should all begin doing formal proofs on the effectiveness and efficiency of our authored algorithms. Instead, I'm saying that perhaps it's worth a 1/2 a day investigation on paper before firing up your trusty editor out of the gate.
A number of interesting topics were presented, primarily concerned with wireless communications and fields of study concerning sensors. An observation worth noting was the evident differences in the disciplines of the presenters and how it affected the detail of the topic and the presentation style.
As I've said in the past, I am a software engineer by trade, having a BS and MS degree in Computer Science. Both school and industry alike, I've been surrounded by individuals both in Comp Sci as well as other engineering disciplines such as physics, electrical as well as mechanical engineering and the differences in the disciplines are very evident.
As much as a person wishes not to admit it....computer science is still a 'soft' science. Sure, it is far more disciplined than the likes of some other engineering persuasions, but is still far less structured as the likes of pure mathematics, physics, optics, electrical or mechanical engineering. The majority of the presentations were conducted by doctorates of physics, electrical or optical engineering, but every once in a while you'd get a computer science major up there and the presentation took a different tone. The best way I can say it is that the logic was softer or more fuzzy. Most presentations from more formal disciplines would be followed with mathematical description of the technology. Computer science presentations rarely had such formality, with the occasional exception to a presenter that had an undergrad degree in a more disciplined major and a PhD in computer science.
Am I knocking Comp Sci...to a degree I am doing just that. With the minor exception to those that pursue theoretical computer science focuses which are more in line with formal mathematics the majority of us still groan in the presence of a formal proof, a detailed description of the fundamental technology in the only pure language...mathematics. As a result, I think we give up the things that could make our discipline more successful. I can, for one, say that if we took a more structured look at proving techniques on paper rather than jump in and start coding we may have less error-prone technologies.
I'm not touting that we should all begin doing formal proofs on the effectiveness and efficiency of our authored algorithms. Instead, I'm saying that perhaps it's worth a 1/2 a day investigation on paper before firing up your trusty editor out of the gate.
04 March, 2007
Technology Webcasts
Recent availability of personal high-speed networking made available delivery of tech netcasts over the web. Two of my favorite regular broadcasts include 1) CommandN: available from youtube.com and 2) Tech Talks off of video.google.com.
Worth a view if you haven't seen them before.
Worth a view if you haven't seen them before.
28 February, 2007
Desires and Diversions
In college our computer science department had a series of videos, each with a computer science theme. One of the "Distinguished Lecutres" Series was given by Allen Newell entitled Desires and Diversions and is one of the most motivational lectures I've ever experienced. I recently located it on the web and figured I'd share.
I've recently uploaded to YouTube, links below:
I've recently uploaded to YouTube, links below:
26 February, 2007
Tinkering with Ruby
I've recently decided to expand on my OO arsenal by picking up Ruby and Python.
Not much to discuss yet as I am just beginning my journey into Ruby.
One thing perhaps worth noting is the reason that I chose Ruby, that Scott Meyer a notable authority of C++ has high opinions on Ruby and "Ruby on Rails" stating that he feels that it's the next generation object-oriented language.
Not much to discuss yet as I am just beginning my journey into Ruby.
One thing perhaps worth noting is the reason that I chose Ruby, that Scott Meyer a notable authority of C++ has high opinions on Ruby and "Ruby on Rails" stating that he feels that it's the next generation object-oriented language.
14 February, 2007
The Dirty Little Secret of CMMI-Level 5
There are a-many things that I think are great concepts but tend to fall apart in the real world; for instance "always tell the truth", "turn the other cheek", "fat-free desserts"...sure, they are great ideas on paper, but when practically implemented they leave you with a black eye, two bruised cheeks, and a mouthful of what tastes like damp sawdust.
The first time I heard about the CMM-level assessment concept I thought what a great idea. Have an independent assessment of your companies strengths and weaknesses, identify an action plan to strengthen your weakness and strive for an even stronger level of capabilities by reaching for the next ladder rung and just work your way to the top. Hey, it was authored by a character from CMU, a notable university, it must be good.
I won't speculate on what might have been, but this concept took a downward spin the day that the Department of Defense decided that all defense contractors have a deadline to achieve level-5 or risk loss of program funding (sigh). Since that wise and ever-so-informed decision (wink) it's been every defense contractor's ambition to make it up to the last rung as quickly as possible. I've witnessed some of the most unethical behaviors in pursuit of this highly acclaimed prize that I only wish I never again see. Contracted independent assessor findings bought and paid for, the hand-selecting of individuals that will mindlessly tout from the Book of Process, and 9th inning e-mails identifying the expected questions assessors will be asking and the proper response (with emphasis on stating only the defined answer and directing to say no more). I ask you, in the pursuit of all contractors achieving level-5 how greatly has it reduced the cost of development programs? Not a dime, it has instead increased program costs.
Sorry for the short rant, the validity of CMMI assessments isn't the subject I wanted to write about, but is directly related. See, now that most defense contractors have fully embraced CMM there is an underlying tone that comes with the price of admission. Assets are all interchangeable; this is the basis of CMM, take a development process and define enough paperwork and instructions such that any monkey that can read can follow it to success (hearty laugh). In recent history employees somehow lost loyalty to their employers and as a result the employers suffer high turn-over. How do you fix this you ask.....well let me tell you.......CMMI level-5(tah da). This magic elixir will allow you to lose an employee, snag an innocent pedestrian off the street, strap a cubical 'round them, hand 'em your defined process and procedures and not miss a beat. Employees are one-size-fits-all and are replaceable at a moments notice.
While I've always speculated that this is how the Mahogany Row muckety mucks looked at their underlings it became obviously apparent as I spent 4 1/2 hours in process training this morning. When asked how the company selects teams for a newly defined program he all but said pick who is available. "How do you find candidates with the proper tool, development methodology, domain experience and such" I asked. "I don't know" he replied. So what you're saying is that there is no way to establish my skill sets nor career interests in hopes to be recognized as a candidate for a new exciting program. What you are saying is that their is no way to align my career aspirations, nor technical experiences, or interests with the companies goals? So even though I accepted a position at company X because they were working in an interesting domain Y and I have expertise in Y when that program is completed there is no way for me to be selected for a new project in Y? Are you kidding?
My point is, I'm still young, ambitious and still love working on 'interesting problems'. I hired into my current company because they have 'interesting problems' and a boat-load of dull ones. Looking at me as a cog and not taking into account my experiences and technical desires you risk losing me when you blindly move me to a position not in line with my individual goals. Treating me like a replaceable cog will increase the likelihood that I'll leave and only increases your turn-over which was the reason you adopted CMMI. The solution becomes the problem.
The first time I heard about the CMM-level assessment concept I thought what a great idea. Have an independent assessment of your companies strengths and weaknesses, identify an action plan to strengthen your weakness and strive for an even stronger level of capabilities by reaching for the next ladder rung and just work your way to the top. Hey, it was authored by a character from CMU, a notable university, it must be good.
I won't speculate on what might have been, but this concept took a downward spin the day that the Department of Defense decided that all defense contractors have a deadline to achieve level-5 or risk loss of program funding (sigh). Since that wise and ever-so-informed decision (wink) it's been every defense contractor's ambition to make it up to the last rung as quickly as possible. I've witnessed some of the most unethical behaviors in pursuit of this highly acclaimed prize that I only wish I never again see. Contracted independent assessor findings bought and paid for, the hand-selecting of individuals that will mindlessly tout from the Book of Process, and 9th inning e-mails identifying the expected questions assessors will be asking and the proper response (with emphasis on stating only the defined answer and directing to say no more). I ask you, in the pursuit of all contractors achieving level-5 how greatly has it reduced the cost of development programs? Not a dime, it has instead increased program costs.
Sorry for the short rant, the validity of CMMI assessments isn't the subject I wanted to write about, but is directly related. See, now that most defense contractors have fully embraced CMM there is an underlying tone that comes with the price of admission. Assets are all interchangeable; this is the basis of CMM, take a development process and define enough paperwork and instructions such that any monkey that can read can follow it to success (hearty laugh). In recent history employees somehow lost loyalty to their employers and as a result the employers suffer high turn-over. How do you fix this you ask.....well let me tell you.......CMMI level-5(tah da). This magic elixir will allow you to lose an employee, snag an innocent pedestrian off the street, strap a cubical 'round them, hand 'em your defined process and procedures and not miss a beat. Employees are one-size-fits-all and are replaceable at a moments notice.
While I've always speculated that this is how the Mahogany Row muckety mucks looked at their underlings it became obviously apparent as I spent 4 1/2 hours in process training this morning. When asked how the company selects teams for a newly defined program he all but said pick who is available. "How do you find candidates with the proper tool, development methodology, domain experience and such" I asked. "I don't know" he replied. So what you're saying is that there is no way to establish my skill sets nor career interests in hopes to be recognized as a candidate for a new exciting program. What you are saying is that their is no way to align my career aspirations, nor technical experiences, or interests with the companies goals? So even though I accepted a position at company X because they were working in an interesting domain Y and I have expertise in Y when that program is completed there is no way for me to be selected for a new project in Y? Are you kidding?
My point is, I'm still young, ambitious and still love working on 'interesting problems'. I hired into my current company because they have 'interesting problems' and a boat-load of dull ones. Looking at me as a cog and not taking into account my experiences and technical desires you risk losing me when you blindly move me to a position not in line with my individual goals. Treating me like a replaceable cog will increase the likelihood that I'll leave and only increases your turn-over which was the reason you adopted CMMI. The solution becomes the problem.
31 January, 2007
Code Generators
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.
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.
Subscribe to:
Posts (Atom)