You're not alone. There are quite a few crappy mainframes out there, and it highlights the difference between an actively maintained mainframe enviornment and a "let it rot" environment.
The latter is common due to IT turnover and management that couldn't be bothered to take the risk & cost of upgrading mainframe hardware + OS software, so it gets slower and slower as load increases and requirements change. When there's no one around that understands the custom software well enough to repair it if an upgrade breaks it -- or if an upgrade WILL break the software (quite common) and requires significant re-writes -- it's going to rot.
As for data quality, that's a function of the application code, not the mainframe itself. Apps from the 1970's and 80's were usually more lenient to data entry. This changed in the early 90's in some companies, but of course, not in others... that's why there's a whole "data cleansing" sub-industry out there.
There's a lot of divergent opinion about H1-B's. I think it comes down to a philosophy of what corporations responsible for, i.e. what is the purpose of a business?
One side suggests that business is responsible for job creation. But this is no better than the school of thought that says business' sole responsibility is to make a profit. It's a chicken-and-egg argument: companies don't make money, companies make shoes.
Another side suggets that business is responsible to its customers, i.e. to the market. Businesses exist solely to create customers. To fill needs for the market in an economically efficient manner, measured by profit.
If it's about serving consumers, globally, then arguably labour force should be global as well.
I don't think H1-B's are a bad thing, as they represent the "free movement of labour". ABUSE of H1-B's is rampant, and must be curtailed, but the laws as-is are fair.
Let's also not forget that NAFTA has effectively created a "North American Free-Trade-Labour Zone" with the TN-1 VISA program. University graduate Canadians and Mexicans can work in the U.S. at ANY TIME, for an UNLIMITED (yearly-renewed) amount of time. This is the direction of American policy -- freer trade in goods, services, and labour. IS it really a bad thing?
My bias is that I was Canadian under a TN-1 visa in the U.S. for 3 years, along with several of my collegues from university. We certainly weren't underpaid (if low 6 figures in California and NYC is underpaid). And the main reason people hired us was because management felt we were better educated and offered a better value than comparable U.S. citizens that they could find.
I don't know if they were lying, but that's the jist of what I hear from people wanting to use Indian H1B's and offshore development. Indians are educated almost as well as Americans, and sometimes better -- why not use them? It's about a combination of money and skill. Companies are going to make a tradeoff among that continuum to hit the right sweet spot.
Offshore has a host of problems relating to communications and hence will probably not work beyond narrow projects with slowly changing needs or requirements. The timezone difference, communication gap, and cultural differences make for a very difficult collaboration. This makes H1B programs palatable.
Protecting labour markets is a long history in the U.S., and there's a lot of inconsistency in it. I would suggest that markets will be protected or opened based on which group has the most local political power -- the farmers, the unions, etc. on one hand, or the technology lobby groups on the other hand. But the general policy of the past 2 administrations has been "freer labour trade".... and I'm not sure that's going to change.
Codd's 12 rules explain what makes an ideal RDBMS. He invented the model, so it probably makes some sense.
MySQL, in particular, violates rules #5 & 6 & 10 (and maybe more) -- it lacks a comprehensive data sublanguage (it's a subset of SQL, which already is limited in how much it can do), and views (particularly updatable views, which many RDBMS still don't support). Lack of foreign keys in MyISAM violates rule #10.
Things like views are "derived relations", and are key ways of simplifying queries. It's almost the equivalent of saying "no function names allowed" in C - everything must be in main().
Subqueries are crucial for key algebraic operations (there are 8 in total, I won't get into all of them here). One such operator is division.
Division can be simulated in MySQL using temporary tables, but this is woefully complex to specify and quite inefficient.
An scenario of a question that requires division is (excerpt from Joe Celko's article above):
A data model of Pilots, Planes, and a Hanger with planes inside of it. There's a table PilotSkills that relates which Pilots have the ability to fly a particular Plane.
CREATE TABLE PilotSkills (pilot CHAR(15) NOT NULL,
plane CHAR(15) NOT NULL,
PRIMARY KEY (pilot, plane));
CREATE TABLE Hangar (plane CHAR(15) NOT NULL PRIMARY KEY);
The question: which pilots can fly EVERY plane in a particular hanger?
In SQL, the answer is ugly, but requires subqueries:
SELECT DISTINCT pilot
FROM PilotSkills AS PS1
WHERE NOT EXISTS
(SELECT *
FROM Hangar
WHERE NOT EXISTS
(SELECT *
FROM PilotSkills AS PS2
WHERE (PS1.pilot = PS2.pilot)
AND (PS2.plane = Hangar.plane)));
The quickest way to explain what is happening in this query is to imagine an old World War II movie where a cocky pilot has just walked into the hangar, looked over the fleet, and announced, "There ain't no plane in this hangar that I can't fly!", which is good logic, but horrible English. (and is also why some dislike SQL.)
1) Have a good manager (the more the better) 2) Have a good programmer (the more the better) 3) Have a process congruent to your goal.
Processes will not eliminate the need for managerial or technical competence.
They do, however, help: - communicating with the team - communicating with the customer - keep an eye on quality.
And the whole point of this "communicating" is to: - gather requirements - clarify requirements - prioritize requirements - make people realize ASAP the requirements have changed - figure out how the heck we can encode these requirements in software
The whole point of agile methods like XP or SCRUM is to support projects where requirements aren't clear, their priorities aren't clear or change, and requirements themselves change. Which is like most in-house business environments. It might (or might not) be appropriate to product development.
Good coders will produce good results with or without methodology.
Absolutely!
But it doesn't mean their results will be used by the customer.
In other words, good people will develop things "right". Methods help you develop the "right thing" by providing a communications framework between the team, management, and the customer.
Agile methods like SCRUM and XP were created under the assumption that people ARE the the most important thing in development and methodology is secondary. They ask: What's the least intrusive set of ceremonies/tasks/disciplines so a group can work effectively?
XP in particular was created because many projects get canned because: a) results were delivered, but they weren't the results the customer wanted, b) money ran out and they couldn't use results developed up to this point (it was all "groundwork"), c) customer needs & direction changes and it eventually costs too much to modify the design, so the project is cancelled or re-written.
So -- in the end, hire good programmers, have a good manager, and use a process that is congruent to your goal.
If that goal involves constant requirements change, and unclear customer requirements -- an agile method like XP or SCRUM may be more appropriate than an incremental process like MSF or Spiral or RUP (which can be made to be agile too).
In general, Martin Fowler's "Patterns of Enterprise Architecture" contains a number of patterns for web & business systems.
"Performance Solutions" by Smith et al is probably the best modern (i.e. recognizes OO)treastise on how to design a system for performance.
For the Java world, I would suggest "Advanced JavaServer Pages" by David Geary and/or "Expert One on One: J2EE" published by Wrox.
There isn't much on integrating XML services out there, and there's a lot of freedom.
As for SQL services, the book I found most helpful is Expert One On One: Oracle by Thomas Kyte. It's oracle-specific, but a very high signal/noise ratio.
You raise a good point, and I am very aware of Senge's work (and Ackoff, Argyris, etc.) on learning organizations.
Change management and organization design & configuration experts have been popular in the literature for some time, there's a lot of good (and not so good) ideas out there, though they're still on the leading edge of practice.
My original statement that manager's can't use an engineering approach is wrong; in retrospect I was trying to suggest that organizations are very difficult to design up-front. Many of the assumptions and tradeoffs in a structure are invalidated through growth. And re-design involves migrating human systems to the new structure -- a task that requires more than systems thinking (hence Senge's four other disciplines, which are often much harder to achieve in large groups).
However, don't underesimate the importance of computing in the business world. It doesn't just deal with person to person communications. Sure you can use a computer to talk to a person over email, chat, video conferencing, or voice over ip. These methods of interperson communication are often very important and they have their place within a business
Of course I believe in the power of technology to improve communication, I am a slashdot user after all, and work at a communications company even.
I was being rather pointed in my responses because of the blatant "yay IT!" attitude earlier.
For example, if you need to discuss a design point with a coworker, email would be horribly inefficient. You would be better served by walking over to the coworker's desk and having a conversation.
Yes, agreed
However if you have prepared a summary design document and need to submit it to 30 people throughout the company, it would be ridiculous to hand deliver it to every person. You could place it in interoffice mail, but then it would most likely take at least a day. If you emailed the message, it would be delivered instantly and you would have a nice audit trail prooving you sent it.
Of course. Interoffice, fax, & photocopying were the old mass communication means before email... why go back? No reason.
If you have a chain 15 companies long and humans are handling all the order processing there's going to be massive delays and pretty soon someone in the chain is going to run out of inventory.
While I agree that electronic supply chains significantly reduce processing times, I will point out that most of the techniques for streamlining a supply chain are logistical and not necessarily electronic communications.
A good example is the way Toyota managed their supply chain in the 1970's. I would suggest computerized inventory management certainly was the key to making this work, not necessarily EDI...
Managers are trained to deal with schedule and budget. Not with designing complex systems.
An organization is a complex human system. Executive management are charged with viewing the big picture and designing a large complex system -- but they can't use an engineering approach, because they're dealing with people, not objects.
It's arguably more complex than engineering for many reasons: you can't guarantee strengths in individuals - you can only observe and take an educated guess, people tend to dislike change and may actively work against any change, plus there are many fuzzy aspects to actually inacting change in an organization due to the complex & mixed nature of an organization's motivation.
The closest thing I can think of is that managing an organization at the executive level is like debugging a concurrent, distributed system with byzantine failures.
This is why good executives are so rare, and why so many companies do a poor job of organization and re-organization.
(One half-baked aside: I find it amusing that the general solution in computing to byzantine failure -- quorum consensus -- looks amusingly like organizational bureaucracy. Both are woefully ineffecient as size increases, but work to eliminate corruption.)
Lots of eCommerce sites have gone with Dell PowerEdge for the lowered costs... obviously with mixed results, but I'm not so sure the Compaq-only mantra is as true as it once was.
So arguably, if Dell can get a foothold due to lower costs, why can't Apple? (other than IT managers not trusting that "fruit company")
Apple doesn't have a fault-tolerant clustering solution yet, so you'd have to rely on application-specific mechanisms --.e.g Oracle 9i Data Guard for databases (whenever they make a production Oracle release of course).
Can today's business world (which really means "corporations" rather than the entire set of all businesses) survive without face-to-face communications? Yes.
Disagree. While some businesses can survive this, the business world cannot in general because the sheer amount of bandwidth available in a face-to-face vs. email.
Can they survive without electronic communications (including email, EDI, etc.)? No. That makes electronic communications more important.
Disagree, again. I guess it depends on your definition of "business". Certainly big businesses need email and perhaps EDI. Small businesses -- questionable. Depends on industry, on focus, market, etc.
It's quite interesting that many people somehow believe people can't survive without an inherently low-cognitive-bandwidth medium, yet can survive without personal human contact.
That's all great, but I really hope you're not suggesting the majority of business communication in the world is accomplished this way. It isn't. It's sort of like saying telephones were the most important mechanism to communicate business before the computer. Important yes, the most important, absolutely not.
Are low/. numbers supposed to be penis size in the geek world? hmmm. then again, it was this way in the BBS world too.... "dude, you're user #8! whoa!"
i agree the master/servant, customer/consultant relationship with IT groups isn't really useful, but I think you're going overboard at times. For example:
Computing is the single most important method of communication in the business world.
That's daft. The most important communication is what occurs between people face-to-face. And we don't really have a lot of that either, more like a lot of mental masterbation and flinging feces at one another (at least at the last IT executive committee meeting I attended)
Before commenting, please live in both countries for a number of years, and then spout off.
Been there, 3 years in the U.S. (1 in Cali, 2 in NYC). Back in Toronto.
What I like about Canada? People, culture, media. What economically sucks about Canada? IT job pay, exchange rate.
Most day-to-day stuff I find is cheaper in Canada *except* cars & geek toys (like computers and electronic equipment) which is KILLED by the u.s. exchange rate. I have to spend over $5k for a new Apple Powerbook compared to $3.3k in the u.s. And I make 15% less than I did in the U.S. (and ONLY 15% because I have a good boss that argued for me).
Sure. Then I'll ask: how many users? And I'm not to certain an interviewer at a brokerage or manufacturing company would appreciate "hit reload" as your answer to fault tolerance.
Perhaps you misunderstood my point -- fault tolerance is about tolerating ALL faults - hardware, software, and user errors. How do you handle hardware failure? Do you crash-fail? Or do you continue in partial service mode? etc.
How do you handle software failure? Restart the server? Or do you go to the lengths of Tandem servers and have process-pairs for everything? etc.
So yes, you could put "enterprise software" on your resume, in the same way that anyone that learned QBasic and wrote a tic-tac-toe game could put "game development" on their resume. It still doesn't make you John Carmack.
I thought about including that in point #3 scalable, but I figured it was implicit.
To be scalable assumes that you A) have picked an appropriate response time and B) throughput is a limitation of the physical hardware, not the software.
I would suggest that "responsive" and "fast" are application-specific requirements -- how "fast" is "fast". Also note that response time is only one dimension of performance -- you don't mention throughput.
I can assure you that in most cases, an application's response time and throughput have very little to do with choosing Java as a technology and a lot to do with project management and technical leadership.
I used to teach J2EE to wall street developers, and in particular new college grads. Most have no clue what an enterprise application is, so I came up with a working definition.
Enterprise application is a software system that is:
1. Distributed (with all the requisite problems of distributed computing) 2. Secure (authentication, authorization, auditing, and encryption) 3. Scalable (can handle increasing load without a re-write) 4. Heterogeneous 5. Fault tolerant and/or Recoverable 6. As a corollary to (5), usually involves one or more transactional DBMS
Each of these topics by themselves can take years to master.... which is why people tend to hold well-designed "enterprise applications" in high regard.
I find modern tools to be pretty sufficient. Some of the following features are quite important:
- Edit/Continue debugging.... VB used to do this (not in.NET for now), JDK 1.4.1 does this. - Watchpoints (when is something edited?) - Jumping back stack frames (though you'll have to be careful to manually reset your shared state)
Tracking down bugs requires a certain kind of expertise. Usually it's harder to debug than to write new code, so that could be one reason why debuggers don't proliferate as much as modelling tools.
One way of gaining this expertise is to have experience in teaching other programmers in a hands-on course. You learn to spot common bugs quickly, and diagnose more complex ones. It's in an environment where you have 15+ people that all need your help at once... kinda pushes you towards honing that debugging sense.
In my experience, most "tough" debugging problems would have been solved if the developer just set the breakpoint and analyzed the code instead of sitting on their thumbs and thinking about it for 15 minutes. This might be fine for Kernhigan, Ritchie, Pike, and all those who suggest that "thinking" is the best way, but these guys also have *decades* of experience to do this without assistance. A debugger is a catalyst to this thought process.
Also, logging techniques are crucial, they isolate the location of a potential problem. But they're very time consuming to figure out WHY something is going wrong (because you never quite know what variables to dump out to stdout).
A debugger to seek stack traces & peek inside variables, change variable values, and edit/continue with your changes adds significantly to agility. It's partially why VB was so successful, and Eclipse is so popular in the Java world (and why most Smalltalkers have migrated to Java/Eclipse).
On the contrary: witness Nortel, who pays their Ottawa-based engineers way less than those in North Carolina (which has a similar cost of living, with the reasonable assumption of currency exchange-at-par).
Yet Roth, the CEO, in a widely publicized press statement, blamed the Canadian government's tax system for the brain drain. No, it's stupid pay policies that don't recognize NAFTA creates a "North American Employment Zone" through TN-1 visas. Anyone with a technical degree can jump ship.
(Here's my anecdote. I intend no offense to those unemployed, or affected by the economy, my financial pains are trivial compared to those down and out. I empathize.)
I happen to work in Toronto now at a significant paycut. I make 20% less per paycheck than my last job in NYC as a salaried consultant and trainer. The only reason I took this job is that it was a career move, the people I'm working with and what we're trying to accomplish will be a big resume bonus. But the pay & compensation really wasn't competitive for a senior-level technical lead in software development ("architect", whatever).
I'm still getting compensated significantly above average for a technical position in the area -- because my hiring VP basically gave me "senior manager" level pay, even though I have no subordinates. And she had to fight for that, hard. One quote was: "We don't have engineers, we have programmers." (shudder)
And U.S. computer/electronics equipment is generally 1.5x more expensive in Canada due to exchange. My new Powerbook G4 17" laptop is going to be over CAD$6500, what would be (with sales tax) maybe USD$3600 in NYC.
That's the general mentality of IT in Canada -- they still believe in paying "managers" more than "performers". A programmer is an interchangable unit of productivity, they never seemed to learn that 10:1 ratio nugget that I believe Capers Jones figured out 20 *YEARS* ago. Seniority and the peter principle rule.
Perhaps some companies are changing. My boss is keeping me satisified with conferences and educational opportunities (a budget she also had to fight for, "WTF do techies need training for?") Thankfully the CIO is on her side.
Wall Street, on the other hand, tends to give enormous compensation packages (even AT PAR, with NYC's cost of living difference) to technical leads that perform.
Many colleges and universities have not-for-profit status. They don't exactly have "shareholders" in the traditional sense of a for-profit public corporation.
Slashdot Mirror
You're not alone. There are quite a few crappy mainframes out there, and it highlights the difference between an actively maintained mainframe enviornment and a "let it rot" environment.
The latter is common due to IT turnover and management that couldn't be bothered to take the risk & cost of upgrading mainframe hardware + OS software, so it gets slower and slower as load increases and requirements change. When there's no one around that understands the custom software well enough to repair it if an upgrade breaks it -- or if an upgrade WILL break the software (quite common) and requires significant re-writes -- it's going to rot.
As for data quality, that's a function of the application code, not the mainframe itself. Apps from the 1970's and 80's were usually more lenient to data entry. This changed in the early 90's in some companies, but of course, not in others... that's why there's a whole "data cleansing" sub-industry out there.
There's a lot of divergent opinion about H1-B's. I think it comes down to a philosophy of what corporations responsible for, i.e. what is the purpose of a business?
One side suggests that business is responsible for job creation. But this is no better than the school of thought that says business' sole responsibility is to make a profit. It's a chicken-and-egg argument: companies don't make money, companies make shoes.
Another side suggets that business is responsible to its customers, i.e. to the market. Businesses exist solely to create customers. To fill needs for the market in an economically efficient manner, measured by profit.
If it's about serving consumers, globally, then arguably labour force should be global as well.
I don't think H1-B's are a bad thing, as they represent the "free movement of labour". ABUSE of H1-B's is rampant, and must be curtailed, but the laws as-is are fair.
Let's also not forget that NAFTA has effectively created a "North American Free-Trade-Labour Zone" with the TN-1 VISA program. University graduate Canadians and Mexicans can work in the U.S. at ANY TIME, for an UNLIMITED (yearly-renewed) amount of time. This is the direction of American policy -- freer trade in goods, services, and labour. IS it really a bad thing?
My bias is that I was Canadian under a TN-1 visa in the U.S. for 3 years, along with several of my collegues from university. We certainly weren't underpaid (if low 6 figures in California and NYC is underpaid). And the main reason people hired us was because management felt we were better educated and offered a better value than comparable U.S. citizens that they could find.
I don't know if they were lying, but that's the jist of what I hear from people wanting to use Indian H1B's and offshore development. Indians are educated almost as well as Americans, and sometimes better -- why not use them? It's about a combination of money and skill. Companies are going to make a tradeoff among that continuum to hit the right sweet spot.
Offshore has a host of problems relating to communications and hence will probably not work beyond narrow projects with slowly changing needs or requirements. The timezone difference, communication gap, and cultural differences make for a very difficult collaboration. This makes H1B programs palatable.
Protecting labour markets is a long history in the U.S., and there's a lot of inconsistency in it. I would suggest that markets will be protected or opened based on which group has the most local political power -- the farmers, the unions, etc. on one hand, or the technology lobby groups on the other hand. But the general policy of the past 2 administrations has been "freer labour trade".... and I'm not sure that's going to change.
Codd's 12 rules explain what makes an ideal RDBMS. He invented the model, so it probably makes some sense.
MySQL, in particular, violates rules #5 & 6 & 10 (and maybe more) -- it lacks a comprehensive data sublanguage (it's a subset of SQL, which already is limited in how much it can do), and views (particularly updatable views, which many RDBMS still don't support). Lack of foreign keys in MyISAM violates rule #10.
Things like views are "derived relations", and are key ways of simplifying queries. It's almost the equivalent of saying "no function names allowed" in C - everything must be in main().
Subqueries are crucial for key algebraic operations (there are 8 in total, I won't get into all of them here). One such operator is division.
Division can be simulated in MySQL using temporary tables, but this is woefully complex to specify and quite inefficient.
An scenario of a question that requires division is (excerpt from Joe Celko's article above):
A data model of Pilots, Planes, and a Hanger with planes inside of it. There's a table PilotSkills that relates which Pilots have the ability to fly a particular Plane.
CREATE TABLE PilotSkills
(pilot CHAR(15) NOT NULL,
plane CHAR(15) NOT NULL,
PRIMARY KEY (pilot, plane));
CREATE TABLE Hangar
(plane CHAR(15) NOT NULL PRIMARY KEY);
The question: which pilots can fly EVERY plane in a particular hanger?
In SQL, the answer is ugly, but requires subqueries:
SELECT DISTINCT pilot
FROM PilotSkills AS PS1
WHERE NOT EXISTS
(SELECT *
FROM Hangar
WHERE NOT EXISTS
(SELECT *
FROM PilotSkills AS PS2
WHERE (PS1.pilot = PS2.pilot)
AND (PS2.plane = Hangar.plane)));
The quickest way to explain what is happening in this query is to imagine an old World War II movie where a cocky pilot has just walked into the hangar, looked over the fleet, and announced, "There ain't no plane in this hangar that I can't fly!", which is good logic, but horrible English. (and is also why some dislike SQL.)
In order:
1) Have a good manager (the more the better)
2) Have a good programmer (the more the better)
3) Have a process congruent to your goal.
Processes will not eliminate the need for managerial or technical competence.
They do, however, help:
- communicating with the team
- communicating with the customer
- keep an eye on quality.
And the whole point of this "communicating" is to:
- gather requirements
- clarify requirements
- prioritize requirements
- make people realize ASAP the requirements have changed
- figure out how the heck we can encode these requirements in software
The whole point of agile methods like XP or SCRUM is to support projects where requirements aren't clear, their priorities aren't clear or change, and requirements themselves change. Which is like most in-house business environments. It might (or might not) be appropriate to product development.
Cheers
Good coders will produce good results with or without methodology.
Absolutely!
But it doesn't mean their results will be used by the customer.
In other words, good people will develop things "right". Methods help you develop the "right thing" by providing a communications framework between the team, management, and the customer.
Agile methods like SCRUM and XP were created under the assumption that people ARE the the most important thing in development and methodology is secondary. They ask: What's the least intrusive set of ceremonies/tasks/disciplines so a group can work effectively?
XP in particular was created because many projects get canned because:
a) results were delivered, but they weren't the results the customer wanted,
b) money ran out and they couldn't use results developed up to this point (it was all "groundwork"),
c) customer needs & direction changes and it eventually costs too much to modify the design, so the project is cancelled or re-written.
So -- in the end, hire good programmers, have a good manager, and use a process that is congruent to your goal.
If that goal involves constant requirements change, and unclear customer requirements -- an agile method like XP or SCRUM may be more appropriate than an incremental process like MSF or Spiral or RUP (which can be made to be agile too).
In general, Martin Fowler's "Patterns of Enterprise Architecture" contains a number of patterns for web & business systems.
"Performance Solutions" by Smith et al is probably the best modern (i.e. recognizes OO)treastise on how to design a system for performance.
For the Java world, I would suggest "Advanced JavaServer Pages" by David Geary and/or "Expert One on One: J2EE" published by Wrox.
There isn't much on integrating XML services out there, and there's a lot of freedom.
As for SQL services, the book I found most helpful is Expert One On One: Oracle by Thomas Kyte. It's oracle-specific, but a very high signal/noise ratio.
You raise a good point, and I am very aware of Senge's work (and Ackoff, Argyris, etc.) on learning organizations.
Change management and organization design & configuration experts have been popular in the literature for some time, there's a lot of good (and not so good) ideas out there, though they're still on the leading edge of practice.
My original statement that manager's can't use an engineering approach is wrong; in retrospect I was trying to suggest that organizations are very difficult to design up-front. Many of the assumptions and tradeoffs in a structure are invalidated through growth. And re-design involves migrating human systems to the new structure -- a task that requires more than systems thinking (hence Senge's four other disciplines, which are often much harder to achieve in large groups).
However, don't underesimate the importance of computing in the business world. It doesn't just deal with person to person communications. Sure you can use a computer to talk to a person over email, chat, video conferencing, or voice over ip. These methods of interperson communication are often very important and they have their place within a business
Of course I believe in the power of technology to improve communication, I am a slashdot user after all, and work at a communications company even.
I was being rather pointed in my responses because of the blatant "yay IT!" attitude earlier.
For example, if you need to discuss a design point with a coworker, email would be horribly inefficient. You would be better served by walking over to the coworker's desk and having a conversation.
Yes, agreed
However if you have prepared a summary design document and need to submit it to 30 people throughout the company, it would be ridiculous to hand deliver it to every person. You could place it in interoffice mail, but then it would most likely take at least a day. If you emailed the message, it would be delivered instantly and you would have a nice audit trail prooving you sent it.
Of course. Interoffice, fax, & photocopying were the old mass communication means before email... why go back? No reason.
If you have a chain 15 companies long and humans are handling all the order processing there's going to be massive delays and pretty soon someone in the chain is going to run out of inventory.
While I agree that electronic supply chains significantly reduce processing times, I will point out that most of the techniques for streamlining a supply chain are logistical and not necessarily electronic communications.
A good example is the way Toyota managed their supply chain in the 1970's. I would suggest computerized inventory management certainly was the key to making this work, not necessarily EDI...
Cheers
Managers are trained to deal with schedule and budget. Not with designing complex systems.
An organization is a complex human system. Executive management are charged with viewing the big picture and designing a large complex system -- but they can't use an engineering approach, because they're dealing with people, not objects.
It's arguably more complex than engineering for many reasons: you can't guarantee strengths in individuals - you can only observe and take an educated guess, people tend to dislike change and may actively work against any change, plus there are many fuzzy aspects to actually inacting change in an organization due to the complex & mixed nature of an organization's motivation.
The closest thing I can think of is that managing an organization at the executive level is like debugging a concurrent, distributed system with byzantine failures.
This is why good executives are so rare, and why so many companies do a poor job of organization and re-organization.
(One half-baked aside:
I find it amusing that the general solution in computing to byzantine failure -- quorum consensus -- looks amusingly like organizational bureaucracy. Both are woefully ineffecient as size increases, but work to eliminate corruption.)
Lots of eCommerce sites have gone with Dell PowerEdge for the lowered costs... obviously with mixed results, but I'm not so sure the Compaq-only mantra is as true as it once was.
So arguably, if Dell can get a foothold due to lower costs, why can't Apple? (other than IT managers not trusting that "fruit company")
Apple doesn't have a fault-tolerant clustering solution yet, so you'd have to rely on application-specific mechanisms --.e.g Oracle 9i Data Guard for databases (whenever they make a production Oracle release of course).
Can today's business world (which really means "corporations" rather than the entire set of all businesses) survive without face-to-face communications? Yes.
Disagree. While some businesses can survive this, the business world cannot in general because the sheer amount of bandwidth available in a face-to-face vs. email.
Can they survive without electronic communications (including email, EDI, etc.)? No. That makes electronic communications more important.
Disagree, again. I guess it depends on your definition of "business". Certainly big businesses need email and perhaps EDI. Small businesses -- questionable. Depends on industry, on focus, market, etc.
It's quite interesting that many people somehow believe people can't survive without an inherently low-cognitive-bandwidth medium, yet can survive without personal human contact.
Cheers
That's all great, but I really hope you're not suggesting the majority of business communication in the world is accomplished this way. It isn't. It's sort of like saying telephones were the most important mechanism to communicate business before the computer. Important yes, the most important, absolutely not.
Fair enough. I guess it varies. :)
Are low /. numbers supposed to be penis size in the geek world? hmmm. then again, it was this way in the BBS world too.... "dude, you're user #8! whoa!"
i agree the master/servant, customer/consultant relationship with IT groups isn't really useful, but I think you're going overboard at times. For example:
Computing is the single most important method of communication in the business world.
That's daft. The most important communication is what occurs between people face-to-face. And we don't really have a lot of that either, more like a lot of mental masterbation and flinging feces at one another (at least at the last IT executive committee meeting I attended)
regarding cars... i find it fascinating how cars are expensive here especially when WE BUILD MOST OF THEM... especially Hondas, Acuras, Toyotas...
Before commenting, please live in both countries for a number of years, and then spout off.
Been there, 3 years in the U.S. (1 in Cali, 2 in NYC). Back in Toronto.
What I like about Canada? People, culture, media.
What economically sucks about Canada? IT job pay, exchange rate.
Most day-to-day stuff I find is cheaper in Canada *except* cars & geek toys (like computers and electronic equipment) which is KILLED by the u.s. exchange rate. I have to spend over $5k for a new Apple Powerbook compared to $3.3k in the u.s. And I make 15% less than I did in the U.S. (and ONLY 15% because I have a good boss that argued for me).
Cheers
Sure. Then I'll ask: how many users? And I'm not to certain an interviewer at a brokerage or manufacturing company would appreciate "hit reload" as your answer to fault tolerance.
Perhaps you misunderstood my point -- fault tolerance is about tolerating ALL faults - hardware, software, and user errors. How do you handle hardware failure? Do you crash-fail? Or do you continue in partial service mode? etc.
How do you handle software failure? Restart the server? Or do you go to the lengths of Tandem servers and have process-pairs for everything? etc.
So yes, you could put "enterprise software" on your resume, in the same way that anyone that learned QBasic and wrote a tic-tac-toe game could put "game development" on their resume. It still doesn't make you John Carmack.
I thought about including that in point #3 scalable, but I figured it was implicit.
To be scalable assumes that you A) have picked an appropriate response time and B) throughput is a limitation of the physical hardware, not the software.
I would suggest that "responsive" and "fast" are application-specific requirements -- how "fast" is "fast". Also note that response time is only one dimension of performance -- you don't mention throughput.
I can assure you that in most cases, an application's response time and throughput have very little to do with choosing Java as a technology and a lot to do with project management and technical leadership.
I used to teach J2EE to wall street developers, and in particular new college grads. Most have no clue what an enterprise application is, so I came up with a working definition.
Enterprise application is a software system that is:
1. Distributed (with all the requisite problems of distributed computing)
2. Secure (authentication, authorization, auditing, and encryption)
3. Scalable (can handle increasing load without a re-write)
4. Heterogeneous
5. Fault tolerant and/or Recoverable
6. As a corollary to (5), usually involves one or more transactional DBMS
Each of these topics by themselves can take years to master.... which is why people tend to hold well-designed "enterprise applications" in high regard.
I find modern tools to be pretty sufficient. Some of the following features are quite important:
.NET for now), JDK 1.4.1 does this.
- Edit/Continue debugging.... VB used to do this (not in
- Watchpoints (when is something edited?)
- Jumping back stack frames (though you'll have to be careful to manually reset your shared state)
Tracking down bugs requires a certain kind of expertise. Usually it's harder to debug than to write new code, so that could be one reason why debuggers don't proliferate as much as modelling tools.
One way of gaining this expertise is to have experience in teaching other programmers in a hands-on course. You learn to spot common bugs quickly, and diagnose more complex ones. It's in an environment where you have 15+ people that all need your help at once... kinda pushes you towards honing that debugging sense.
In my experience, most "tough" debugging problems would have been solved if the developer just set the breakpoint and analyzed the code instead of sitting on their thumbs and thinking about it for 15 minutes. This might be fine for Kernhigan, Ritchie, Pike, and all those who suggest that "thinking" is the best way, but these guys also have *decades* of experience to do this without assistance. A debugger is a catalyst to this thought process.
Also, logging techniques are crucial, they isolate the location of a potential problem. But they're very time consuming to figure out WHY something is going wrong (because you never quite know what variables to dump out to stdout).
A debugger to seek stack traces & peek inside variables, change variable values, and edit/continue with your changes adds significantly to agility. It's partially why VB was so successful, and Eclipse is so popular in the Java world (and why most Smalltalkers have migrated to Java/Eclipse).
On the contrary: witness Nortel, who pays their Ottawa-based engineers way less than those in North Carolina (which has a similar cost of living, with the reasonable assumption of currency exchange-at-par).
/electronics equipment is generally 1.5x more expensive in Canada due to exchange. My new Powerbook G4 17" laptop is going to be over CAD$6500, what would be (with sales tax) maybe USD$3600 in NYC.
Yet Roth, the CEO, in a widely publicized press statement, blamed the Canadian government's tax system for the brain drain. No, it's stupid pay policies that don't recognize NAFTA creates a "North American Employment Zone" through TN-1 visas. Anyone with a technical degree can jump ship.
(Here's my anecdote. I intend no offense to those unemployed, or affected by the economy, my financial pains are trivial compared to those down and out. I empathize.)
I happen to work in Toronto now at a significant paycut. I make 20% less per paycheck than my last job in NYC as a salaried consultant and trainer. The only reason I took this job is that it was a career move, the people I'm working with and what we're trying to accomplish will be a big resume bonus. But the pay & compensation really wasn't competitive for a senior-level technical lead in software development ("architect", whatever).
I'm still getting compensated significantly above average for a technical position in the area -- because my hiring VP basically gave me "senior manager" level pay, even though I have no subordinates. And she had to fight for that, hard. One quote was: "We don't have engineers, we have programmers." (shudder)
And U.S. computer
That's the general mentality of IT in Canada -- they still believe in paying "managers" more than "performers". A programmer is an interchangable unit of productivity, they never seemed to learn that 10:1 ratio nugget that I believe Capers Jones figured out 20 *YEARS* ago. Seniority and the peter principle rule.
Perhaps some companies are changing. My boss is keeping me satisified with conferences and educational opportunities (a budget she also had to fight for, "WTF do techies need training for?") Thankfully the CIO is on her side.
Wall Street, on the other hand, tends to give enormous compensation packages (even AT PAR, with NYC's cost of living difference) to technical leads that perform.
(std disclaimer, views expressed are mine alone)
I've heard Coopers is a much better brew than Fosters
"The school is there to make money. That's it."
Many colleges and universities have not-for-profit status. They don't exactly have "shareholders" in the traditional sense of a for-profit public corporation.