Slashdot Mirror
Facts and Fallacies of Software Engineering
The Layout
Facts and Fallacies is not a technically demanding book; it's a very easy and compelling read. There are 55 Facts (and 5+5 fallacies) grouped into logical sections such as Management, Life Cycle, and Quality.
First, each Fact is stated succinctly. (For instance, Fact 1: The most important factor in software work is not the tools or techniques used by the programmers, but rather the quality of the programmers themselves.) Then the point is fleshed out more fully -- in this case, that even with all the periodic hype for some hot new methodology that promises orders of magnitude greater productivity, the quality of your programmers matters far more than anything else (and even the best new methods only offer 5-35% increases).
Next, the level of controversy about this Fact is discussed. For Fact 1, it's that even though everyone pays lip service to the idea of people being more important than processes, we all still act like it's not true. Maybe this new hot methodology can turn all your lousy programmers into great ones! Perhaps it's because people are a harder problem to address than tools, techniques, and process. And, of course, hot new methodologies sell a lot of books.
Finally comes a list of sources and references, which can lead you to more in-depth great reading like Peopleware and Software Runaways. This all works out to about one to two pages per item.
The Facts and FallaciesThe Facts and Fallacies fall into several groups. Some are not well known (or just met with stunned disbelief) such as Fact 31: Error removal is the most time-consuming phase of the life cycle. Some that are pretty well accepted, but are mostly ignored, like Fact 1 above. Some that are accepted, but nobody can agree on what to do about (if anything), like Fact 9 (paraphrased) #150: Project estimates are done at the beginning of the project when you have insufficient understanding of the requirements and scope, which makes it a very bad time to do an estimate for the entire project.
Some Facts Glass acknowledges many people will flat out disagree with (and for a few people, very loudly), like Fact 30: COBOL is a very bad language, but all the others (for business data processing) are so much worse. These are the Facts where he really has an axe to grind, and make for amusing reading. In this case what he's really saying is that there is a use for domain-specific languages intended to do one specific thing and do it well, rather than languages like C and Java which attempt to be "good enough" for any use under the sun. But everyone hates COBOL, including me, so it's controversial.
What's Good?
Again, this is a good (and fast) Read. Even if you don't agree with everything, Glass is a skilled writer with strong opinions and a sense of humor. And you might end up agreeing more than you expected. I was pretty skeptical when I started reading. After all, I'm a long time software engineer with strong opinions too, and how often do you get opinionated geeks to agree on even what soda or text editor to use? But most of the Facts resonated with my experience, and of course for most of them Glass has substantial research reference for. The best Facts are those that you knew but might never have expressed explicitly, like Fact 41: Maintenance typically consumes 40 to 80 percent (average, 60 percent) of software costs. Therefore, it is probably the most important life cycle phase of software.
Or consider Fact 18: There are two 'rules of three' in reuse: (a) it is three times as difficult to build reusable components as single use components, and (b) a reusable component should be tried out in three different applications before it will be sufficiently general to accept into a reuse library. I knew this generally, and you probably did too, but I didn't know the specific reference for "Biggerstaff's Rules of Three," which give you a ballpark figure.
The book was written in 2002, when eXtreme Programming was hot, and it's very interesting that the predictions Glass made in this book about the strengths and weaknesses of XP were, in retrospect, pretty much on target, and this sort of predictive success helps confirm more viscerally that he knows his subject.
What's Bad?
There are a few Facts in here that Glass included just because he feels strongly about them (or even about specific people) and he doesn't really back them up very strongly except with "well golly, this is so obvious." Like Fallacy 5: Programming can and should be egoless. Note that this is a Fallacy, so he opposes it. I happen to agree with him, but his arguments are mostly personal ox-goring even if they're based on his extensive experience. Still, it's an interesting read.
A few of the Fallacies he feels are so obvious that he doesn't even really bother providing sources or references for them, and this somewhat diminishes the overall feel of rigor.
Really, the worst thing about this book is that it doesn't come with a poster of just a bullet-pointed list of facts and fallacies that you can nail to your office wall (or your boss's).
A Few More Facts
Just to whet your appetite:
Fact 21: For every 25% increase in problem complexity, there is a 100% increase in solution complexity.
Fact 37: Rigorous inspections [code reviews] can remove up to 90% of errors before the first test case is run. [But are so mentally and emotionally exhausting that we rarely do them.]
Fallacy 10: You teach people how to program by showing them how to write programs. Why don't we teach them to read programs first? Good question (and he has a few possible answers).
In Conclusion
I wouldn't say this Facts and Fallacies of Software Engineering is quite as powerful as The Mythical Man Month, Peopleware or Death March on their own, but if you program (or manage programmers) and want to be more than just a code pig, this will give you the condensed version of 40 years of research in a very readable package. Even if you don't agree with everything he says, it's well worth considering it.
You can purchase Facts and Fallacies of Software Engineering from bn.com. Slashdot welcomes readers' book reviews. To see your own review here, carefully read the book review guidelines, then visit the submission page.
Dear Veteran: I Salute thee for resisting the pressures of becoming another me-too manager and instead staying in trenches to fight with poor soldiers.
"Doing what i can, with what i have." ~ Burt Gummer
is random claims like 'For every 25% increase in problem complexity, there is a 100% increase in solution complexity.'
Where do they get these figures?
BTW First post!!
"Fact 21: For every 25% increase in problem complexity, there is a 100% increase in solution complexity." How is that a fact? Some data would be nice, and i'll wager 60 Quatloos he doesn't have any.
I resent that. As we all know, the correct term is r as in coder.
An Indian-American Hindu committed to non-violent thought/speech/action alarmed by the global explosion of radical Islam
You could have shortened that to "experienced"; the rest follows naturally from that.
Sheesh, evil *and* a jerk. -- Jade
...this one by Mike Cohn of Mountain Goat Software.
Mike's review is from the "agile software" point of view, so he comments favorably on (among others) Fact 22 - "Eighty percent of software work is intellectual. A fair amount of it is creative. Little of it is clerical".
The Army reading list
I saw the word COBOL and cringed and immediately thought of long hot days in the arid lab. Also, spending enormous amounts of time programming/debugging on what I thought was the worst language ever. Master file update...almost makes me cry what they put us through...and then there was Assembler. I'll be interested to check this book out for the COBOL section alone.
I say we just grow up, be adults and die.
If he was in management, wouldn't he have more influence which he could use to change things for the better? Just because you have a management position doesn't automatically mean that you believe in the PHB management style.
Remember the days when Republicans were the party of fiscal responsibility?
The most important factor in software work is not the tools or techniques used by the programmers, but rather the quality of the programmers themselves.
Another important factor is the amount of time that they are given to accomplish the task. Certain programmers, including many who are otherwise excellent, procrastinate and cannot meet deadlines. And, as we're aware, even good programmers often take shortcuts once fatigue begins to set in.
Do you like German cars?
> can remove up to 90% of errors before the
> first test case is run. [But are so mentally
> and emotionally exhausting that we
> rarely do them.]
I think some of these terms mean different things to different people. When he says "test case", he means (I think) a tester clicking around a UI and adding a new employee or whatever. But "test case" can also mean a unit test, i.e.:The latter meaning of unit test provides a way to do "rigorous inspections" over and over - because a computer is doing the work. Good times.
The Army reading list
COBOL is an old language, not necessarily a bad language. Like anything else, you get out of it what you put into it. If you like programming in COBOL then you'll probably be good at it. If you like programming in Java, then you'll probably be able to code any business data processing functionality you need in it too. I think it's best to use the tool you're most comfortable with.
...the worst system except for all the others.
Hear hear!
This is the big problem with management. Pre-boom managers were PHBs, and thus promote PHBs. New skilled IT people look at PHBs and think, I don't want to be like that, so I won't become a manager.
So its a self-feeding cycle.
WE NEED MORE GEEKS IN MANAGEMENT.
Right now, I should be writing my MBA assignment, worth 25% of the subject, due in at midnight tommorrow, but instead I'm procrastinating on SlashDot. If that doesn't qualify me to be a geek manager, I don't know what does.
Norman Cook's Ode to Sl
If a code review, which takes several hours of my time and the time of my fellow developers, can catch 90% of the errors before the first test case is run, or I can catch 90% of the errors (not necessarily the same ones) using the test cases, it's a better use of resources to let the computer point the errors out to me.
A code review on "90% debugged" software that finds an error strikes me as more useful than a code review that finds several errors in 0% debugged software.
As for fact #1, good process or tools may not be able to make all programmers gods, but bad process or tools can make a mortal out of anyone.
Addendum: Unless you are talking about a Microsoft product where for every 1 % increase in problem complexity, there is a 7 year delay in solution delivery.
Fact 1: The most important factor in software work is not the tools or techniques used by the programmers, but rather the quality of the programmers themselves.
This may be true as far as conventional algorithmic programming is concerned. But the reason that algorithmic programming is wrong-headed has to do with this well-known fact:
Fact 31: Error removal is the most time-consuming phase of the life cycle.
Why is this true? It is because there is something fundamentally wrong with the way we program our computers. It has to do with the old practice of using the algorithm as the basis of software engineering. For an alternative approach to software construction, check out the info at this site: The Silver Bullet
Maybe all the managers are 'me-too' because all you foot soldiers are cowering in the trenches instead of representing.
We had a Book Club at my job, where we reviewed one to four Facts or Fallacies at each meeting, once a week. We collected comments and suggestions about how to change how we worked. It was really interesting, and it was good to engage more people in the discussion, because while I might really care about this stuff and have strong opinions, other people in our organization did not have strong opinions and actually started to think about this stuff as a result of our meetings.
Unfortunately, our suggestions didn't really get anywhere as a Massive Reorganization (TM) of the department took place. *grumble*
We're thinking of doing another Book Club, talking about the "Dynamics of Software Development" by Jim McCarthy.
Education is the silver bullet.
> Fact 41: Maintenance typically consumes
> 40 to 80 percent (average, 60 percent)
> of software costs. Therefore, it is probably
> the most important life cycle phase of software.
Hm. This is a tricky one. Does maintenance take that big a chunk because of the way we write v1.0? Maybe we can improve our initial code to make subsequent changes easier. And build in a safety net of units tests to make those changes less painful.
A lot of maintenance may be a good sign - it may mean that the program is being evolved and improved and is actually useful to someone. Dead programs and cancelled projects don't get maintained, but that's not a point in their favor.
The Army reading list
Fallacy 5: Programming can and should be egoless
I have worked with somebody who turned himself into a great programmer by being egoless. He could solve any problem by the simple expedient of not trying to do it all himself and being very good at accepting ideas from other people. In most circumstances programming is done within a team and ego just gets in the way.
Who wants to work with somebody who rejects an idea just because they didn't think of it!!.
...there's precious little fallacieso in software engineering unless you count daydreaming fantasies.
Let's assume that the book's thesis is true that COBOL is best for administrative programming since it's a specialised language.
Does the book address e.g. Lisp, where programmers have a standard "pattern" to create sub-languages to attack problems?
It sounds like an argument that Lisp should be used instead of COBOL, since Lisp is arguably at least as good as any/most for non-low level programming.
Now I'll probably be flamed by Lisp people... :-)
Karma: Excellent (My Karma? I wish...:-( )
Train engineer here. Bite me.
>EE here. Please stop calling yourself "Engineers", because you're not (B/M/PhD.Sc vs B/M/PhD.Eng), and you doing so degrades my trade.
And having EE folks performing CS tasks degrades mine. Stop it and we'll talk.
If this type of thinking could be eliminated (through examples and actions), lots of people would have happier, healthier work environments and professional relationships:
:)
"And he's on your side, having deliberately passed up a more lucrative career in management for a technical track."
Why they vs. us? Why can't we all just get along?
Simpy
The hard part about getting geeks into management is that they need to be around one place long enough. PHB's get where they are by riding out the clock and becoming the one with the most knowledge. This happens through attrition in many organizations. We geeks aren't often patient enough to ride the pendulum long enough for it to swing the other way.
Our management here has been propogated through golf buddies and drinking buddies. Those with the experience to make good decisions for the organization and proven experience are not considered for promotions. How do you propose a geek go about staging a coup de corp?
It is the presumption on your part that you will or can catch the 90% that is the so what.
It is emperical that people tend to overlook errors in their own work. Hence, the reviewing by others.
I don't think he's talking about compilation errors, so the computer can't always find the (business logic) errors.
I think a book like this is what is wholly necessary. I am not saying this book does a good job of it (I haven't read it). There just needs to be a book that tells people how much of the software engineering information is false and unnecessary. This is so we don't have to either sift through all of it or even worse waste countless hours trying to follow a faulty discipline.
Yea I have an agenda because writing software is hard enough in itself. It is 10 times worse when cluttered with overhead. I remember my very first programming class in high school (it was at a community college) where I was told for a FACT that I should flowchart every function and include a separate box for every line of code. It is ridiculous and they are feeding this stuff into students heads as fact.
Yeah, but it's quite horrifying how many people/shops look at code reviews as unnecessary or too time-consuming. When I'm interviewing at companies, I tend to ask careful questions about process. If they don't include code reviews, I'm out of there.
There may well be people who talk this way who aren't useless losers who think that badmouthing everyone else is an adequate substitute for competence.
But I've sure never worked with one...
And you wouldnt want THAT. It would spoil the cool "old soldier" metaphor...
Some are poorly organized in everything but their code (*ahem*.) A few grew up believing that an employee / employer relationship should be antagonistic; that a manager must rule their team with an iron fist. That may come from looking around at a bunch of us slacker programmers thinking "hey, why aren't they working as hard as I? If I were their manager, I'd be busting their asses 24 by 7." Many are extremely introverted and have trouble speaking up among their peers; they simply would not be capable of dressing down an employee who desperately needs it.
In most of these cases it seems that the programmers have spent their time learning machine management skills. Those skills are completely unhelpful when it comes to working with people. The lessons you learn (for example, "the machine only does exactly what I tell it") don't work with human employees, no matter how hard you try to apply them.
Yes, management is a skill that can be learned, but I don't know any geeks that would want to spend the time, let alone actually manage. Not even for the money. Almost all the people I know who have become successful managers have never been real programmers. They were business analysts or came from completely outside the IT field.
John
And should the people who drive locomotives quit calling themselves engineers as well? Pompous of you to try to corner that title.
Webster's:
1 en-gi-neer n
3 c: a person who carries through an enterprise by skillful or artful contrivance.
So basically, according to Webster's, bite me.
My degrees are a combination of EE and CS courses. You both shut the hell up.
After writing out a couple hundred lines of code, print it out. Then come in the next day and read it. I mean, truly read it, line by line.
Some may argue that this is not as good other programmers reading the code. Undoubtedly true, but you will still catch many errors. The fact that you've waited a day means you are, in a sense, a different programmer than the one that wrote the code. And the fact that it's printed rather than on the screen gives you a different perspective.
I suggest that running tests is not sufficient to ensure a reasonable level of quality. There are certain errors that are unlikely to be caught by testing, and yet are quite obvious in a read through.
In other word, testing is not a replacement for read throughs. In finding problems, a multi-faceted approach is needed.
How do you propose a geek go about staging a coup de corp?
Attain some social skills, go out and play some golf and buy the boss a beer.
Noone wants to work with arrogant anti-social types, management included.
I don't need no instructions to know how to rock!!!!
Since when does a "fact" include a value judgment, like COBOL being a bad language? That's an opinion.
When I was 20, with an electronics Associates degree, we set up a software configuration management program for a shop writing C software that became FDA approved for robotic orthopedic devices.
We based the configuration mgmt program on IEEE standard 828-1990. As part of the program we modeled our Software Requirements Specification process off of IEEE standard 830-1984. Our design practices off of IEEE 1016-1987. Our testing practices off of IEEE 1012-1986.
We demonstrated adherence to these standards of practice in order to gain FDA approval for our robotic device. Our software development cycle flowed as specified in our carefully engineered plans.
We engineered software. But we didn't have engineering degrees. Did we dilute your title?
This message paid for Swift Byte Programmers for Truth.
Fact 21: For every 25% increase in problem complexity, there is a 100% increase in solution complexity.
Fact 37: Rigorous inspections [code reviews] can remove up to 90% of errors before the first test case is run.
Fallacy 10: You teach people how to program by showing them how to write programs. Why don't we teach them to read programs first? Good question (and he has a few possible answers).
FACT: a piece of information presented as having objective reality - in fact : in truth
fact 21 & 37 are not facts. He's just throwing about numbers.
fallacy 10 is a fact. You teach people how to program by showing them how to write programs.
did you forget to take your meds?
Really, the worst thing about this book is that it doesn't come with a poster of just a bullet-pointed list of facts and fallacies that you can nail to your office wall (or your boss's).
Or your boss.
"We returned the General to El Salvador, or maybe Guatemala, it's difficult to tell from 10,000 feet"
It may work for trivial problems, or you may like Visual Basic so plug-ins help you to make code. The visual tools let you skip errors on UI. But the real code, the 'what does it do to make me money' code. That is what you need real good programmers for.
If the manager imposes an impossible deadline to the programmer, hes just a bad boss, PHB style. Of course, there are always real world time constraints to be met, but in this case the manager should define a possible goal along with the programmer, alternative solutions, scope agreements, etc.
On the other hand, if the programmer is incapable of defining a deadline himself to a well defined amount of work, than you just cant blame the manager.
This is Blatant Self Promotion (you have been warned).
Here's a good list of software resources, mostly books that I've collected over the last five years or so. Lots of stuff about agile, stuff for managers as well as developers.
Helping with organizational effectiveness is our job.
WHAT US WHO TAKE ENG. CORE?
I don't know about the rest of you, but my EECS department went so far as to develop a written policy stating that reading other students' code was cheating.
I saw an opening for an Engineer to work in the boiler room at a local hospital. Let me know if you're interested.
As opposed to Japan, Italy, Korea, Germany, etc?
Fallacy 10: You teach people how to program by showing them how to write programs. Why don't we teach them to read programs first? Good question (and he has a few possible answers).
This is exactly what John Lions was trying to do with his commentary. And he used nothing less than the Unix kernel source code as an example of well-crafted, and very readable, code.
Rest in peace, John. Your little project helped more hackers than you could ever have known in this life.
Make that "outclasses my trade".
I know a recent EE graduate. At the beginning of every university course, someone in the class would timoroulsy raise a hand and ask the professor "Will there be any programming in this course?".
A huge collective sigh of relief would greet a "No". Couldn't hack it.
Slashdot entertains. Windows pays the mortgage.
A bug that took a programmer 8 hours to find in a code revision can be a waste of development time, but think of the time it takes to fix this bug in production software:
the user will try a workaround before calling support:4 hours.
first level support will try to reproduce the bug: 2 hours.
a programmer will find the buggy code and fix it, once he has a bugged scenario:4 hours.
a tester will generate a new software release to fix the bug and run all the tests to make sure nothing else is broken: lots of hours. (a "priceless" joke, anyone?)
The thing that every seems to forget about the code inspection school of thought is that it was developed at a time when running tests and debugging actually did cost real money back in the 1970's when Fagan came up with his inspection process. Your department was charged everytime you compiled and ran your program on the mainframe computer because the mainframe was expensive to buy/rent, power and maintain.
Now it doesn't cost real money but has an implied cost that bugs found later in the development process cost more money to fix than if you found then in the coding phase at a code review. Never mind the fact that the recommended rates of code inspects in lines of code per hour are near glacial and costs more money now to have 4 highly paid people to sit in a room and read code out loud. One project I worked on was all brand new code and would have taken three full months of code reviews to review every single piece of code at the speed the QA people were insisting was required for a proper code inspection.
The process also insisted that we code inspect before we began any testing. So instead of running a suite of tests that could test 90% of the code in a matter of minutes, the QA insisted that we go through a code inspection before test just because the QA people's definitive texts on software quality still use the same data that Fagan used from his research back in the 1970s. They can quote the facts but they don't understand what assumptions were in the original research.
Code inspections do have their place. I would say those places are to enforce coding standards and knowledge transfer which both help with maintainability in the long term. In reality however, most of the code I inspect today has been pounded on for a month or so before we review it. I can't remember the last time I actually found an error through inspection that would have resulted in a bug report. Most of the stuff we find are missing documentation and typos in that documentation. *yawn*
I am also an EE.
;)
Some jurisdictions do allow Software Engineering. APEG-BC (The Association of Professional Engineers and Geoscientists of British Columbia) lets Software Engineers register. UVic (University of Victoria) grants a four-year B.Eng in Software Engineering. Other universities in BC offer the same degree. I didn't go to these other places, so I don't have any details on them.
Other places in Canada offer B.Eng degrees in Software. I'm sure that there are accredited institutions in other countries that provide Software Engineering degrees. (B.Eng, not B.Sc)
Now, those NSE and MSCE guys are a different story.
---
ECHELON is a government program to find words like bomb, jihad, plutonium, assassinate, and anarchy.
In /. style, I'll comment on your broad statement and point out the exception...
:-)
It used to be in Texas that an EE couldn't use the word 'engineer' in their title either. However, that was recently changed.
There are actually legitimate Software Engineer's seen in the wild. The NCEES's EE exam has been updated with software/hardware/networking questions. And there are in fact Professional Engineers with specialties in Software Engineering. I would guess they just might put "Software Engineer" on their business card... and have the legitimate right to do so.
I'm sure licensed architects get annoyed with software people as well. And I know Doctors that get really worked up over Chiropractors calling themselves doctors... and think of all the churches that are ticked off at Judas Priest.
Surely there are better things to get worked up over.
Two reasons (there are more, but these are the best ones that come to mind immediately):
(1) The next time you park yourself on a commercial airliner you can be thankful that the software controlling the engines, the autopilot and the cabin pressure controls, to name just a few subsystems, was reviewed exhaustively at every step in the life cycle. They do this for a reason: It finds errors that testing alone cannot detect. [DO-178B, Section 6, available here]
(2) If fixing an error during implemention costs, say, 1 unit of resources (the baseline), then fixing that same error during requirements generation will only cost 0.2, and fixing it after deployment will cost upwards of 20 times the baseline. [from Software Requirements, by Alan M. Davis]
People who don't do reviews during the requirements, design and implementation phases are destined to spend their time poking their buggers and trying to explain to annoyed customers why the software doesn't work. Putting the effort up-front into good requirements design and code reviews makes the final testing and verification so much easier.
As for myself, I detest debugging at the tail-end of the life cycle; I'd much rather be moving on to the next fun project. Wouldn't you?
There is no substitute for code reviews as a cost-effective and timely way to detect and correct errors. Period.
My take on it is that those programmers who don't want to do code reviews and don't want others looking at their code must have something to hide.
And so many SE books seem like lists and lists of lists and lists. Or "here are the 328 things you must do to write a line of code". They instil guilt rather than instilling ability.
LOL, there's nothing wrong with seeking money, glory, or becoming a manager.
John Kerry is a Joke!
Except most programmers I know that are worth their weight in salt would completely and totally suck to have as managers.
Yep. My experience of fellow computer programmers is the same. They would not make good managers. And, more importantly, they would not ENJOY being managers. They are perfectly content to be managees.
However, the few programmers who are both capable and motivated to be in management really should aspire to do so, IMAO. They are exactly the sort of management that the industry needs, will likely encounter great success, and could serve as beneficial trend setters.
$1.00/50
> He could solve any problem by the simple expedient
> of not trying to do it all himself and being very
> good at accepting ideas from other people.
I have met quite a few such people and I know that they are not great programmers. They are not even good programmers. They are simply very good at getting the rest of the team to do all the real work. Every team has them and they are a drag; they contribute nothing, but because everyone covers for them they still manage too look good if the team is able to solve the problem.
> In most circumstances programming is done within
> a team and ego just gets in the way.
ego, n.: the self; the individual as aware of himself. That's Webster's definition. Are you saying that it is bad to be aware of yourself? If you do not have an ego, it is likely because you have done nothing to distinguish yourself as an individual. You could have managed that by having no original thoughs and just "accepting ideas from other people". As I already stated, nobody likes a free rider.
I don't know what you call "ego" then; to me it means having pride in your code and refusing to accept garbage from other team members. I have pride in my code because it is good; my progamming team benefits from it and I would most certainly reject some ideas if I do not think they are good enough for the code base.
> Who wants to work with somebody who rejects an
> idea just because they didn't think of it!!.
Nobody, but what does that have to do with anything? Don't lump all cranky primadonnas with the concept of ego. There is a difference between having an ego and being self-centered. In fact it is likely those who never have an idea of their own, that are more likely to reject good ideas by others just because they can. Little people feel better by bringing others down to their level.
As an example, one of the laws mentioned in this discussion is given as "Individual developer performance varies considerably." (Law 31) Then some statistics are given showing the variability. Finally there is a comment on if we should or should not trust the numbers given.
New skilled IT people look at PHBs and think, I don't want to be like that, so I won't become a manager.
Too right. I've been to interviews for several companies where they claimed to be "looking for senior system engineers", when in fact they were "looking for senior system engineers wanting to move into full-time management". When I found out their management structure for the project consisted of lead programmer, team leader, project manager, systems architect and technical director (but no admin), and that the project manager was expected to spend Friday afternoons playing golf, I practically fled the building. The last I heard, the company had seriously downsized their management.
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
i will give you the shortest possible summary of the difference between code reviews and test cases: code reviews are done by humans, test cases by computers.
who's smarter?
test cases are a great way to ensure that your code continues to do what it's intended to do. code reviews can catch design errors [though the ego factor is problematic here], can lead to new ideas, can dramatically simplify algorithms, etc.
ITS GOOD WHEN THE PROGRAMMERS TALK ABOUT THE CODE EVERY ONE IN A WHILE!
a free side benefit of reviews is that you have two people who know the code. invaluable in case one of your programmers gets hit by a bus.
A value judgement is not just an opinion! These days it is a popular attitude to "keep your values to yourself" and to consider one man's values as good as any those of any other. It is easy to understand the motivation for this, since without objective standards it is impossible to criticise anyone or anything. You can read an interesting conversation on this subject in Neal Stephenson's "The Diamond Age", between John Hackworth and Lord Finkle McGraw. Because we have no allowable objective standards on judging languages (among other things), it is not possible to prove a language to be bad. All judgements become opinions and, as such, irrelevant. Naturally, with no way of distinguishing a good language from a bad one, except for that nebulous "gut feeling", the world gets exactly what it deserves: hundreds of bad languages with groups of fanatical adherents flaming each other on Slashdot about the (purely relative and irrelevant) merits of their languages. So it is with other things in this world. You can do nothing good unless you define what good is, but you can do nothing bad either, so I guess most people are satisfied. There is nothing I can do about it.
Does anyone esle find it incredible that this reviewer complains that the cranky old coot author doesn't bother to provide justifications where he really doesn't have anything compelling to add?
Knowing when to shut up is one of best indicators that someone cares enough about their subject matter that they don't feel the need to "fill air" as if other people can't supply their own experience.
I heartily condone the approach: here's what I think, take it or leave it.
I'm an old coot myself, and I've learned that it's generally a waste of time to write toward an audience that won't think for itself. If you boss won't think, a poster of convenient sound bites won't solve any problem that matters.
If printing it out is not an option, displaying it in a different font, in a different size, ideally with differnt line breaks (hard for code, possible for other things) is almost as good.
The aim of printing or reformating is to change the text, and force you to actually read the letters that are on the page. This is done by destroying the patterns in the positioning of the text that the writer is used to, thereby hindering recall.
This is one of the reasons LaTeX is useful (for me, at any rate), because it does all of the above, without actually printing it (written in 10 pt monospaced Courier, read is 12pt Times New Roman, 1.5 spaced, paginated). Most literate programming schemes also have this as a side effect, notably Web derived scheme which output LaTeX. I've always wondered how much that contributes to the sucess of those methods.
Project estimates are done at the beginning of the project when you have insufficient understanding of the requirements and scope, which makes it a very bad time to do an estimate for the entire project.
This is what separates the men from the boys. Estimation of project requirements are not perfect until the project is complete, so you have no choice but to work with educated guesses.
Modern project management is an exercise in managing uncertainty.
It is easy to say how long it would take you to write a script, anyone can do that in their head: guess base on experience, multiply by x2 and have a reasonable estimate.
Now try estimating a thousands scripts (or circuits) done by hundreds of engineers of varying aptitudes that will result in a capital cost of several billion dollars over (hopefully) a few years! All of which is directly reflected in your retirement investments!
That kind of planning is real nuts-and-guts stuff that most of us well never have to wrestle with, and a "fact" like this grossly understates and misrepresents.
Programming is easy.
Planning is orders of magnitude harder by comparison.
I prefer programming, the latter makes my brainpan throb.
https://www.accountkiller.com/removal-requested
Fact 1: The most important factor in software work is not the tools or techniques used by the programmers, but rather the quality of the programmers themselves.)
I don't necessarily agree with this statement. It's truthfulness is ultimately circumstantial. In theory, it's a fact, but in practice it's a lot more complicated.
Yes, the quality of the programmer is most important, but for the very reason that a seasoned programmer will select the best software and tools, which is equally as important. So the question is basically circular in nature.
Second, the goal of software engineering is to produce a viable product. The best programmer in the world may still be subject to the whims of management which may override his choice of approach or tools.
Fact 41: Maintenance typically consumes 40 to 80 percent (average, 60 percent) of software costs. Therefore, it is probably the most important life cycle phase of software.
I think this is once again, circumstantial. If you're running a Microsoft shop, it's a fact. If you're running a Unix shop, the maintainenace costs can be negligible depending upon the quality of the program design.
"At university I and a friend invented the IRS."
and
"All these came from the sound research of the IRS (Institute for Random Statistics)."
You're so lucky you said that. Me and my buddies were going to bust your chops bad.
Actually, the idea of the Slashdot general public in management positions is a thought too frightening for words.
WE NEED MORE GEEKS IN MANAGEMENT.
With the outsourcing of IT jobs, there would be no problem with the availability of IT personnel for management positions.
NOW GET BACK TO WRITING YOUR MBA!!!
How do you propose a geek go about staging a coup de corp?
By telling them the about how to get the best porn online during a binge drinking session. He'll be a hero.
Yeah, but then you cease being a geek, and you start living a double life, where tassels and the wool content of your suit pants become important factors.
One day you'll be driving by fry's and realize you've not been there in over three months, and you will feel very small indeed.
Geeks are good at what they do when they embrace their geekness. When they try to suppress it, they become miserable, depressed creatures. And i would not want that in managament.
I say: stay behind the keyboard, and long live sandals!
"Piter, too, is dead."
This book is currently ranked 988th on Amazon.com and 670th on bn.com!
Actually this would mean a polynomial increase, not an exponential one.
" Almost all the people I know who have become successful managers have never been real programmers"...well,meet one more. I have been a coder for many years in embedded systems work, and also in the web area. And I have (and do) manage teams of programmers and analysts. The reason most geeks don't want to manage is simple..It is HARDER than coding. No debuggers, no error messages, no recomplies, it has to be right the first time. And Senior Management expects it!! Plus the skills are mostly people skills, something IMNSHO a lot of "geeks" have trouble with. People solutions are generally not right/wrong they are somewhere in the middle, they are kinda "fuzzy" which bothers the logical programmers mind. But those "soft" management skills CAN be learned if you try. In my 22 yrs in IT I've been up the Management chain to mid-level and back down and over to Sr. Technical Staff. I prefer the Technical work, but it is getting HARD to find, so I have my PM skills to fall back on. Versatility in roles, as well as in programming skills is valuable! Oh,and don't get me started on my soapbox about how Leadership is MUCH more valuable than management, but it is in every scarcer supply in the tech world. Set reasonable expectations but hold them to it, give people room to work, help them with problems, keep the customer informed and off the programmers backs and you'll do OK in Managment.
Personally, I think a relationship between a manager and a programmer should be one of trust. When both are committed to the the job, you cant go wrong. When thats not the case, I would say that one should rely on his own feeling and experience to tell the difference.
then again, thats probably just the answer youd get from a consultant... a statement with no useful information at all. creepy.
I like to think that, a skilled engineer could learn to be a skilled manager in under 12 months, but a skilled manager, could only become a skilled engineer in 12 years :) So who gets paid more?
99% of programmers I know are actually "out there" very social or good at the pub guys. Maybe its just the australian culture.
But what is a good manager? one that ignores human skills/people totally and just gives orders like a drill sargent? Gets things done I guess.
What I really hate though are lieing MF's managers that pretend to their programmers "oh yeah project going ahead well, all rosy for next release", when in the background he has spoken to head of R&D and knows your project baby thats 5 years old is gona get canned because of incompetent marketing which isnt yielding massive sales, and that some staff will get the ass too.
I do have to wonder if women with children would make a better manager?
Liberty freedom are no1, not dicks in suits.
Extreme Programming advocates code reviews as a good practice. In fact, code reviews are part of the point behind Pair Programming. If code reviews are good, let's review all the time.
Fallacy 10: You teach people how to program by showing them how to write programs. Why don't we teach them to read programs first?
For the same reason we don't teach people how to write books by telling them to go read: If they're serious about writing, they're *already* avid readers. Teaching them to read would be redundant.
If a wannabe programmer isn't already reading code for ideas then he's wasting your time asking how to be a programmer.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
When I was looking around for universities (beginning of the 90s), York University (UK, not Toronto suburbs) offered a choice of a BEng or BSc in Comp Sci. I don't think you had to make a choice about which you wanted until the very end.
I have a Software Engineering degree, 4.0 GPA, and it is a worthless rag.
FACT: The fact of Software Engineering is that it is a horrible, worthless career due to:
- INsourcing mass foreigners, H1B visas, just HORRIBLE!
- OUTsourcing tech jobs, TERRIBLE!
1) GOTO Massive Foreigners2) CLICK ON Advanced Search button
3) SELECT your State and Company
4) CRY when you see the massive number of foreigners who have replaced your job!
Remember, you can NOT compete with mass foreigners & H1B visas. Why? Because you both follow a different set of laws. Foreigners have enormous legal advantage over you. Sucks huh! There is NO legitimate career future in Software Engineering or Computer Science.
The corporate outlaws have won the battle. *sigh*
Score & Karma: SASA: Slashdot Approval Seekers Anonymous
Ditto!!! See my post in this same thread. Capers Jones at Southern Cal did the exponential cost model you are quoting.
No, what he's saying has nothing to do with MS vs. Unix. He's saying that the effort/time/money required to create the code in the first place is less than the effort required to keep it running:
- for the next decade or three
- on hardware that wasn't even on the drawing boards when the program was written
- for uses that, while within the program's theoretical capability, were never comprehended by the original creators.
Ever maintain a code base for a decade? It's painful - more painful than writing new code. That's his point.
Technically, computer science and computer engineering are (or should be) distinct, in the same way that chemistry and chemical engineering are distinct. Most people I know with CS degrees fall somewhere in between the two. Some universities seem to focus more on the science end (in many cases the CS dept grew out of the math dept, CS -- as opposed to computer engineering -- is basically mathematics); some focus more on engineering.
I don't see why you would consider your trade degraded because some people calling themselves computer engineers are more computer scientists. I didn't find EE inherently more (or less!) challenging than CS, it just used different abilities.
It's been my experience that it helps to have both computer scientists and computer engineers on any project that's sufficiently complex to be interesting, because they tend to have complementary knowledge and abilities.
Which is what we used to call pretty-printers when they did more than just wrap everything in font tags.
My favorite was lgrind, which produced TeX/LaTeX versions of your source. It could be taught about variable naming patterns, so if your code does something like "delta_vn = blah", it would emit "\delta_{vn} = blah". When printed, this becomes an actual Greek delta character, with the "vn" as a subscript. (Just one example.)
Checking the formula in the code against the formula in the math reference is a lot easier when the formula in the code looks like the math. :-)
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
Bah. The parent may be a troll, but please don't add insult to injury. The engineering classes I took weren't easier than the CS classes; they're entirely different disciplines. I know several programmers who sucked at EE, too.
In a hundred years we will have software that does what a manager does today. But man will always need geeks. Yes, what is complex today is simple tomarrow. But tomarrow there will new complex problems to solve!
"Learning is not compulsory... neither is survival."
--Dr.W.Edwards Deming
No one else would touch it 'cause it was tainted by Rational Rose and UML? ;-)
GENERAL PUBLIC SIGNATURE (GPS) Any replies (derivatives) of this post must also use the GPS
This is exactly what John Lions was trying to do with his commentary. And he used nothing less than the Unix kernel source code
Many instructors with a knowledge of copyright law at least used to advise students to avoid these books. Problem is that these sorts of books tend to pollute readers with "access" (in the copyright sense) to copyrighted source code, such that if a programmer ever writes substantially similar source code, he could get sued.
"The reason most geeks don't want to manage is simple..It is HARDER than coding."
Management is not harder than coding per se. It is just harder for geeks whose talents and interests are more suited for coding. Most managers don't want to code, because for them it is HARDER than managing.
---------
There is inferior bacteria on the interior of your posterior.
Code inspections may be useful for knowledge transfer, but they're a relatively expensive way of achieving that goal. Code should be written primarily to "speak" to someone who has to maintain the code later, not just for the control of the machine. A full-blown code inspection just so Coder B can take ownership from Coder A is overkill.
I mean, after all, 80% of all statistics are made up on the spot...
Everything I need to know about copyrights I learned from Slashdot.
However, the few programmers who are both capable and motivated to be in management really should aspire to do so, IMAO
In my ass off?
If you were a coder in the "web area", how about some markup to make your message readable? Maybe a/> or a <p>?
:)
Sigh...managers
Management concepts are very easy to understand... a semester equivalent's worth of reading will more than do. But they're really hard for most people to impliment.
Particularly so for the sorts of people that generally end up in CS programs and/or selftought hackers, it seems. But that's completely ancedotal based on people I know.
Getting results from a "Apply people to problem" problem is very different than getting results from "Apply myself to this problem". And knowing what problems to attack, from the "this business has to succeed" sense, is even harder.
> If he was in management, wouldn't he have more
> influence which he could use to change things for
> the better?
Not necessarily. I was a team lead. My boss asked for an estimate. I got the estimate from the developer, seemed accurate. Got the "no way, do the same in half the time."
So we went ahead and started the project. I think it finished up almost to the day originally specified by the developer.
Being in management doesn't mean you can make a difference unless you have the power to change things, which at some companies means you have to be a VP or CTO.
- Manages records as a base data type well - Makes it simple to write readable code - Has nice control structures for large data sets It sucks at a lot of things (don't write a UI in it, for example!) but there isn't much better at traversing a database.
I think a distinction between management and leadership is worthwhile considering. I agree the programmer-manager duality is tough and there are few who can handle it. The programmer-leader can be tenable- the question then becomes whether the "ex"-programmer can recognize this and (as needed) bring in the 'management' as appropriate/needed. Caveat: I am now, after many bounces between "mgmt" and "technical" position, in a high-level management position, and therefore by I expect these comments to be modded-down. Sigh. However, there are many who would swear to my continuing geek-status. yes, I still code. As often as possible. Just don't tell my boss.
Programmers..worried about format not content! :) Or maybe that's UI Designers who Programmers and Managers BOTH hate!
The dilbert principal in action... people who are too incompetent to do actual work become managers. =)
Not funny. I beleive that would be "In My Arrogant Opinion".
woot.
"Somebody has to do something. It's just incredibly pathetic it has to be us."
--- Jerry Garcia
I suspect that the mere act of doing a MBA will turn you into a PHB, despite your best efforts.
What a long, strange trip it's been.
There are a few schools which offer degrees in "Software Engineering". I happen to be a student at one of them (Rose-Hulman Institute of Technology), though I'm an EE and Computer Engineering (both out of the EE department), not CS or SE.
The SE tracks tend to focus more on project development. Things like adhering to specifications and such. Basically, some of the same stuff that gets taught in EE engineering classes. Of course, they take some of the CS classes.
"Fundamental" computer science is more math than engineering, though most schools (appropriately) teach a bit of both. Rose does this, though recently they have begun to separate more since the introduction of the software engineering degree.
And yes, you can be a licensed professional engineer in software engineering. Donald Bagert, a professor of mine last year, was the first to bear that title in the US.
*cough* sure *cough*
"Hey, twiddlingbits, when you're through blowing that new forth system onto that prom, could you come look at this Cold Fusion template? It doesn't seem to connect to the database right..."
All's true that is mistrusted
Prof made a rough statement, student called him out on it, prof. pointed out that there's no universal and objective way to measure "complexity" and that if you're worrying about the actual numbers he used you're missing the entire point of his statement.
All's true that is mistrusted
How does one validate the different specifications: requirements, functional, design, etc... against the code? If you write test cases using the specs as input to validate the code, then you still need to validate the test case code against the specs...
As you undoubtedly know, managing is all the drudge work. For those who don't think about it much, a manager has to schedule vacations, write reviews, hand out status reports to jittery managers of other projects, demand status reports of recalcitrant coders, praise the good guys and spank the bad ones who spend their mornings on Slashdot. They make up the on-call lists and have to listen to 50% of the people whine that they were on call last Christmas, so why did they get this Labor Day? Then, they have to memorize the handbooks that list the official columns of carrots and sticks. Somewhere in there they have to learn the technical lingo their employees toss around trying to explain their latest problems, they have to send flowers to the guy whose dad just died, and meet with half a dozen salesmen who promise to double staff productivity and end global warming if they'd just place their order. They have to keep their sense of humor, put up with crap from the arrogant technical staff, calm the neurotic director, and attend daily project meetings.
Oh, and they have to buy their senior technical staff new PCs. I mean really. 1500MHz is a crap box these days for compiles of that many lines of code. Dual Xeons at the desktops would improve productivity by a lot, position your staff for the 64-bit OS to come, and don't skimp on the RAM, SATA RAID, or the graphics cards. Besides, those junky old PCs are depreciated already, just give them to the guys in accounting, they don't need anything more than that.
Managing means keeping two dozen balls in the air simultaneously. It's not a glamour job. It's a sucky job. If you think your manager is overpaid, just think about that list above, realize that's only the visible portion of what your manager has to do, and then be really really glad it's not you.
[ I can hear Aldous Huxley's Brave New Words echoing in my ears: "I'm glad I'm a Beta. Alphas have too many responsibilities..." ]
John
RICHARDSON , Texas (Aug. 26, 2004) - The National Science Foundation (NSF) has awarded the Erik Jonsson School of Engineering and Computer Science at The University of Texas at Dallas (UTD) $385,000 to provide scholarships for talented, financially needy students studying software engineering (SE) and computer science (CS) to help alleviate a national shortage of high-tech workers.
The grant, which is effective Sept. 1 and expires four years later, will fund 28 scholarships, with matching funding by the Jonsson School providing another seven - for a total of 35 scholarships.
"The demand for highly trained software engineers and computer scientists far exceeds the supply," said Dr. Kang Zhang, associate professor in the Jonsson School's Department of Computer Science and primary investigator of the NSF-funded project. "The goal of the program is to recruit talented and financially needy students into our SE programs and produce highly skilled professionals who can join the industrial workforce or proceed to higher degrees in the field."
Software engineers are responsible for designing and programming large-scale computer systems and applications.
According to Dr. Bob Helms, dean of the Jonsson School, UTD is "highly qualified to help fill the nation's critical need for high-technology workers vital to the national economy." The school has long offered an M.S. degree in SE. Three years ago, it instituted one of the nation's first B.S. degrees in the field, and it recently started an SE doctoral degree program.
In addition, Helms said, more than a quarter of the university's computer science faculty specializes in SE and related areas.
Zhang said that he and his UTD colleagues will engage in joint recruitment efforts with community college districts in both Dallas County and Collin County to identify potential scholarship applicants, including those from under-represented groups - an effort he termed "a cornerstone" of the project.
UTD will begin awarding the scholarships, primarily to undergraduate students, in the spring of 2005. Students who qualify will receive up to $3,125 a year and may renew the scholarship each year for up to four years, based on academic performance.
UTD's Computer Science Department will implement a rigorous process to select and retain SE scholarship students, according to Dr. Gopal Gupta, a co-principle investigator on the project. It will include a full range of supporting services, assessment and evaluation procedures and opportunities for industrial internships.
"We believe that these new scholarships will help promote and strengthen UTD's SE and CS programs, making them a model to be emulated nationally," Gupta said.
Assisting Zhang and Gupta on the NSF project are a number of their colleagues from the Jonsson School - Dr. D. T. Huynh, Dr. Simeon Ntafos and Dr. Sook Kim, among others.
About UTD
The University of Texas at Dallas, located at the convergence of Richardson, Plano and Dallas in the heart of the complex of major multinational technology corporations known as the Telecom Corridor®, enrolls about 14,000 students. The school's freshman class traditionally stands at the forefront of Texas state universities in terms of average SAT scores. The university offers a broad assortment of bachelor's, master's and doctoral degree programs. For additional information about UTD, please visit the university's web site at www.utdallas.edu.
87% of statistics simply made up on the spot.
[Vic Reeves].
Mozilla developers can confirm! They spend 100% their time removing bugs!
Example bugs (some resolved fixed):
- Bounce command not implemented in MailNews
- Progress bar should be displayed only when loading stuff
- Download Manager unimplemented
- Mozilla should include IRC client
- "Sort bookmarks" missing
- Add interface to unblock secure ports
- Coffee machine on 2nd floor broken (old one, from Netscape times yet...)
- Developer conference should be organised...
Anagram("United States of America") == "Dine out, taste a Mac, fries"
COBOL ought to be perfect for web apps and ought to have a bright future because it has fixed-point math and fixed-length strings, the first is a necessity (as described above) and the second is extremely efficient. But I don't believe the COBOL vendors have been aggressive about this market.
Ewww, what a revolting image. "Berkies" should be buried with their late owners.
Managing means keeping two dozen balls in the air simultaneously. It's not a glamour job. It's a sucky job. If you think your manager is overpaid, just think about that list above, realize that's only the visible portion of what your manager has to do, and then be really really glad it's not you.
I'm a manager of a large department. I didn't ask to be promoted -- it was thrust upon me. Managing is 30% more work for 10% more pay. I stick with it mostly because it looks good on a resume. The most frustrating thing is being judged based on the performance of others.
-a
It demonstrates that you lack the qualities to become any kind of manager. If you can't manage your own time well, you certainly shouldn't be allowed to manage other people's.
You forgot managing budgets, budget requests and making capital expenditure requests, making business justifications for buying Oracle instead of MySQL for the corporate F&A database, etc.
And how do you document complex interactions in complex projects needing tens or even hundreds of programmers?
Post-it notes and badly written pseudo-code?
Software is complex (testament to it is how we accept with buggy sofware that is normally just good enough to fullfil its purpose) and any pretense on the contrary is wholly clueless and uninformed.
IANAL but write like a drunk one.
If you had the bad luck to have been thought by lazy sociopaths you have our deepest simpathy but not necessarliy our support in your derogatory blanket generalizations.
Many of the advances in computer sciences that have made life easier for many people in the IT industries come from people in the academic field.
Obviously you don't understand the demands of a teaching position. You have to prepare tha class, grade the students, keep up to date in the cutting edge and then deal with complete idiots that believe they know it all because have a bit of working experience when in reality lack the most fundamental foundations in computing.
But of course since you seem to be such a brilliant star in the IT firmament, surely have a better solution to the time tested teaching system followed in most places around the world which will free the brightest minds in our classrooms from the tyranny of the teachers.
Why should the young listen respectfully, why age, experience and insight should be held on any respect whatsoever if the youngs minds will lead ud to an era of prosperity, abundancy and progress. Like they did during the dot com era for example.
IANAL but write like a drunk one.
If you have trouble coming up with justifications for spending company money, then you might want to review your decision - it just might be wrong.
Or, in this specific case, you could just sidestep the whole problem and get PostgreSQL instead.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
Fact 1: The most important factor in software work is not the tools or techniques used by the programmers, but rather the quality of the programmers themselves.
A really good programmer knows which of his tools and techniques are appropriate for the problem at hand. A few simple examples:
-Spaghetti code has its place in small experiments. The sort you hack up in a few hours and might throw away afterwards.
-Object-oriented programming will help you to keep large projects organized.
-Scripts are fine for small tasks, but don't expect them to have great performance.
Of course, there may be the problem that your pointy-haired boss insists on $LatestHypeTechnique. But otherwise, competent people will choose the right tools on their own.
C - the footgun of programming languages
"under-represented groups - an effort he termed "a cornerstone" of the project." I was denied equal access to higher education while the Fascist police state continues to help the so-called under-represented. Your racism, sexism, and other discrimination will only come back on your heads. The economy is getting worse and worse, and you want to continue playing fascism, socialism, communism, racism, sexism, class warfare, and other social engineering cards to get what you want. Screw you. You social engineering scum bag. I worked for my education, and now it has no value in the U.S. just like the original poster said. Bush has sown the seeds of revolution.
I am not strictly a geek, but in my field of knowledge (money management) the same problem exists; and I have my reservations about the ability of geeks to occupy PHB's places.
1. first off, motivations define the people; the very act of becoming a geek, or more appropriately a person that defines himself by the quality of his professional work, is the willingness and the ability to be rigorous AGAINST YOURSELF in a trial and error process. you do not become one if you play the blame game. a PHB doesn't start anything if he doesn't know where eventually the blame will lie ( in management speak "an exit route").
2.for any pro, the equation Effort---> Results must remain valid at all times. A geek could stay up all night programming, but if it is one of those days when nothing good comes out of the grey matter, the urge to do anything else is a dominating factor. for a PHB effort is the end, not a mean to an end; he must be SEEN SWEATING at all times. incidentally, this lack of "creative Laziness" makes the higher up actively opposed to any productivity enhancing idea (...if we use gadget XYZ, we'll do the same job better in less time".... "oh, but then people wuold work less, that's unethical!!")
3. a geek in management would probably pay to go back where he belongs, if only because there's what I call a "farmers' factor" in line work. If you plow a furrow and then look back, you're able to see the job done; if you're in management, and you are accustomed to see what you're doing, you'll be deranged shortly.
4. if, by some quirk of fate, a geek or pro could make it to the valhalla of management, he would wield a mean axe all too soon. the instinct to question the validity of solutions, to trial and error would probably send him to an unexpected finding: all organizations have way too many managers for the amount of work managed. In addition, whenever the managers have seminal choices to do, their accuracy approssimates a random function. In all fairness that's probably because there's not enough info to make a sound decision, but if that's the case, back to the axe.
oh, another thing. it 's funny that "golf buddying" is part of the selection process: in golf, you do not have anyone to blame but yourself.
"If a boss demands loyalty, give him integrity. But if he demands integrity, give him loyalty." (John Boyd, 1927-1997)
Funny how my company has almost none of those. Most of our programmers are very vocal, in front of their peers as well as managers...
The only way to make management fun for those types of people is to show how a good engineer is like a good manager. Both are jobs where creativity, design, and a deep understanding of the field are necessary. Of course there are horrible ones in both fields, most are in each for the money not by interest.
For example, you can view an organization's strategy the same way you view a product's design. Developers create UML to think through the design of their program and then to communicate it to others. Its not heavy on implementation details. Managers map their strategy using the Balanced Scorecard approach. Both have some details set. Where classes might have data elements defined, scorecards have measures. Above all, they were designed to somehow fulfill a vision.
If you leverage the creative side of an engineer, then business is fun. Its all about presentation.
"Open Source?" - Press any key to continue
Vic Reeves, I believe
WE NEED MORE GEEKS IN MANAGEMENT
... and some accountant thought it would save money to send them via the internet which actualyl costs us fees to up-load and down-load what they wanted to send. No matter how many times we tried to tell management it was MORE EXPENSIVE to send stuff over the internet, they refused to believe it cost money, because they thought the internet was some big Free thing that everyone on the planet could connect to without cost.
.. but do you think management would take the root password off tem after that? Nope!
:-)
The only manager I worked under who was any good, the provebial "enlightened manager", had risen from the geek ranks. However, he was pretty much trained to be a good manager. He had previously worked for EDS who invested a heap of cash in his management training, and it really paid off.
Other managers I know who rose up from the geek ranks, usually lack the people skills to actually be effective managers. Quite often they think they know technology so well, that they also can't see past their own ego.
The worst IT managers though, were the ones who had no idea about technology, and constantly made major faux pas almost every day due to their lack of understanding of what was realy needed. Their interpersonal skills also deteriorated. When they first start in IT management, they have the people skills, but as their stupid ideas get more and more resistance, they begin to feel that there is some sort of mutiny on and become rigid dictators who threaten people with sackings if they do not perform their stupid requests.
I've seen these sorts of managers ruin entire IT departments. Especially if they have come from accounting backgrounds, where they only care about the bottom line, and ignore people and good work practices in order to get things done.
The last place I worked, they removed the IT manager who had come from a geek background, because he opposed them for attempting illegal shortcuts (like removing security). He was replaced by an accountant who used to demand the other managers be 'yes men' to whatever ideas were past down from above.
The last straw for me was when they asked me to set it up so that they could send scanned checks with peoples bank details across the internet UNENCRYPTED. Quite illegal, and quite stoooopid. It resulted in a nasty battle with lawyers and HR involved, and the company was forced to give in.
This was in spite of the fact, that we had a private WAN which sent those scanned checks for free
So, it would be nice to see more geeks get into management, but only after they have had extensive traininh in managing people OR if they grab the manager from outside of IT, they need to ensure they get a good understanding of what IT is, and how it works.
Another good example of where non-IT managers fell down, was when I was a System Admin. Manaement insisted I give the root password to two guys who didn't need it, just because they convinced management that they couldn't do their jobs without it. Management couldn't explain to me why these guys couldn't do their jobs without it, but I still had to inform them whenever I changed the root password, or else I was going to get sacked. I was so glad whenI moved positions, because the security for those machines was impossible. One of those idiots blew away the i-node to the password file when he was trying to hack peoples passwords. The idiot. That was a tough day for me
Just my two cents worth.
Mainichi onaji kotono kurikaeshi.
Sure enough, the cow costume was hanging up next to the superhero outfit and sailors uniform. (S,Spud)
I have also been managing a group of 10 programmers for a few years, and in fact i appear to be doing a good job (on target for cost, quality and time; what more do you want?). To achieve this i needed 3 weeks of management training.
Recently i went back to programming. Why? Because it is more challenging (hey, isn't that ironic?) and it pays better to be a good programmer (and isn't that unexpected?). Being a manager is not hard, but it's a misserable job, mostly because other managers appear to like making life difficult for eachother. The only advantage it has is that it pays well compared to other misserable jobs. Maybe management is interesting if you are really free to make your own choices, but you will only that get if you can start your own company without needing 'intrusive' financing.
I am straining my suspension of disbelief circuits here.
Do you have an example of any working software that acutally does anything ? How about a description of how to achieve a specific task eg, how would you sort some numbers into ascending order using this methodology ?
Or, is this just some kind of elaborate joke ?
http://rareformnewmedia.com/
They are exactly the sort of management that the industry needs, will likely encounter great success, and could serve as beneficial trend setters.
I agree with the first and last part of that sentence, but not the middle part. If you do your job well, no higher manager will ever notice. Only if you allow a big fuck-up to occur and then rescue the project, but that's not being very professional is it? Can you explain how you think these kind of managers will likely encounter great success?
In much of central europe, the term engineer is "protected" much like that of "Dr". If I had studied for a diploma in engineering in Germany, I would be entitled to prefix my name with "Dipl. Ing. ". Such a qualification requires about 12 semesters studying at University (6 years) or an equivalent level insitution. It doesn't matter whether the subject is trains, or software - the title is protected.
See my journal, I write things there
It's grieving to see how SCO has changed since then...
Please correct me if I got my facts wrong.
In some languages, there is no confusion in that matter, as the word for engine has no resemblance to the wor for engineer.
In Portuguese (spanish and french may be similar):
engenho: wit
engenheiro: engineer
no confusion, duh
Like in so many cases, the same word has different meanings, and different origins.
This forum ain't in Europe, son. It's international. Too bad.
Sure, some are. But I've known some managers who were too. (The reason such people climbed the corporate greasy pole was they had a reasonable degree of sociopathy).
Saying that programmers are schizoids is like saying executives are dumb, greedy crooks. Sure, some are, but the majority are not.
Most programmers I know are urbane, intellectual and have bags of common sense.
I'm amazed that we still tolerate programmer stereotypes when it is illegal in the work place to make derogatory comments on other peoples' racial/sexual/religious persuasions.
--- "We've always been at war with Eastasia."
An EE course that doesn't involve programming? Strange. I'm an EE student and we have to do quite a few CS subjects. And you know what? The CS subjects are the easiest i do. The hardware stuff (circuits, gates, microprocessor design, etc) is way harder. I'll never complain about assembler again.
If the author had used Lisp, he wouldn't have written that a 25% increase in the complexity of the problem results in a 100% increase in the complexity of the solution.
He also wouldn't have written that quality tools/techniques aren't important. Quality programmers will spend a large chunk of the lifecycle choosing and/or developing appropriate tools/techniques to attack the problem.
Others have said it better than me. See Still Relevant and There's Gold in Them Thar COBOL Skills . For some "true facts" on COBOL, see What Professionals think of the Future of COBOL? .
Just as an example off the top of my head, it's common to write if (condition = immediate) ...
Need I say more? C and C++ is full of these. Was there any "code review" when C was designed? I think not. C++? Negatory. Both were designed by some geek or group of geeks, with very little contact with the real world. IMHO.
You can't. Any software project that requires tens or hundreds of programmers is doomed to failure.
All successful software projects have been developed by small teams, regardless of the size or complexity of the project. Large teams tend to run into the "Mythical Man Month" effect.
One example I can think of: Cisco's IOS. Three years ago, when I attended an executive briefing at Cisco in San Jose, I was told that Cisco had 3,500 engineers working on IOS. Yes, some of those are QA engineers, not writing code but instead developing test cases. Yes, IOS consists of many programs running on a real-time kernel, just as "Linux" consists of hundreds of user-space programs running on the kernel. However, most of those Linux programs are orthogonal in nature: if vi blows up, it's not going to take gcc, cupsd and Quake with it
The briefing I attended was to address the issue of trying to get a "stable" IOS release out of Cisco. I was working for an ITSP at the time, and we had hundreds of Cisco 5300 H.323 gateways deployed around the world. We were desparately trying to deploy new functionality, but were unable to get a stable IOS release out of Cisco; every time they'd release a patch, it would break something else. After 18 months we still hadn't received a stable release, thus the briefing.
At the briefing, Cisco recognized that they had a problem. They showed us graphs of defect rates over time by release, talked about internal initiatives to address their perceived quality issues, and introduced us to their new head of software development, who promised to clean up the whole mess.
A year later, the situation had not improved, and shortly thereafter they had yet another new head of software development.
From my perspective (software engineer with 20+ years experience), the problem is simple: they have too many engineers working on too old a code base. The only solution for them is to start a "skunkworks" project with a small team to re-architect, re-design and re-implement the entire thing from scratch. Until Cisco takes this approach, IOS will continue to suffer from stability issues and ridiculously long lead times for new features.
I don't mean to pick on Cisco specifically; I'm sure that every large software development organization has the same issues, and for all I know, in the two years that have passed since the last time I dealt with Cisco's development organization, things may have improved (but I doubt it). Cisco just happens to be one that I'm familiar with.
Don't underestimate the power of The Source
> I like to think that, a skilled engineer could learn to be a skilled manager in under 12 months, but a skilled manager, could only become a skilled engineer in 12 years :)
And then you wonder why so many managers suck!
90% of the managers most people on this thread blast started as managers thinking just what you think.
See, just too many tech people think they can easily switch to mgmt and be good at it in a year or so. I've done mgmt for 10 years now. Along the years I've prepared a hell of a lot for it and I'm still learning it. What makes you an ok manager can be read in books. But unlike technical work, what makes you a really good manager can't be found in books. It takes a lot of time, requires that you live through a lot of varied situations, and takes an awful lot of introspection which starts with willingness to do so.
Do all your peers a favor, keep coding.
I have been doing QA/Testing for 10 years, and it is pretty sad how all-important people think programmers are. The best ones may be, but they aren't all the best ones. When you foster an atmosphere where "develpment is always right" you run into major roadblocks in software development. Requirements analysts can't do their job properly or requirements are ignored. Documentation people are glared at for trying to make the system understandable. (yet we all love to bitch about bad online documentation) Test people are seen as people who are just blocking the inevitablility of shipping the code. If anyone tries to even analyze why things are F'd up, they are seen as "not being team players" and "finger pointers", even if you are trying to fix the process and not the people.
I will say that what he says about inspections is right on. Although, I think just focusing only on code reviews is wrong - rigorous reviews of requirements/code/test plans/process docs/user doc/etc will remove 90% of the defects. And defects in requirements are much more costly to fix later. The trick is balancing which of these are most important for your company to review, depending on the project. You can't just do it willy-nilly, you have to do a risk assessment on it and make a decision based on something.
I actually had a director of engineering say in a meeting "Since we implemented my new requirements management process, I *guarantee* that the code will work, first time, out of the box." I laughed out loud, and received a very dirty look from him, but agreement from everyone else. Needless to say, that release is the worst one we have had in 5 years, and it is at least 6 months over schedule. People have had to work a lot of OT to try and shine this turd, and they are getting burnt out. Most places do software development and not software engineering. Which is fine, as long as you are clear about it.
I just thought of a very good analogy that /.ers can understand. There is probably little doubt that Microsoft has a lot of good programmers. However, their culture and business model has lead the direction of their product. That alone should show you that software development is not all about the programmer. On the other hand, OSS is great but it can only get so far on "good code". Once it is managed, it can be pretty powerful.
My beliefs do not require that you agree with them.
Those are some very good observations.
I can relate to the randomness of mangement you make in point 4. When our manager was out, we would flip a coin to make management decisions. Heads is inefficient solution, tails is approach that cannot possibly work, edge was the solution we were supporting, and dangling in the air indefinitely was no decision. Aside from aversion to decision, which was 80% of what our manager would do, the heads/tails/edge options approximated the 20% of decisions actually made.
Maybe there is something to golf in management. They choose a sport where they are solely responsible for their own outcome for their free time and choose to take no responsibility for their own actions professionally. Perhaps geeks are not as "complex" as PHB's - we have a hard time doing the constant context switching between the double standards.
How does debugging not cost money now? I've seen the problem broken down as this before: Any non-trivial piece of software will at least 100 different inputs (in bits) which will result in at least 2^100 test cases.
Checking all possibilities to fully debug the program would then be a matter of checking 2^100 test cases. That would not only be extremely costly, it's not possible in a reasonable amount of time. Debugging is important too, but since you can't fully debug a program you want to take other measures as well.
There's no way in hell that software is going to replace a good manager, not now, not in 100 years. Good management is all about people skills, understanding the interactions and politics in a workplace, keeping your workers happy and motivated, etc. Computers can't even understand simple written text, despite 40 years of AI work into doing just that- there's no way they could handle a good manager's job. (I insert good there a lot- computers could duplicate a PHB pretty well)
Typical "geek" stuff, on the other hand, gets easier every day. People used to joke about trying to record something on a VCR- now we have Tivos. Programming used to involve hex dumps- now you can buy totally visual, drag+drop programming environments. Yes, there will always be complex problems, but the ability of easy-to-use tools to do those complex problems is increasing rapidly. (Although I don't see a computer understanding human speech coming any time soon- see above :^)
"Seven Deadly Sins? I thought it was a to-do list!"
> You're not going to "prove" any opinion. Opinions have no true/false status.
Only if you have no absolute standards. A statement "COBOL is a bad language" can be a fact if all its terms are explicitly defined. For example, if one were to define a bad language as "a language lacking support for modular design and interfaces", then "COBOL is a bad language" becomes a fact because it is logically derived from provably real premises. Logic is a method of ensuring your statements correspond to reality, and a logically proven statement is a fact because no matter how many people have different opinions, it is still true. Of course, the hard part is creating the real premise chain. You have to define what makes a language bad or good, explicitly explain why the traits that make it good are the only ways of making it good, and then finally prove that COBOL lacks those traits.
> I just get itchy when people think that because THEY think something, it must be a fact
And you are correct. An opinion does not become a fact just because you feel it is right. It becomes a fact only if you can logically prove it to be right, because then its veracity is independent of how you feel about it and of how other people may feel about it.
Shows how much you know. Forth is NOT used in embedded systems,C/C++, Ada, Assembler, some Java. And I've never worked in Cold Fusion..not everyone has used every tool. Ad hominen attacks are not going to get you any mod points. Crawl back under your rock.
One of the problems w/ today's programmers is that they don't have the theoretical knowledge to understand why MySQL might not be the best thing to use instead of Oracle, and why PostgreSQL is a much better fit.
Likewise, many of them are opting not to learn assembly language, and are winding up not knowing how computers actually work. It's very frustrating.
On top of that, few programmers know of even the leaps that computer science made in the 60's, and are still using the state-of-the-art from the 50's. That's great if you know the difference, but if it's because you just aren't aware of it then there's a problem. Things like closures, continuations, hygienic macros, languages w/ better type systems, multimethods, ambiguous values, and lazy evaluation just to name a few. The fact that a language w/ a garbage collector was seen as a huge improvement in the 90s showed just how far behind we were.
A lot of programmers start off in a tiny little area and never even peer to see what might be beyond the horizon. How many Windows programmers even know what a regular expression is? How many C/C++ programmers know that they can have garbage collection _in_ C/C++? How many people have had to implement logic processing in a language that just wasn't well-suited to it, just because they didn't know the languages that were better?
I see this happen all the time, and it's very frustrating. Some software houses, in an entire staff, do not have anyone who looks above the day-to-day grind to see what else might be out there.
Engineering and the Ultimate
That may be what your intuition tells you, but you're wrong. That is the most expensive way to debug software.
When you find a defect in code inspect, you have your finger on it. You know exactly which line of code is faulty, and you know how it is faulty. Fixing it is trivial.
When you find a defect in unit test, you know which subsystem is at fault, but you may have to spend some time digging around to find the acutal problem and fix it.
When you find a defect in system test, you may not know anything about it. Your problem could exist anywhere inside your system, and it may take considerable time to track it down.
This is born out by statistics. In my particular large-nameless-software-company, we spend, on average, about an hour to fix a defect found in code inspect, about 1-2 days to fix a defect found in unit test, and about 3-4 days to fix a defect found in system test.
If I have 100 defects to remove, I'd rather spend 100 hours fixing them, than 400 days.
It's also much faster and easier to find defects in code inspect than in unit test or system test. You spend less effort to find a defect in code inpsect than you do in unit test.
Ideally, though, you want to remove your defects long before code inspect, in design inpections and requirements inspections. They are an order of magnitude cheaper yet to find in these stages.
System test, by the way, should never be used as a tool to remove defects. It is a method for verifying the quality of a system. Verify is an important word there. If you test your system, and your rate of defect discovery (vs. effort) is high, it is because your system is of very poor quality. If it is low, it is because your system is of very high quality. Either way, any "reasonable" ammount of system test effort will find a small fraction of the defects in your system. You should still fix any defects you find, of course, but if you find a lot, you're in trouble, and extra testing won't get you out of it.
>Good management is all about people skills
.NET platform. There ain't nuthin easy there.
Exactly, which is why I contend that geeks are probably the least fitted for the task.
> Typical "geek" stuff, on the other hand, gets easier every day
I wouldn't be so sure. Ask the guys who are porting python to the
"Piter, too, is dead."
I think that statement speaks for itself.
All's true that is mistrusted
Perhaps because when our large company had everyone taking the Meyers Briggs Personality Inventory back in the late '90s, we saw a hugely disproportionate share of introverts among the programming staff? Or perhaps it's simply because introverts tend to avoid management positions, since interacting with people is not high on their list of "things they enjoy doing"?
You fall back on anectodal "evidence" that suggests your experience of hanging around with extroverted people is somehow related to their profession, when it's much more likely you hang around extroverts because you're an extrovert yourself, and you hang around programmers because you're a programmer. Those are two separate affinities -- don't get them confused just because you share both of them.
Finally, I never called programmers "schizoid" -- you made that up from whole cloth. I also never said introverts don't have "bags of common sense", nor did I say they weren't intellectual. Common sense and introversion are unrelated. You apparently are having very a hard time distinguishing introversion from a mental disorder, and seem to either be afraid of introverts, have a distate for them, or simply make no effort to understand them.
My suggestion to you is to quit whining "stereotype, stereotype" just because someone recognized a cause and effect relationship that happens to involve people. In the field of biology, recognizing cause and effect among life forms is often called "research." That, and get out there and encourage a few shy people in some way. You seem outgoing enough, you'll probably do both of yourselves some good.
John
Yes, management is a skill that can be learned
You're right about that. It's nothing but a skill surely can be learned easily, and it involves doing nothing.
It certainly is not a science, as many would like to believe. Just as economy, psychology and a lot of other vague... hm... activities.
Remember who we have to thank for the internet bubble. Do assumptions like "With internet we'll get all rich" and "Profits can be doubled each year".
Here is what I know about Forth...it's OLD, it was a custom language developed for use in Astronomy in the 1960's(telescope controls I think). It did become a standard, but it has really fallen out of favor. Based on my experiences I'd say it might have 1-2% of the market. It's a lot like Perl in that is has a funky syntax. It was used in some UNIX boxes as part of the Boot ROM. Perhaps there are some niche areas it is used today (industrial controllers?) but its not common at all. So Mr Expert...can you tell me which OSes are most commonly used in embedded systems, and the difference between Windows CE and Windows? Can you code the same thing in Ada/Ada95/C/C++ and tell me which one will use less memory and run faster? What is the difference between the Motorola Memory Architecture and Intel? Describe the VWE Systems Architecture? What is FibreChannel? What is BigEndian? What's the Carry Bit? What gets pushed on the stack in a context switch? Why? What's a protected section? Why are they used? What is a NMI? What is rate monotonic tasking? What is priority inversion? What's a semaphore? How many types can you name? What's DOD-STD-2167A? Ever written PL/M? Can you hand optimize compiler generated assembler? Do you have software flying in front line fighter systems? In space? Ever seen a mega-million dollar defense project cancelled based on your word the software was screwed up and wouldnt work? Answer these questions and you'll have my respect, attack my credibility and you are only going to incur my disdain. I'm done with this thread..I got a lot better things to do with my time.
The problem in a business shop is that everyone has a day job -- crank out this code. Like most people, we'll continue to do things the same old way until someone shows us different. For example, in the early '90s when we began the migration of our business product to a Windows based platform, most of us had only briefly encountered object orientation in books and magazine articles (those of us who bothered to keep up with the trade publications, that is.) At that early time (for us), it was difficult to distinguish object oriented programming from any of the other programming "fads" of the day. For example, at that time management still thought code generators would be the magic bullet, and placed little emphasis on learning the new object oriented languages. They did not provide any encouragement to any of us to move forward professionally (although some of us did on our own, anyway.)
Recently, we brought in a consultant to help us with a large refactoring effort. I learned so much about agile programming (and not so much about refactoring) that I'm trying to figure out how to take a six-month sabbatical to go code on an agile team somewhere else just for the experience. It was really an eye-opener for me, and I think if I knew more about it, or experienced it first hand, I'd love to get it in house. More than anything, the consultant reopened my eyes to seeing what else is going on out there, over and above the daily grind.
But that's not the common viewpoint of many of the developers -- they just want to come in, write their code, and then go home to play softball or drink beer. It's not that they're opposed to learning a new methodology or technology, they simply aren't interested in personally learning that subject and then bringing those ideas in house. They see no payoff in learning assembler, or what an IP stack is, or why it's written that way, and so they don't put the effort into it. Even though they can look to the people who have that knowledge and see how successful they are, they don't often take that initiative upon themselves.
But what's ultimately most frustrating to me is our primary software vendor partner is just as old school as anyone else I can think of. We're talking "let's write our own string library because we're ignorant of the std::string library" kind of old school. (I mean, the old saw that writing your own string class is one of the stages every newbie passes through is now 10 years old.) The reason I'm so frustrated is that they're "outside" of our daily grind, so theoretically they should be exposed to methodologies from dozens of other clients. I originally expected us to get "modern" thinking out of them, but we've ended up driving more change in their organization than they've given us.
John
You consider Windows CE real "embedded systems" work. I understand now.
All's true that is mistrusted
It's not capitalism, and it's not that it's the worst there could be, it's just that it's the worst that has been tried so far. So don't give up, better alternatives to democracy do exist. Someday people will look back on democracy the same way they now look back on trepanning and COBOL.
heressomefuckingcontentforyadumbass.
PL/I has a fixed-point format, according to the ANSI standard. I've read that there are fixed-point extensions to C. And although I don't know it for a fact, I assume someone has written a fixed-point class for C++. 18 years ago, my employer wrote fixed-point routines for Turbo Pascal, by carefully handling the real datatype (or whatever Pascal calls it. Not the best approach, but adequate.)
Contribute to civilization: ari.aynrand.org/donate
" Almost all the people I know who have become successful managers have never been real programmers"
Because of people like you it's that most projects fail. Don't talk about succes here!
People in management don't have a clue whatsoever of what is going on in their company, what product their selling, are managing and always have overbloated expectations.
Just like the economists rule "revenues must double each year"!!!!!!!!!!!!!!!!!
Just as an example off the top of my head, it's common to write ...
... ...
if (condition = immediate)
On a similiar note, things like
if (pointer = NULL)
always used to find its way into my code by lazy fingers not typing "==". A friend showed me a trick to have the compiler complain and catch this bug. Simply put the constant first, i.e.:
if (NULL = pointer)
which will cause the compiler to barf, so you can correct it with minimal frustration. I cannot believe how much time this simple trick has saved me!
Demonstrant's Open Source Tools
If it was just a bad rep, the COBOL people at least would use for something else.
So that C++/script languages was just to make that point a bit less boring.
If you are going to be a flaming asshole then at least do it when you have read the article and the discussion so you've understood the argument...So your description of my article makes me think about the classic "when Peter speaks about Paul, we learn more about Peter than about Paul"...
Karma: Excellent (My Karma? I wish...:-( )
My Turing argument here was an answer to Oligonicella's "[I have] accomplished anything that needed doing [in COBOL]". Of course you can do anything in any language. (If it's a good tool for the problem is another argument.) The second time I posted, was because Oligonicella seemed to not be aware of the theory regarding Turing machines and argued that there were things some languages couldn't do.
Well done, though, to accuse someone else for bad logic while misrepresenting their points! Did you do it on purpose or where you lucky?
Here is the quote from the book I started from:
That is the common opinion, like that water (under certain temperature and pressure ranges) is wet. COBOL is a specialised language -- that work well for it's problem domain and is hardly used at all outside it.You argue -- "If COBOL handles currency better than any/most other languages, then use it for financial programs."
WTF 2??
I have never written anything else! Your point isn't contradicted by "Fact 30" above, either, which I've not argued against -- just tried to work around.
That was the second point you are claiming I've written things I've not done. I stopped reading.
I think you're a troll and I'm not stupid enough to waste time arguing with you.
Karma: Excellent (My Karma? I wish...:-( )
I don't really believe it's an honest complaint. You're just grasping for an excuse for being an asshole troll.
I gave two points:Given the above points, a full argument seemed superfluous. Especially since you clinically have avoided commenting on the reference to the well documented book (and everyone else in the computing world) -- and instead demanding references from me.
And with you flamers that wrote in support, I expected lots of counterclaims about how good some total idiocy is. In short, it was a can of worms I didn't feel a need to open with non-serious debaters when I had the two strong points above.
Karma: Excellent (My Karma? I wish...:-( )
No, you said:
"Many are extremely introverted and have trouble speaking up among their peers; they simply would not be capable of dressing down an employee who desperately needs it."
Compare and contrast with:
Schizoid personality disorder (SPD) is a personality disorder characterised by a detachment from social interactions and a tendency towards a solitary lifestyle. SPD is characterised by ... indifference to either praise or criticism.
"You apparently are having very a hard time distinguishing introversion from a mental disorder, and seem to either be afraid of introverts, have a distate for them, or simply make no effort to understand them."
Gee, you must be awfully clever to conclude all of that from just a few paragraphs. I wish I possessed your perspicacity.
"My suggestion to you is to quit whining "stereotype, stereotype" just because someone recognized a cause and effect relationship that happens to involve people."
And my suggestion to you is that you study why "correlation" does not necessarily infer "cause and effect".
--- "We've always been at war with Eastasia."
Damn Skippy. I'm computer engineering (Yes, different from Software) and after my first year (transferred in, so consider it soph and jr. level classes).....the Mentor suite (logic design) labs were much more in depth and harder than the craptastic java assignments ("Intro to computing")
Course part of that was the fact that Mentor apparently sucks...but it was still harder.
If you can't see the value in jet powered ants you should turn in your nerd card. - Dunbal (464142)