Oh, what did we do before Wikipedia!
My wife is defining some software development training materials focusing on the object-oriented programming paradigm. One of the slides presents the idea that object-oriented programming is _a_ programming technique, not _the_ programming technique.
Far too often I think we get caught up with a new technology and believe that it is the end-all of software development. Object-oriented programming, agile development, Ruby-on-rails, . . . I think we all too often jump on the new technology bandwagon. It is worth a lunch-hour to investigate some of the other programming paradigms.
http://en.wikipedia.org/wiki/Programming_paradigm
17 June, 2007
15 April, 2007
Whiz Kid
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.
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.
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.
Subscribe to:
Posts (Atom)