Organic Touchpoints
-
I submitted the following to a technical forum because the inability to successfully use a new tool. This reflects on the industry in general not just the software involved! "At the risk of editorializing (which of course is NOT the purpose of this or any other technical forum...) - As many of you know I have been writing production military and business programs since the early nineteen-sixties so have a leetle experience in the world of computing - in fact the first retail program conceived, designed, developed & marketed by me was Apple S.T.EM. [Smart Terminal EMulator] won't bore you with the details but did have to be concerned with successfully installing on any machine with appropriate environment. Now, of course, since then the hardware has become much more powerful and diverse(?) and the OS huge compared to Steve's original 12K ROM based OS & Basic - but, at the same time all areas of the computing world have advanced to where if enough care is taken in design, development and testing great feature rich and productive tools can be built - even by humans. I was taught many years ago by a Navy officer to "replicate the symmetry of nature" in creating software products - have almost always succeeded when this dictum was followed... When we are shown the block diagrams of the current suite of software tools, they are made to look very simple (with just 3 or 4 boxes) in the way they interconnect with other parts of the OS and Languages and Databases and Hardware and Networks and Browsers, etc, etc. but when you watch the linkages fly by during the 'generation' of the software it looks much more like multi-directional weaving. Now if you just picture a two dimensional seven thread by seven thread weave - that's a possible forty-nine touch points that can fail (my guess is it's more like: let's see... maybe SIX dimensions and FORTY threads in each dimension - yes that's FOUR BILLION, NINETY-SIX MILLION possible touch points to screw up. Are we able to even understand that many test cases, let alone code them? - I don't think so. So... maybe, just maybe, we need to rethink some of our design efforts in the hopes of reducing the number of layers and touch points to a more humanly manageable level and produce more 'organic' software." Comments?
-
I submitted the following to a technical forum because the inability to successfully use a new tool. This reflects on the industry in general not just the software involved! "At the risk of editorializing (which of course is NOT the purpose of this or any other technical forum...) - As many of you know I have been writing production military and business programs since the early nineteen-sixties so have a leetle experience in the world of computing - in fact the first retail program conceived, designed, developed & marketed by me was Apple S.T.EM. [Smart Terminal EMulator] won't bore you with the details but did have to be concerned with successfully installing on any machine with appropriate environment. Now, of course, since then the hardware has become much more powerful and diverse(?) and the OS huge compared to Steve's original 12K ROM based OS & Basic - but, at the same time all areas of the computing world have advanced to where if enough care is taken in design, development and testing great feature rich and productive tools can be built - even by humans. I was taught many years ago by a Navy officer to "replicate the symmetry of nature" in creating software products - have almost always succeeded when this dictum was followed... When we are shown the block diagrams of the current suite of software tools, they are made to look very simple (with just 3 or 4 boxes) in the way they interconnect with other parts of the OS and Languages and Databases and Hardware and Networks and Browsers, etc, etc. but when you watch the linkages fly by during the 'generation' of the software it looks much more like multi-directional weaving. Now if you just picture a two dimensional seven thread by seven thread weave - that's a possible forty-nine touch points that can fail (my guess is it's more like: let's see... maybe SIX dimensions and FORTY threads in each dimension - yes that's FOUR BILLION, NINETY-SIX MILLION possible touch points to screw up. Are we able to even understand that many test cases, let alone code them? - I don't think so. So... maybe, just maybe, we need to rethink some of our design efforts in the hopes of reducing the number of layers and touch points to a more humanly manageable level and produce more 'organic' software." Comments?
Frank Towle wrote:
So... maybe, just maybe, we need to rethink some of our design efforts in the hopes of reducing the number of layers and touch points to a more humanly manageable level and produce more 'organic' software."
Layers are good. Layers centralize operations and divide them into testable portions. Layers REDUCE the amount of interaction between different parts of a system by providing limited APIs instead of just letting every piece of code access every other piece of code. I tried to process the rest of your post, but honestly you need to cut down on the buzzwords and hyperbole... We're geeks here, not executives, at least for the most part. If you're going to talk about APIs and frameworks, just do so... All of this stuff about "weaving" and "touch points" and "threads" (I take it you're making an analogy here, not referring to actual process threads) kind of makes me cringe. Sorry to be so blunt, but I can't think of a nicer way to say it.
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels) -
Frank Towle wrote:
So... maybe, just maybe, we need to rethink some of our design efforts in the hopes of reducing the number of layers and touch points to a more humanly manageable level and produce more 'organic' software."
Layers are good. Layers centralize operations and divide them into testable portions. Layers REDUCE the amount of interaction between different parts of a system by providing limited APIs instead of just letting every piece of code access every other piece of code. I tried to process the rest of your post, but honestly you need to cut down on the buzzwords and hyperbole... We're geeks here, not executives, at least for the most part. If you're going to talk about APIs and frameworks, just do so... All of this stuff about "weaving" and "touch points" and "threads" (I take it you're making an analogy here, not referring to actual process threads) kind of makes me cringe. Sorry to be so blunt, but I can't think of a nicer way to say it.
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels)Hi Ian, Thanks for your thoughtful reply. Sure layers are good as long as they are totally isolated from each other. Probably the original 7-layer model proposed by my major hero Charlie Bachman would be a GOOD example. [Another hero of mine was Admiral Hopper - learned directly from both at Navy, DEC and GE/HIS long term assignments] BUT... the segregation between layers is either incomplete or total, i.e. the caller has very little if any idea what's going on at the next layer - just told to call this, don't worry about it when in fact we know assumptions are being made by the coder that may be wrong but get by the testers because 'it always worked before'. Sorry about 'buzzwords and hyperbole', I did warn about editorializing - you must be a geek with an English degree... Aren't APIs and frameworks sort of the same thing? Yes, of course I was making an analogy - draw 7 vertical lines then 7 horizontal lines over them that makes a weave of 7 squared or 49 intersections (touch points) right? what happens if one of the weaves isn't done right? Back to reality and software development: My original idea came after watching a MS slide show on LightSwitch in which my statement 'just a few boxes on top of each other with no interconnects' was what I saw and what was explained by the presenter. So... thinking well this seems to be a straight-forward implementation, lets see how it works -- 1. Installing LightSwitch required the installation or update of other components on my dev machine which, up until this time was working very nicely, thank you... But after ensuring my backup HD was safely removed to the vault (no really) I said sure go ahead and put up the rest of your toolkit. 2. Eventually restarted with new VS2010 (glad I got over the SP1 install issue several weeks ago) and got to intro tutorial, second step as I recall - couldn't connect to SQL Server even though I had followed installation instructions to the letter. 3. Finally found an obscure note to: stop SQLServer (ok) find %appsomething%/.... (what - talk about speaking english!!!) and delete the contents of SQLEXPRESS subdirectory. That got me past #2 and I could code the basic tutorial. But then when I hit F5 (that's coder talk)[It was during this exercise that I would look at the bottom of the VS screen and would see dozens of 'library' references flying by and wondering to myself "does anyone kn
-
Frank Towle wrote:
So... maybe, just maybe, we need to rethink some of our design efforts in the hopes of reducing the number of layers and touch points to a more humanly manageable level and produce more 'organic' software."
Layers are good. Layers centralize operations and divide them into testable portions. Layers REDUCE the amount of interaction between different parts of a system by providing limited APIs instead of just letting every piece of code access every other piece of code. I tried to process the rest of your post, but honestly you need to cut down on the buzzwords and hyperbole... We're geeks here, not executives, at least for the most part. If you're going to talk about APIs and frameworks, just do so... All of this stuff about "weaving" and "touch points" and "threads" (I take it you're making an analogy here, not referring to actual process threads) kind of makes me cringe. Sorry to be so blunt, but I can't think of a nicer way to say it.
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels)Just found this abstract from an ACM Turing award lecture titled "The programmer as navigator" given by Lord Bachman in 2007: 'Copernicus completely reoriented our view of astronomical phenomena when he suggested that the earth revolves about the sun. There is a growing feeling that data processing people would benefit if they were to accept a radically new point of view, one that would liberate the application programmer's thinking from the centralism of core storage and allow him the freedom to act as a navigator within a database. To do this, he must first learn the various navigational skills; then he must learn the "rules of the road" to avoid conflict with other programmers as they jointly navigate the database information space. This reorientation will cause as much anguish among programmers as the heliocentric theory did among ancient astronomers and theologians.' [This also relates back to work he was doing for GE back in the 1960's]
-
Hi Ian, Thanks for your thoughtful reply. Sure layers are good as long as they are totally isolated from each other. Probably the original 7-layer model proposed by my major hero Charlie Bachman would be a GOOD example. [Another hero of mine was Admiral Hopper - learned directly from both at Navy, DEC and GE/HIS long term assignments] BUT... the segregation between layers is either incomplete or total, i.e. the caller has very little if any idea what's going on at the next layer - just told to call this, don't worry about it when in fact we know assumptions are being made by the coder that may be wrong but get by the testers because 'it always worked before'. Sorry about 'buzzwords and hyperbole', I did warn about editorializing - you must be a geek with an English degree... Aren't APIs and frameworks sort of the same thing? Yes, of course I was making an analogy - draw 7 vertical lines then 7 horizontal lines over them that makes a weave of 7 squared or 49 intersections (touch points) right? what happens if one of the weaves isn't done right? Back to reality and software development: My original idea came after watching a MS slide show on LightSwitch in which my statement 'just a few boxes on top of each other with no interconnects' was what I saw and what was explained by the presenter. So... thinking well this seems to be a straight-forward implementation, lets see how it works -- 1. Installing LightSwitch required the installation or update of other components on my dev machine which, up until this time was working very nicely, thank you... But after ensuring my backup HD was safely removed to the vault (no really) I said sure go ahead and put up the rest of your toolkit. 2. Eventually restarted with new VS2010 (glad I got over the SP1 install issue several weeks ago) and got to intro tutorial, second step as I recall - couldn't connect to SQL Server even though I had followed installation instructions to the letter. 3. Finally found an obscure note to: stop SQLServer (ok) find %appsomething%/.... (what - talk about speaking english!!!) and delete the contents of SQLEXPRESS subdirectory. That got me past #2 and I could code the basic tutorial. But then when I hit F5 (that's coder talk)[It was during this exercise that I would look at the bottom of the VS screen and would see dozens of 'library' references flying by and wondering to myself "does anyone kn
Frank Towle wrote:
Thanks for your thoughtful reply. Sure layers are good as long as they are totally isolated from each other. Probably the original 7-layer model proposed by my major hero Charlie Bachman would be a GOOD example. [Another hero of mine was Admiral Hopper - learned directly from both at Navy, DEC and GE/HIS long term assignments]
Don't code based on arbitrary numbers of layers... Analyze the needs of your system, and build the layers based on the logical components. Just because some guy said seven is a good number, doesn't mean your particular system needs seven layers.
Frank Towle wrote:
BUT... the segregation between layers is either incomplete or total, i.e. the caller has very little if any idea what's going on at the next layer - just told to call this, don't worry about it when in fact we know assumptions are being made by the coder that may be wrong but get by the testers because 'it always worked before'.
In other words, you need a well-documented API... I doubt you'll find many people here who would disagree with that.
Frank Towle wrote:
Sorry about 'buzzwords and hyperbole', I did warn about editorializing - you must be a geek with an English degree... Aren't APIs and frameworks sort of the same thing?
The analogy was distracting from your point instead of illustrating it. No, I don't have an English degree... I have a Computer Science degree... Writing is a hobby, not my day job.
Frank Towle wrote:
But then when I hit F5 (that's coder talk)[It was during this exercise that I would look at the bottom of the VS screen and would see dozens of 'library' references flying by and wondering to myself "does anyone know what all these linkages are doing?"] ...
Isn't that the entire point of abstracting into layers? You don't have to know what all of those linkages are doing. You're not supposed to know. You just call the APIs and trust that the underlying framework will do its job.
Frank Towle wrote:
NOW: You really missed the meat of my posting which was [in middle paragraph] to design and develop software to mirror [no not disk drives] nature. Symmetry: think flowers have (?), trees
-
Just found this abstract from an ACM Turing award lecture titled "The programmer as navigator" given by Lord Bachman in 2007: 'Copernicus completely reoriented our view of astronomical phenomena when he suggested that the earth revolves about the sun. There is a growing feeling that data processing people would benefit if they were to accept a radically new point of view, one that would liberate the application programmer's thinking from the centralism of core storage and allow him the freedom to act as a navigator within a database. To do this, he must first learn the various navigational skills; then he must learn the "rules of the road" to avoid conflict with other programmers as they jointly navigate the database information space. This reorientation will cause as much anguish among programmers as the heliocentric theory did among ancient astronomers and theologians.' [This also relates back to work he was doing for GE back in the 1960's]
There you go again, spouting analogies without actually proposing anything concrete. It's like the managers that run around talking about how we should "think outside the box" and "adopt new paradigms" and "rethink our process flow", assuming that someone else will translate that into an actual course of action. So you're proposing that programmers do things differently... Differently how? What exactly should be done?
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels) -
There you go again, spouting analogies without actually proposing anything concrete. It's like the managers that run around talking about how we should "think outside the box" and "adopt new paradigms" and "rethink our process flow", assuming that someone else will translate that into an actual course of action. So you're proposing that programmers do things differently... Differently how? What exactly should be done?
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels)read my last post quoting Dr. Bachman - yah, it will be tough but 'think outside the box'! too many think Computer Science is 'Science' and that everything we need to know about the subject has been thought of - not even as expressed by Prof. Bachman just a few years ago.
-
read my last post quoting Dr. Bachman - yah, it will be tough but 'think outside the box'! too many think Computer Science is 'Science' and that everything we need to know about the subject has been thought of - not even as expressed by Prof. Bachman just a few years ago.
Again... Buzzwords that don't actually mean anything. Telling people to think differently is meaningless, as any decent programmer is going to look at a new problem from as many different directions as possible, and choose the one that works best. Programmers, like other engineers, are always looking for better ways to do things, so you're not actually contributing unless you actually suggest a new technique. All you're doing is suggesting that we explore new methods, which we're already doing.
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels)