Slashdot Mirror
Intuitive Bug-less Software?
Starlover writes "In the latest java.sun.com feature at Sun's Java site, Victoria Livschitz takes on some ideas of Jaron Lanier on how to make software less buggy. She makes a couple of interesting points. First, making software more 'intuitive' for developers will reduce bugs. Second, software should more closely simulate the real world, so we should be expanding the pure object-oriented paradigm to allow for a richer set of basic abstractions -- like processes and conditions. The simple division of structures into hierarchies and collections in software too simple for our needs according to Livschitz. She offers a set of ideas explaining how to get 'there' from here. Comments?"
First, making software more 'intuitive' for developers will reduce bugs
Feels right.
I would love to use a C/C++/Java-like language that utilizes pure objects, versus the mish-mashy hybrid typing that exists in most languages that I've used. To me, Livschitz's observation about how programmers work in metaphors, while mathematicians work in pure syntax, is very true: I breeze through all my programming and software engineering classes, but struggle mightily with math courses (save boolean algebra, but I digress).
I, for one, would like software writing to resemble (really resemble) building structures with Legos.
This type of stuff is not a problem for me to worry about anymore. It's India's. Direct me to the nearest auto-mechanic school please. It's time to learn how to fix problems that can put money in my pocket.
It might be me, but I've seen more bugs created because of assumptions made about abstractions, or because someone was used to a pre-made abstraction and didn't learn how things actually worked.
Want to make better software? How about actually scheduling enough QA time to test it? When development time runs over schedule, push the damned ship date back!
She misuses the term functional programming. I'm assuming she meant imperative languages. A lot of the problems could be solved with true functional languages (Haskell, OCaml, etc) but the learning curve is too high. Especially when you can get a team of second rate VB coders for the price of one haskell coder (if you can find one) But really, do you want working code now? Or perfect code in 10 years? That's where the problem is. Time.
I find it enlightening that this article does not include the word "test" once. Rather than spending a lot of time hoping that the purest use of OO technology or some other fancy boondoggle is going to make software better actually writing tests that describe the expected behaviour of the program is a damn fine way to make sure that it actually works.
:-)
Picking just one program from my experience, POPFile: intially we had no test suite, it quickly became apparent that the entire project was unmanageable without one and I stopped all development to write from scratch a test suite for 100% of the code (currently stands around 98% code coverage). It's particularly apparent when you don't have all day to spend fixing bugs because the project is "in your spare time" that it's vital to have fully automatic testing. You simply don't have time to waste fixing bugs (of course if you are being paid for it then you do
If you want to be really extreme then write the tests first and then write the program that stops the tests from breaking.
John.
The first is the intense pressure to get the product to market. This is especially true for custom code, written specifically for one client. They want it fast and cheap and in order to satisfy this desire, code invariably gets released/installed before it's ready. Then the "month of hell" starts as the client starts complaining about bugs, "bugs" and other problems and we bend over backwards to get it right.
As a ISV, we have no choice but to do it this way. If we don't quote the project with this in mind, the client will hire somebody else with a better "can-do attitude".
The second big reason software is buggy is because all the underlying tools (e.g. code bases, code objects, .dlls, etc.) are buggy as hell. I spend more time working around inherent bugs than I do debugging my own code.
Most programmers are perfectly capable of making their own code solid, given enough time.
I've made up my mind and now I've got to lie in it.
To produce bugless software we need to start with software designs that are provably correct and then produce code that is provably in line with the design. Using more objects that more closely model the "real world" is an invitation to producing larger number of bugs as the ambiguity of the real world infects the design and implementation of the program.
Well, the trick to "anticipating everything a person will do that will inadvertantly blow up your application" is to keep it as simple as possible, specifically by restricting how the user interacts with the app. If the user can only press one of 3 buttons or put a fixed number of characters into a text box, it's not impossible to code for every possibility. In theory, you could build a complex application from lots of very simple (and easy to test and write) parts interacting in a well-defined manner.
In practice, this almost never happens. Most developers are willing to trade perfect code that'll take four months for mostly-perfect code that will be ready for the deadline.
To sum it all up, a properly designed and written program should never choke on user input. If it doesn't, that means you cut corners somewhere. Don't blame it on the user.
Karma: Contrapositive
So she wants to make software more intuitive and wants to make it more like the real world.
:-)
Perhaps she should make up her mind.
...it also seemed like she misstated Java's approach as a "sandbag architecture" as opposed to a "sandbox architecture". I keep trying to visualize programmers writing more and more Java code to stave off the inevitable surge of bugs....
Lately democracy seems to be based on the skybox, the Happy Meal box, the X-box, and the idiot box.
"and more closely simulate and resemble the real world". Hey, I know! How about a COmmon Business-Oriented Language? We could call it COBOL perhaps.
"I am Heisenborg. You will probably be assimilated"
Well.. some interesting ideas in there mainly flawed.
.Net ae eliminating may of those issues.
1) The concept that software should 'feel' right to the developer. First of all this cannot be formalized in any sense of the word. Secondly even if it could be it is focused on the wrong target, it should feel right to the end user/problem domain experts. More about this in point 2.
2) Software tools should model the real world. Well.. duh. Any time you build software you are modeling a small part of the real world. THe next question is: what part of the real world. The reason that OOP has not progressed farther is that the real world is so complex that you can only build some generic general purpose tools and then have a programmer use those tools to solve a particular subset. So the programmer must first know what the problem domain is and what the tool set is capable of.
3) Programmers should be average. Absolutely not. In order to model the real world a good programmer must be able to retrain in an entire new problem domain in a few months. This is what is missing in may cases, most people do not have that level of flexibility, motivation or intelligence and it is difficult to measure or train this skill.
4) Programmers shouldn't have to know math. Wrong again. Programming IS math. And with out a basic understanding of math a programmer really does not understand what is going on. This is like saying engineers shouldn't need to know physics.
5) The term 'bug' is used very loosely. There are at least 3 levels of bugs out there:
a) Requirements/conceptual bugs. If the requirements are wrong based on misunderstanding you can write great software that is still crap because it does not solve the correct problem. This can only be solved by being a problem domain expert, or relying heavily on experts (a good programmer is humble and realize that this reliance must exist).
b) Design flaws. Such as using the wrong search, bad interface, poor secuirty models. This is where education and experience come in.
c) Implementation bugs, such as fence post errors and referencing null pointer. THis can be largely automated. Jave, Perl and
In short, a bad simplistic article which will probably cause more harm than good.
putting the 'B' in LGBTQ+
Having watched many people struggle with physics, chemistry, and biology courses, I'm not sure that the real world is all that inituitive. Even in the non-scientific informal world, many people have incorrect intuitive models for how things work. For example, many people think that increasing the setting on the thermostat will make the room warm up faster (vs. warming at a constant rate, but reaching a higher temperature eventually). And my wife still thinks that turning off the TV will disrupt the functioning of the VCR.
Another problem is that the real world is both analog and approximate, while the digital world calls for hard-edged distinctions. In the real world, close-enough is good enough for many physical activities (driving inside the white lines, parking near a destination, cooking food long enough). In contrast, if I am moving or removing files from a file system, I need an algorithm that clearly distinguishes between those in the selection set and those outside it.
I like the idea of intuitive programming, but suspect that computers are grounded in logic and that logic is not an intuitive concept.
Two wrongs don't make a right, but three lefts do.
- I accept that humans are fallible, and as long as software is produced by humans, or by anything humans create to produce software for them, the software will have bugs.
:)
- I accept that there is no magic bullet to programming, no simple, easy way to create bug-free software.
- I will not add unrelated features to programs that do something else. A program should concentrate on one thing and one thing only. If I want a program to do something unrelated, I will write a different program.
- I will design the structure of the program, and freeze its feature set, before I begin coding. Once coding has begun, new features will not be added to the design. Only when the program is finished will I think about adding new features to the next version. Anyone who demands new features be added after coding has begun will be savagely beaten.
- A program is only finished when the time and effort it would take to squash the remaining obscure bugs exceeds the value of adding new features... by a factor of at least two.
- If I find that the design of my program creates significant problems down the line, I will not kludge something into place. I will redesign the program.
- I will document everything thoroughly, including the function and intent of all data structures.
- I will wish for a pony, as that will be about as useful as wishing that people would follow the above rules.
"Destroy science and religion. Science would re-emerge exactly the same; but not religion." - Penn Jillette, paraphrased
I don't care if it's 90,000 hectares. That lake was not my doing.
Dijkstra has a few things to say on the topic as well:
On Education, Specifically:
And then on Computer Science in general:
Thanks,
--
Matt
What bothers me about statements like this, is that no one is suggesting that perhaps our estimation and budgeting methods are off.
What if someone scheduled one week and allocate $100 for design and construction of a skyscraper, and when the engineers failed to deliver, who should be blamed? The engineers?!
...richie - It is a good day to code.
The syntax of all mainstream programming languages is rather esoteric. Mathematicians, who feel comfortable with purely abstract syntax, spend years of intense study mastering certain skills. But unlike mathematicians, programmers are taught to think not in terms of absolute proof, but in terms of working metaphors. To understand how a system works, a programmer doesn't build a system of mathematical equations, but comes up with real-life metaphor correctness which she or he can "feel" as a human being. Programmers are "average" folks; they have to be, since programming is a profession of millions of people, many without college degrees. Esoteric software doesn't scale to millions, not in people, and not in lines of code.
In the article, her solution to error is to increase the tolerance for error, making direct mistakes unlikely or impossible because there is plenty of 'slop' in the system and you can't get a wrong answer. Theoretically, this lowers precision and increases overhead of the system. Her solution to the difficulty in understanding programming is making it so any idiot can understand it.
To make an analogy, a programmer is like a bucket. Her solution to filling a bucket (writing code) is to submerge it inside a larger pool. In that situation, any old bucket will do, the bucket will always be full when placed in a pool; but you will then have to carry the entire pool if you want it to move. The question then becomes how much you can carry, not the performance of the bucket.
She may well be right about intuitive programming, being easier to use, and that making programming more like regular language with intuitive syntax could be beneficial (more like programming a Star Trek AI computer than what we have now). But this would also shift the nature of the problem from design and architecture to performance and underlying stability issues. Any fool could write code without knowing how it worked. Some shortcuts may be appropriate in certain cases, but to rely on these kinds of methodologies in critical situations could lead to disaster and has a built in unreliability factor. If some company thinks they can buy this system and then expect bullet proof security, reliability and high performance, they are probably in for a rude awakening. They should expect 'good enough' performance, which is what they are getting already.
The only way to do exceptionally good work in a complex situation is to have the knowledge and experience for what you are doing at all levels and the ability to execute. Allowing programmers to be ignorant of how a computer works doesn't seem like a solution to me. The real problem with crappy software is companies that don't care and consumers who don't know any better.