Flame wars never accomplish anything but annoy people. You've read thing things into what I wrote that just aren't there. I never implied your capacity to program is limited. I implied unstructured code, when flowcharted, tends to result in crossed lines. However, it is also true that crappy flowcharting tools will do the same even with perfectly structured code. I didn't write anything to acknowledge that even though that might be the situation for you, because as I wrote you didn't restrict your comments to flowcharting tools, but to flowcharting in general. It is always possible, and trivially so, to hand draw a flowchart of a properly structured function without crossing any lines. You wrote that it is nearly impossible to do so. Your statement is clearly and simply false. I'm sorry if pointing that out hurts your feelings. But it's still not intended as a personal attack, though if you insist on viewing it as such that is your right. I guess by your reasoning anyone could say that whenever any incorrect thing they have written is pointed out as incorrect that it is a personal attack. I don't see it as such; it's not a personal attack unless there's some rude or threatening sort of tone that underlies it. I don't see any point in arguing whether my reply was a personal attack or not. Decide for yourself. It was not intended as such. Accept that or not. It comes down to how you define "personal attack." It's way off issue in any case. I also didn't write that your capacity to flowchart is limited, I wrote that you didn't really understand their proper use. Nothing you've written indicates otherwise. I do not advocate flowcharting if it is just an exercise in going through the motions. Some programmers do find them truly helpful. You are not among them at this time. That's fine. Different people think in different ways. I find a properly drawn graphical representation more clearly and quickly conveys how a complex function works than seeing a text listing does. You have also misread and misunderstood what I wrote about flowcharting tools. I do not find flowcharting, per se, to be difficult. Far from it. I do find the current flowcharting tools of which I am aware to be difficult to use and of very limited utility for that purpose. Most are intended as more general purpose graphics programs than specifically for flowcharting. I know of none that are specifically for structured programming. I am aware of none that is worth using as a development tool. As far as not following

It wasn't my intent to attack you personally, for the sake of attacking you. The fact that I replied to your posting makes it personal to you. I replied to your posting because I disagree with what you wrote. Making a posting in a public forum makes it fair game for criticism, but I have nothing against you personally. The tone of my reply was not rude. I did consider changing the sentence you quoted before posting it, but decided against doing so because your overall posting was broadly general. If you had urged programmers to discourage the use of currently available flowcharting programs, that would have been one thing (and I can't say I'd disagree). But you didn't write that. You urged programmers to discourage the use of flowcharting entirely. That's an attack on how some programmers have found to do their work more effectively. Who are you to tell other programmers how they ought to do their work? Live by the sword, die by the sword. I don't tell you you ought to use flowcharts, so don't tell me I ought not use them. If you don't like looking at other programmers' flowcharts, then don't look at them. Problem solved! But if they find them helpful for whatever reason, then that's fine, too. And both of your postings indicate that you really don't understand the proper use of flowcharts! That's not intended as an attack, it's intended as a relevant observation because relatively uninformed opinions aren't as credible as better informed opinions. -- david_f_knight

Sorry, but this just indicates that you don't know how to use flowcharts properly... and that your coding isn't structured. Properly structured code *never* has any difficulty being drawn without crossing lines (assuming competent drawing). Spaghetti code, not so much. Keeping everything at the same level requires discipline, but then so does writing good, bug-free, code. Trouble keeping a flowchart on one page indicates functions that are too large, that do too much. Divide and conquer. I don't use a flowcharting program because I have never found one that's specifically designed for structured code. It makes a big difference. I started to write one, but decided that the investment of my time was too great and abandoned it. If I thought the market for a good flowcharting program was significant I would have pursued it, but in my experience very few programmers use flowcharts and I thought that was too great a barrier to marketplace success. For me, a flowchart isn't a tool to document what's been coded (past tense), but to help design optimal code first, and additionally to make it easier to understand and debug. Consequently, the flowchart must be easily updatable as the code is debugged or otherwise modified. The various "flowcharting" programs I've seen are for generic drawings. Simply tossing in a few flowcharting shapes is worthless to me. A competent flowcharting program must have an underlying model of a structured program. In other words, you wouldn't use diamonds or rectangles and connecting line primitives, you would use if-then or do-while or switch constructs, for example. Their structure is implicit. Keeping lines from crossing is automatic and trivial. A superior flowcharting program will be able to parse a source code file and produce a flowchart from it. That makes it easy to keep documentation up to date. Unfortunately, I have never found any commercial program that does that. (I wrote one for myself, but that's another story.) A superior flowcharting program will also be able to generate source code from the flowchart. That also makes it easy to keep documentation in sync with program. A really superior flowcharting program will allow debugging a program from the flowchart rather than from the source code... such a program would allow never having to look at source code any more than programmers have to look at the assembly code produced by a compiler or the object code produced by an assembler now. With a flowcharting program like that (it would actually be an in

There's a lot of blame to go around. On the one hand, software piracy is huge - it's estimated that 99% of all the software used in China is pirated. It's probably about the same in the ex-Soviet countries. Even in America, the software piracy rate is estimated to be around, what, 25% or more? (When software is valueless, software writers are valueless.) On another hand, there's the open source movement. When you give stuff away for free you shouldn't be too surprised that it undermines the value of what you do. Why pay for something when you can get it for free? Why hire an employee to write something you can get for free? Open source, etc., undermines professional software development. (For some things, like infrastructure and standards, open source may be good, but for free applications it's ultimately harmful to the profession.) On a third hand, there're the many companies that give software away for free under the concept that they will make up for it on volume or market share. (Did anybody else ever learn that zero times anything is still zero?) On a fourth hand, there's outsourcing. Supply and demand issues, etc. absolutely mean that will undercut salaries and opportunities in developed countries despite all the spinning to the contrary. On a fifth hand, there's bundling and monopolies. When Microsoft bundles some application with Windows, that pretty much kills the market for that application type. I've long since run out of hands to count on, but professional software development is being undercut from every angle. Some of it is extremely difficult to combat, due to widespread corruption of public officials by large corporations. (The US H1-B visa program is a complete fraud, for example.) But some of it is our own fault! Stop giving your services away for free, and maybe you will see the value of your services rise. -- david_f_knight P.S. In response to your question whether the big corps fake this stuff (the IT shortage) to shift the market in their favour and pay us IT types even less, I believe they do that but for several reasons. One is as you suggested. Another is that it helps support the "need" for the H1-B Visa program in the US. Another is that it provides political and public relations cover for outsourcing. Universities do their bit to perpetuate this fraud since it helps them sell their services to their clients, the students. For the truth, follow the money!

By saying that having a PhD might be a big problem if you want to develop accounting applications, I meant it specifically in the context of getting an employer to hire you, not in any more general sense. I'd never argue that having less education is better than having more! But do all employers value it equally? I don't think so. It's a question of optimizing finite resources for maximum personal benefit. There are many ways to evaluate the potential benefit of further education, such as personal satisfaction, career flexibility and opportunity, lifetime earnings, professional capabilities, and cash flow (earning money working sooner vs. increasing debt funding more education). My take on it is this: if you want to be a generalist or don't have a driving interest in any particular specialization, don't get a PhD. But if you want to be an authority on some specific field, be a researcher, or be on the faculty of a university, getting a PhD may well be the best (or only) way to get there.

There are a few considerations. First, what type of work do you want to do? Some things in industry are more suited to having a PhD than others. For example, if you want to work developing state-of-the-art 3D MRI-type advanced medical imaging equipment, having a PhD might be quite beneficial. On the other hand, if you want to work developing accounting applications, having a PhD might be a big problem. Second, where do you want to work? If on a university campus or in a research institute, having a PhD may be quite beneficial, but for other places might be a problem. As a general rule, I suggest looking through the relevant trade publications for your area of specialization and interest. In the back they often have classified help-wanted ads. See what actual employers of the type you'd be interested in are looking for today and in the recent past. Ultimately, employers make their hiring decisions based on the opinions of a few people. Different people have different prejudices, so it's a crap shoot as to who happens to interview you and what their particular prejudices are. Some people are intimidated by people with more education than they have themselves, and some aren't. Some people look down their noses at people with less education than they have themselves, and some don't. No matter what you choose, you won't please everyone. Also, another factor that may work against PhD job applicants is that employers may likely expect that they will have to pay them more money. Unless you are the CEO, they don't like to do that. Having a PhD will likely limit the number of positions you will be seriously considered for, but conversely may be essential for a small number of positions. So, it comes back to this: what do you want to do?

modified on Friday, April 25, 2008 10:42 AM