What are the intractable problems in software? [modified]

[Roger Wright]

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"

[Member 96]

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.

---

Read a book, here's some good ones[^]

[BillWoodruff]

<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#

[Mustafa Ismail Mustafa]

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!"

[Luca Leonardo Scorcia]

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

[Caslen]

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.

[Marc Clifton]

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

Will work for food. Interacx

[martin_hughes]

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?

[MidwestLimey]

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

[Caslen]

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.