I think the real question is why anyone would want to make an "object oriented" version of COBOL. I have been programming for 30+ years now, and I can't count all the wonderful innovations I have seen come and go. Exactly one of them -- structured programming -- was actually an advance over what went before. I am sure this will ignite a firestorm of rage and recrimination, but as far as I can see, OO is a fancy shmancy name for wasting a whole lot of time dancing around before you design your data structures and subroutine libraries (OOPs, I mean "classes" and "methods"). There is really nothing you can do with Oh-Oh that you can't do with a good assembler. Well, I should qualify that. Nothing useful. Obviously, there is always money to be made selling old wine in new bottles. I have learned and forgotten a Babel of languages, and at this point what I want from a language is for it to Get Out Of The Way and let me work on the problem. Visual Basic comes closest, so naturally they are pulling the plug on it.

Estimating is a whole 'nother matter. If you simply want a list of pieces of code that will need to be written, the pseudocode will provide that, at whatever level of detail you take it to. But there is also the question of design of files or databases, and then there is the question of "testing". The usual development paradigm looks like this; design => code => test => deploy The problem with this is that it assumes the function of testing is to verify satisfactory performance. That shouldn't take long, should it? I could write a book, and maybe I should. But let's cut to the chase. The first question to ask about any document is, "Who is the intended audience?" This applies in spades to a coding time estimate. If you are a contractor, and the reader is a prospective employer, you want the estimate as short as is remotely plausible, so you will get the contract. They won't fire you when it's half done. This may sound cynical, but I assure you it is the standard industry practice. How do you think they make all that money? If you are an employee, and your boss wants an estimate, make him help you develop it. Then he is on the same hook you are. Otherwise, when anything takes longer than YOU estimated, it is YOUR fault. So, yes, your question is a political one, not a technical one. If you build five houses a year, all exactly alike, you have a pretty good idea how long it takes to build one. But no one ever builds the same program twice, and no one has any idea how long it will take to build the next one. JBB

It sounds like you mean "How do you design code", not "How do you design an interface". If the problem is complicated enough that I can't just sit down and write the code, I use pseudocode, preferably on a whiteboard. I use very high level "statements", like do while alive open files get devices play song conquer universe end do get old and die That way, I can deal at a high level with the overall flow of control, then go back and pseudocode the individual steps. But I usually find that the devil is in the details. There are unexpected dependencies, and I have to start over. Of course, this assumes that you are working in a procedural environment. I know people who use an "Object-Oriented" paradigm. They begin by designing the classes they are going to use to solve the problem. I don't know if there is a second step to this methodology. I have never seen anyone finish step 1. JBB

Dude, Which will look better on your resume, an additional language, or a sexual harassment charge? Don't s*** where you eat, don't f*** where you work. JBB

Would you hire someone who didn't bother to proofread their e-mails, but claimed to advocate quality improvement through testing? What would you hire that person to do?

Objects in mirror are generally less important than they appear JBB