What are the intractable problems in software? [modified]
-
I was out planting the borders today. It's a hugely satisfying thing to do, and it lets the mind wander where it will. Recommended. I don't know why, but whilst planting, for some reason top bloke and all round spiffing chap, Grizzly Adams[^] sprang to mind. In a purely innocent way, I might add. Anyway, I got to thinking: here's a chap who must spend an incredible amount of resource (time/money/blood/sweat/tears) trying to solve problems created by software. This immediately turned my mind inside out: software should be a tool which is used to solve other problems, why is it introducing more problems? And that led me to ask: where and why do these problems in software occur? Is it the user base? Are users not adequately expert in the tools? Are the tools too complicated that only a comparative few competently understand and use them? Are there too many tools that are incompatible with each other? (such as OOP and RDBMS) Is a software solution not always right for the given problem, but shoe-horned and botched into it? And some other questions popped up, which I can't now remember. Feel free to add your own. One epiphany that emerged was this: The more we abstract from the actual metal of a machine, the easier we make it to do a specific thing but it seems we make it harder to make two specific-easier-things to talk to each other. This might not be true, but to me it rings true. So what and why are the intractable problems in software?
print "http://www.codeproject.com".toURL().text Ain't that Groovy?
modified on Thursday, March 26, 2009 7:17 PM
-
I was out planting the borders today. It's a hugely satisfying thing to do, and it lets the mind wander where it will. Recommended. I don't know why, but whilst planting, for some reason top bloke and all round spiffing chap, Grizzly Adams[^] sprang to mind. In a purely innocent way, I might add. Anyway, I got to thinking: here's a chap who must spend an incredible amount of resource (time/money/blood/sweat/tears) trying to solve problems created by software. This immediately turned my mind inside out: software should be a tool which is used to solve other problems, why is it introducing more problems? And that led me to ask: where and why do these problems in software occur? Is it the user base? Are users not adequately expert in the tools? Are the tools too complicated that only a comparative few competently understand and use them? Are there too many tools that are incompatible with each other? (such as OOP and RDBMS) Is a software solution not always right for the given problem, but shoe-horned and botched into it? And some other questions popped up, which I can't now remember. Feel free to add your own. One epiphany that emerged was this: The more we abstract from the actual metal of a machine, the easier we make it to do a specific thing but it seems we make it harder to make two specific-easier-things to talk to each other. This might not be true, but to me it rings true. So what and why are the intractable problems in software?
print "http://www.codeproject.com".toURL().text Ain't that Groovy?
modified on Thursday, March 26, 2009 7:17 PM
martin_hughes wrote:
I was out planting the boarders
You take in boarders at your house? Well, I really hope they're dead if you're planting them in the garden.
Best wishes, Hans
[CodeProject Forum Guidelines] [How To Ask A Question] [My Articles]
-
martin_hughes wrote:
I was out planting the boarders
You take in boarders at your house? Well, I really hope they're dead if you're planting them in the garden.
Best wishes, Hans
[CodeProject Forum Guidelines] [How To Ask A Question] [My Articles]
Yeah, well, see the thing about that was..... *runs*
print "http://www.codeproject.com".toURL().text Ain't that Groovy?
-
I was out planting the borders today. It's a hugely satisfying thing to do, and it lets the mind wander where it will. Recommended. I don't know why, but whilst planting, for some reason top bloke and all round spiffing chap, Grizzly Adams[^] sprang to mind. In a purely innocent way, I might add. Anyway, I got to thinking: here's a chap who must spend an incredible amount of resource (time/money/blood/sweat/tears) trying to solve problems created by software. This immediately turned my mind inside out: software should be a tool which is used to solve other problems, why is it introducing more problems? And that led me to ask: where and why do these problems in software occur? Is it the user base? Are users not adequately expert in the tools? Are the tools too complicated that only a comparative few competently understand and use them? Are there too many tools that are incompatible with each other? (such as OOP and RDBMS) Is a software solution not always right for the given problem, but shoe-horned and botched into it? And some other questions popped up, which I can't now remember. Feel free to add your own. One epiphany that emerged was this: The more we abstract from the actual metal of a machine, the easier we make it to do a specific thing but it seems we make it harder to make two specific-easier-things to talk to each other. This might not be true, but to me it rings true. So what and why are the intractable problems in software?
print "http://www.codeproject.com".toURL().text Ain't that Groovy?
modified on Thursday, March 26, 2009 7:17 PM
-
I was out planting the borders today. It's a hugely satisfying thing to do, and it lets the mind wander where it will. Recommended. I don't know why, but whilst planting, for some reason top bloke and all round spiffing chap, Grizzly Adams[^] sprang to mind. In a purely innocent way, I might add. Anyway, I got to thinking: here's a chap who must spend an incredible amount of resource (time/money/blood/sweat/tears) trying to solve problems created by software. This immediately turned my mind inside out: software should be a tool which is used to solve other problems, why is it introducing more problems? And that led me to ask: where and why do these problems in software occur? Is it the user base? Are users not adequately expert in the tools? Are the tools too complicated that only a comparative few competently understand and use them? Are there too many tools that are incompatible with each other? (such as OOP and RDBMS) Is a software solution not always right for the given problem, but shoe-horned and botched into it? And some other questions popped up, which I can't now remember. Feel free to add your own. One epiphany that emerged was this: The more we abstract from the actual metal of a machine, the easier we make it to do a specific thing but it seems we make it harder to make two specific-easier-things to talk to each other. This might not be true, but to me it rings true. So what and why are the intractable problems in software?
print "http://www.codeproject.com".toURL().text Ain't that Groovy?
modified on Thursday, March 26, 2009 7:17 PM
I really think that the fact that progress is so fast that nothing gets a chance to become settled, is a major problem. Does that make sense? A lot of thats in that. Progress is wonderful and although I enjoyed it, at the time, I would hate to have to go back to assembler for everything, it's just that there is so much of it (progress/change that is). But particularly as I have got older, and things take a little longer to sink in, I wish there could be some plateaux occasionally. As you have said, much of the progress is divergent and/or incompatible. It would be terrible if there were only one way to do things, it is nearly as bad when there are thousands. There, I feel better now. Thanks!
Henry Minute Do not read medical books! You could die of a misprint. - Mark Twain Girl: (staring) "Why do you need an icy cucumber?" “I want to report a fraud. The government is lying to us all.”
-
I was out planting the borders today. It's a hugely satisfying thing to do, and it lets the mind wander where it will. Recommended. I don't know why, but whilst planting, for some reason top bloke and all round spiffing chap, Grizzly Adams[^] sprang to mind. In a purely innocent way, I might add. Anyway, I got to thinking: here's a chap who must spend an incredible amount of resource (time/money/blood/sweat/tears) trying to solve problems created by software. This immediately turned my mind inside out: software should be a tool which is used to solve other problems, why is it introducing more problems? And that led me to ask: where and why do these problems in software occur? Is it the user base? Are users not adequately expert in the tools? Are the tools too complicated that only a comparative few competently understand and use them? Are there too many tools that are incompatible with each other? (such as OOP and RDBMS) Is a software solution not always right for the given problem, but shoe-horned and botched into it? And some other questions popped up, which I can't now remember. Feel free to add your own. One epiphany that emerged was this: The more we abstract from the actual metal of a machine, the easier we make it to do a specific thing but it seems we make it harder to make two specific-easier-things to talk to each other. This might not be true, but to me it rings true. So what and why are the intractable problems in software?
print "http://www.codeproject.com".toURL().text Ain't that Groovy?
modified on Thursday, March 26, 2009 7:17 PM
That is a really interesting question, one which I ponder often. I already feel that using a mouse and keyboard is so incredibly outdated and redundant. It's the same with coding. I constantly think of how developing software will change over time; say 20 years from now, we will have entirely new and different methods of programming and coding. The idea of an intuitive programming language framework that can be applied in a straight forward and bug free way is really appealing, so much so that sometimes I feel stupid that I am still actually typing out code. Imagine just being able to TALK to the computer and tell it what you want it to perform, or more importantly what you DON'T want it to do. Imagine the computer being able to not only interpret your instructions, but make suggestions or corrections based on its previous producitons. Imagine a framework that can learn from mistakes and bugs that have been made in previous releases, not just from your work, but from other peoples works around the world. Imagine a pool of code and resources that arent available for YOU to browse and download, but are there for the FRAMEWORK itself to extract and use, and possibly alter or update, depending on it's requirements. Imagine calling this framework HAL... ;P We all know the elements of a good development cycle, but unless we are completely anal, we probably don't follow it to the letter. I'm sure most of us realise the importance of relaying a bug in code to the correct channels and following the right procedures, but on a Friday afternoon taking the 5 mins to fix the bug is a lot more appealing that taking 15 mins to fill out the appropriate forms. My point is that even the best of us can have an off day, or get bored with what we are doing, and as long as we are human, we can stray from the path of 'perfect programming'. The intrinsic problem with programs is the PEOPLE THAT PROGRAM THEM. As long as humans are designing and developing software there will always be intractable problems with the product. Obviously if you had some intelligent system developing the programs for you, someone would have had to program the intelligent system in the first place, leaving anything it creates open to issues from the get go. The more complex a system becomes, the higher the chances of something bad happening. x+y=z is a simple formula. Put a string in there and something goes wrong, but it's much easier to identify the problem. Complicate the formula and there are more and
-
I was out planting the borders today. It's a hugely satisfying thing to do, and it lets the mind wander where it will. Recommended. I don't know why, but whilst planting, for some reason top bloke and all round spiffing chap, Grizzly Adams[^] sprang to mind. In a purely innocent way, I might add. Anyway, I got to thinking: here's a chap who must spend an incredible amount of resource (time/money/blood/sweat/tears) trying to solve problems created by software. This immediately turned my mind inside out: software should be a tool which is used to solve other problems, why is it introducing more problems? And that led me to ask: where and why do these problems in software occur? Is it the user base? Are users not adequately expert in the tools? Are the tools too complicated that only a comparative few competently understand and use them? Are there too many tools that are incompatible with each other? (such as OOP and RDBMS) Is a software solution not always right for the given problem, but shoe-horned and botched into it? And some other questions popped up, which I can't now remember. Feel free to add your own. One epiphany that emerged was this: The more we abstract from the actual metal of a machine, the easier we make it to do a specific thing but it seems we make it harder to make two specific-easier-things to talk to each other. This might not be true, but to me it rings true. So what and why are the intractable problems in software?
print "http://www.codeproject.com".toURL().text Ain't that Groovy?
modified on Thursday, March 26, 2009 7:17 PM
martin_hughes wrote:
the easier we make it to do a specific thing but it seems we make it harder to make two specific-easier-things to talk to each other.
IMHO it doesn't have to be that way, it's only that way because many of the people who design these pieces don't know what they're doing.
¡El diablo está en mis pantalones! ¡Mire, mire! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! VCF Blog Just Say No to Web 2 Point Oh
-
I was out planting the borders today. It's a hugely satisfying thing to do, and it lets the mind wander where it will. Recommended. I don't know why, but whilst planting, for some reason top bloke and all round spiffing chap, Grizzly Adams[^] sprang to mind. In a purely innocent way, I might add. Anyway, I got to thinking: here's a chap who must spend an incredible amount of resource (time/money/blood/sweat/tears) trying to solve problems created by software. This immediately turned my mind inside out: software should be a tool which is used to solve other problems, why is it introducing more problems? And that led me to ask: where and why do these problems in software occur? Is it the user base? Are users not adequately expert in the tools? Are the tools too complicated that only a comparative few competently understand and use them? Are there too many tools that are incompatible with each other? (such as OOP and RDBMS) Is a software solution not always right for the given problem, but shoe-horned and botched into it? And some other questions popped up, which I can't now remember. Feel free to add your own. One epiphany that emerged was this: The more we abstract from the actual metal of a machine, the easier we make it to do a specific thing but it seems we make it harder to make two specific-easier-things to talk to each other. This might not be true, but to me it rings true. So what and why are the intractable problems in software?
print "http://www.codeproject.com".toURL().text Ain't that Groovy?
modified on Thursday, March 26, 2009 7:17 PM
I think this guy's sig[^] makes a fantastic point. Another factor that comes to mind: software is probably the only field - with the exception of government and economics - where the incompetent can not only survive, but actually thrive.
Cheers, Vıkram.
Carpe Diem.
-
I was out planting the borders today. It's a hugely satisfying thing to do, and it lets the mind wander where it will. Recommended. I don't know why, but whilst planting, for some reason top bloke and all round spiffing chap, Grizzly Adams[^] sprang to mind. In a purely innocent way, I might add. Anyway, I got to thinking: here's a chap who must spend an incredible amount of resource (time/money/blood/sweat/tears) trying to solve problems created by software. This immediately turned my mind inside out: software should be a tool which is used to solve other problems, why is it introducing more problems? And that led me to ask: where and why do these problems in software occur? Is it the user base? Are users not adequately expert in the tools? Are the tools too complicated that only a comparative few competently understand and use them? Are there too many tools that are incompatible with each other? (such as OOP and RDBMS) Is a software solution not always right for the given problem, but shoe-horned and botched into it? And some other questions popped up, which I can't now remember. Feel free to add your own. One epiphany that emerged was this: The more we abstract from the actual metal of a machine, the easier we make it to do a specific thing but it seems we make it harder to make two specific-easier-things to talk to each other. This might not be true, but to me it rings true. So what and why are the intractable problems in software?
print "http://www.codeproject.com".toURL().text Ain't that Groovy?
modified on Thursday, March 26, 2009 7:17 PM
martin_hughes wrote:
So what and why are the intractable problems in software?
A major problem is the design-methodology-of-the-day mentality that puts coding before requirements definition and analysis. The race to market has become more important than bulding a product that actually works. A contributing component, too, is the demise of the user documentation. Once upon a time both hardware and software arrived in a shrink wrapped box with a thick, readable manual that the user could study before using the product. Now we have to fire it up to find the usually worthless online help, only to discover that we've already clicked all the wrong things in the flashy but non-intuitive user hostile interface. Once upon a time we had functional flow diagrams, interface control documents, and specifications that everyone followed or everyone agreed to change before a deviation was permitted. Modules were reviewed by other programmers, and tested by someone other than the designer. Such problems didn't occur then, but it did take longer to complete - and validate - the final product. On the plus side, the products worked, and the customer received what was paid for.
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
-
I was out planting the borders today. It's a hugely satisfying thing to do, and it lets the mind wander where it will. Recommended. I don't know why, but whilst planting, for some reason top bloke and all round spiffing chap, Grizzly Adams[^] sprang to mind. In a purely innocent way, I might add. Anyway, I got to thinking: here's a chap who must spend an incredible amount of resource (time/money/blood/sweat/tears) trying to solve problems created by software. This immediately turned my mind inside out: software should be a tool which is used to solve other problems, why is it introducing more problems? And that led me to ask: where and why do these problems in software occur? Is it the user base? Are users not adequately expert in the tools? Are the tools too complicated that only a comparative few competently understand and use them? Are there too many tools that are incompatible with each other? (such as OOP and RDBMS) Is a software solution not always right for the given problem, but shoe-horned and botched into it? And some other questions popped up, which I can't now remember. Feel free to add your own. One epiphany that emerged was this: The more we abstract from the actual metal of a machine, the easier we make it to do a specific thing but it seems we make it harder to make two specific-easier-things to talk to each other. This might not be true, but to me it rings true. So what and why are the intractable problems in software?
print "http://www.codeproject.com".toURL().text Ain't that Groovy?
modified on Thursday, March 26, 2009 7:17 PM
The single most overarching intractable problem in software right now is that people *think* there is a problem and keep trying to solve it in ever more complex and fanciful ways when in fact there are no problems of any kind in the development world. Right now there is a tool available to accomplish anything you put your imagination to. In fact too many tools, too many options, it's too easy and when the going gets easy innovation falls by the wayside.
-
I was out planting the borders today. It's a hugely satisfying thing to do, and it lets the mind wander where it will. Recommended. I don't know why, but whilst planting, for some reason top bloke and all round spiffing chap, Grizzly Adams[^] sprang to mind. In a purely innocent way, I might add. Anyway, I got to thinking: here's a chap who must spend an incredible amount of resource (time/money/blood/sweat/tears) trying to solve problems created by software. This immediately turned my mind inside out: software should be a tool which is used to solve other problems, why is it introducing more problems? And that led me to ask: where and why do these problems in software occur? Is it the user base? Are users not adequately expert in the tools? Are the tools too complicated that only a comparative few competently understand and use them? Are there too many tools that are incompatible with each other? (such as OOP and RDBMS) Is a software solution not always right for the given problem, but shoe-horned and botched into it? And some other questions popped up, which I can't now remember. Feel free to add your own. One epiphany that emerged was this: The more we abstract from the actual metal of a machine, the easier we make it to do a specific thing but it seems we make it harder to make two specific-easier-things to talk to each other. This might not be true, but to me it rings true. So what and why are the intractable problems in software?
print "http://www.codeproject.com".toURL().text Ain't that Groovy?
modified on Thursday, March 26, 2009 7:17 PM
<blockquote class="FQ"><div class="FQA">martin_hughes wrote:</div>So what and why are the intractable problems in software? </blockquote> 1. Human Nature 2. Programmers 3. Programmers' egos 4. the need to support legacy applications resulting in OS and IDE bloat. 5. The "feature race" driven nature of all software development 6. The current environment in which networked and internet-connected computers are under frequent attack (security issues). However, I am not complaining : taken all together, imho, these factors (and countless othes) result in a virtual full employment act for programmers :) A frequent image I used in the mid-1980's (yes, I am from the Jurassic, when the mainframe glaciers, and their priestly attendants, began to recede, and the "personal computer" emerged from electronic-hobbyists, geeks and clever Svengalian entrepeneurs) was that software development for personal computers of that era was very much like looking at a stained old sepia-tone photograph from the early 1920's or so where a group of people in heavy dust-cloaks and goggles stood next to a car on some washboard-rugged road : one of the people in the picture holding up the crank used to start the car. Fast forward to 2009 : every time I open the select-a-file dialog in Windows XP, have to choose to view in "details" mode, and then have to order by date so I can see the most recent files ... because the stupid thing does not preserve last-used state, and gives you no way to configure its state ... I wonder what's changed. My mind boggles at the attention given to a device called the iPhone that, in its first incarnation, did not allow cut and paste. At the same time ... even as early as late sixties ... at Xerox Parc Labs, as many of you know so well, you had bit-mapped graphical interfaces, icons, mouse, networking, high-level abstract development langauages like SmallTalk and Sail and JAM (the precursor of PostScript) : <a href="http://en.wikipedia.org/wiki/NLS\_(computer\_system)">http://en.wikipedia.org/wiki/NLS\_(computer\_system)</a>[<a href="http://en.wikipedia.org/wiki/NLS\_(computer\_system)" target="_blank" title="New Window">^</a>] <a href="http://en.wikipedia.org/wiki/The\_Mother\_of\_All\_Demos">http://en.wikipedia.org/wiki/The\_Mother\_of\_All\_Demos</a>[<a href="http://en.wikipedia.org/wiki/The\_Mother\_of\_All\_Demos" target="_blank" title="New Window">^</a>] But, like I say, I am not complaining; I like Visual Studio and C#
-
I think this guy's sig[^] makes a fantastic point. Another factor that comes to mind: software is probably the only field - with the exception of government and economics - where the incompetent can not only survive, but actually thrive.
Cheers, Vıkram.
Carpe Diem.
Don't you just bleeding hate that? :mad: A year ago almost, I was contacted by a financial firm to consult and potentially redevelop their systems (amongst several things, they own a chain of supermarket stores and the distribution of all the goods. Big operation) I spent over a month slaving away on their structure and applications (they owned the source code) and my was it terrible architecture or what?! When I finally told them that and gave them an offer on how much time and money this was going to cost them to fix to make it right and working (for a change) they said that was too expensive and they went with someone who offered nearly half of what I offered. Grapevine says they're tearing their hair out and which that they went with me. At the time, when they said no, they looked at me like "What the !@#$ are you talking about?!!! We paid good money for this and we're not gonna pay more to make it work!"
-
I was out planting the borders today. It's a hugely satisfying thing to do, and it lets the mind wander where it will. Recommended. I don't know why, but whilst planting, for some reason top bloke and all round spiffing chap, Grizzly Adams[^] sprang to mind. In a purely innocent way, I might add. Anyway, I got to thinking: here's a chap who must spend an incredible amount of resource (time/money/blood/sweat/tears) trying to solve problems created by software. This immediately turned my mind inside out: software should be a tool which is used to solve other problems, why is it introducing more problems? And that led me to ask: where and why do these problems in software occur? Is it the user base? Are users not adequately expert in the tools? Are the tools too complicated that only a comparative few competently understand and use them? Are there too many tools that are incompatible with each other? (such as OOP and RDBMS) Is a software solution not always right for the given problem, but shoe-horned and botched into it? And some other questions popped up, which I can't now remember. Feel free to add your own. One epiphany that emerged was this: The more we abstract from the actual metal of a machine, the easier we make it to do a specific thing but it seems we make it harder to make two specific-easier-things to talk to each other. This might not be true, but to me it rings true. So what and why are the intractable problems in software?
print "http://www.codeproject.com".toURL().text Ain't that Groovy?
modified on Thursday, March 26, 2009 7:17 PM
IMHO the main philosophical problem is that the linear, logical world of computer processing maps horribly to our real world where exceptions to the rules are the norm. Most of the time, software is built following reasonable abstractions of the real world processes - let's call them specifications. However these specifications do not follow exactly what a human operator would execute - programmers have the tendency to abstract every "flow" and reconduct them to already-solved cases. On the other hand, human operators tend to take shortcuts, jumping steps, cutting corners to get the problem solved. At my current job, specifications are half a page of rules and twenty-three pages of exceptions. Our tools are not built to deal easily with this kind of job. That's why we try to invent extensibility frameworks, "intelligent" systems, rule-based engines... but we're not quite there yet. Add to this, of course, that specifications are not written in stone, they evolve with time. This may lead to the need to rearchitect the framework, but often there's not enough time => A quick'n'dirty patch addresses the problem, but adds its weight to the maintainability of the package. And, as you highlighted, there's the problem of communication across different abstractions. There's no real solution, except making good use of the braincase. Sometimes it's easier to change the habits of the user, sometimes it's better to ignore his explicit requests and spend some time in his office to see how they work, sometimes it's better to spend extra time in designing a really flexible framework that requires negligible time to change the business rules. That's what makes our job interesting. BTW, this is why I absolutely hate Italian laws that assimilate the computer programmer/analyst job to the factory worker one. There's no way our job can be compared to working on an assembly line. End of Rant.
Luca The Price of Freedom is Eternal Vigilance. -- Wing Commander IV En Það Besta Sem Guð Hefur Skapað, Er Nýr Dagur. (But the best thing God has created, is a New Day.) -- Sigur Ròs - Viðrar vel til loftárása
-
The single most overarching intractable problem in software right now is that people *think* there is a problem and keep trying to solve it in ever more complex and fanciful ways when in fact there are no problems of any kind in the development world. Right now there is a tool available to accomplish anything you put your imagination to. In fact too many tools, too many options, it's too easy and when the going gets easy innovation falls by the wayside.
Overcomplication and generalisation are certainly major problems - PCs (and MACS) are so generalised that they are almost useless for most purposes, sure you can make them do the job but at the expense of time, money and more importantly introducing additional failure prone complication and fault finding nightmares. My job would be a whole lot easier in some ways if I could buy a specialised computer tailored to my needs which I probably can but at a high cost and with little or no support in terms of compatible software and peripherals.
-
I was out planting the borders today. It's a hugely satisfying thing to do, and it lets the mind wander where it will. Recommended. I don't know why, but whilst planting, for some reason top bloke and all round spiffing chap, Grizzly Adams[^] sprang to mind. In a purely innocent way, I might add. Anyway, I got to thinking: here's a chap who must spend an incredible amount of resource (time/money/blood/sweat/tears) trying to solve problems created by software. This immediately turned my mind inside out: software should be a tool which is used to solve other problems, why is it introducing more problems? And that led me to ask: where and why do these problems in software occur? Is it the user base? Are users not adequately expert in the tools? Are the tools too complicated that only a comparative few competently understand and use them? Are there too many tools that are incompatible with each other? (such as OOP and RDBMS) Is a software solution not always right for the given problem, but shoe-horned and botched into it? And some other questions popped up, which I can't now remember. Feel free to add your own. One epiphany that emerged was this: The more we abstract from the actual metal of a machine, the easier we make it to do a specific thing but it seems we make it harder to make two specific-easier-things to talk to each other. This might not be true, but to me it rings true. So what and why are the intractable problems in software?
print "http://www.codeproject.com".toURL().text Ain't that Groovy?
modified on Thursday, March 26, 2009 7:17 PM
Dang, CP was down when I tried replying last night! <blockquote class="FQ"><div class="FQA">martin_hughes wrote:</div>here's a chap who must spend an incredible amount of resource (time/money/blood/sweat/tears) trying to solve problems created by software.</blockquote> Actually, I really don't do much of that in real life. I guess the articles I write are more oriented toward that, because certainly I need decent tools to, yes, overcome software deficiencies. However, the whole reason for those tools is to get something bigger accomplished. Like a cool RMS, or determining failure conditions in switch rings for satellites, or adding 30% to the profit on a nightclub (wink, wink). <blockquote class="FQ"><div class="FQA">martin_hughes wrote:</div>the easier we make it to do a specific thing but it seems we make it harder to make two specific-easier-things to talk to each other.</blockquote> I always have viewed that more as a people problem. :) <blockquote class="FQ"><div class="FQA">martin_hughes wrote:</div>So what and why are the intractable problems in software? </blockquote> #0: VB #1: A complete and total lack of best practices, a disciplined approach to software development (remember the guy in the SB about 5 years ago that said he codes best when stoned?), standards/quality that can be empirically measured, and accountability. Flame away, folks. :) #2: Documentation (as in, lack thereof) Marc
-
Dang, CP was down when I tried replying last night! <blockquote class="FQ"><div class="FQA">martin_hughes wrote:</div>here's a chap who must spend an incredible amount of resource (time/money/blood/sweat/tears) trying to solve problems created by software.</blockquote> Actually, I really don't do much of that in real life. I guess the articles I write are more oriented toward that, because certainly I need decent tools to, yes, overcome software deficiencies. However, the whole reason for those tools is to get something bigger accomplished. Like a cool RMS, or determining failure conditions in switch rings for satellites, or adding 30% to the profit on a nightclub (wink, wink). <blockquote class="FQ"><div class="FQA">martin_hughes wrote:</div>the easier we make it to do a specific thing but it seems we make it harder to make two specific-easier-things to talk to each other.</blockquote> I always have viewed that more as a people problem. :) <blockquote class="FQ"><div class="FQA">martin_hughes wrote:</div>So what and why are the intractable problems in software? </blockquote> #0: VB #1: A complete and total lack of best practices, a disciplined approach to software development (remember the guy in the SB about 5 years ago that said he codes best when stoned?), standards/quality that can be empirically measured, and accountability. Flame away, folks. :) #2: Documentation (as in, lack thereof) Marc
Marc Clifton wrote:
Dang, CP was down when I tried replying last night!
Well you still beat me in coming back to read it - I tend to ask these questions and then go to bed with the intent of reading them in the morning... only I was rather late getting up this morning :)
Marc Clifton wrote:
standards/quality that can be empirically measured, and accountability.
Accountability just doesn't seem to exist in the modern world. If there's blame to be apportioned you suddenly find everyone who was actually involved has developed steeply-sloping shoulders syndrome and taken to wearing Teflon suits.
print "http://www.codeproject.com".toURL().text Ain't that Groovy?
-
Overcomplication and generalisation are certainly major problems - PCs (and MACS) are so generalised that they are almost useless for most purposes, sure you can make them do the job but at the expense of time, money and more importantly introducing additional failure prone complication and fault finding nightmares. My job would be a whole lot easier in some ways if I could buy a specialised computer tailored to my needs which I probably can but at a high cost and with little or no support in terms of compatible software and peripherals.
So you're saying that on my computer desk I should have one machine for development, one for 3d 1st person games, one for strategy games, one for word processing, one for using the internet ... ?
10110011001111101010101000001000001101001010001010100000100000101000001000111100010110001011001011
-
So you're saying that on my computer desk I should have one machine for development, one for 3d 1st person games, one for strategy games, one for word processing, one for using the internet ... ?
10110011001111101010101000001000001101001010001010100000100000101000001000111100010110001011001011
Now that would be silly wouldn't it? :) If you're a farmer you buy a tractor, if you're a plumber you buy a van and if you're a fool you buy a Prius. You could squeeze a sheep or all your tools into the back of a family saloon but you wouldn't buy one for the job would you? Yet we all buy family saloon PCs and make do with the fixes and fiddles to get the job done - for most of us the family saloon PC will alway be a compromise and therefore will cause problems for the programmer trying to make it do specific tasks.