Mon Oct 8 20:53:44 2001
Is Your IT Staff Giving You the Business?
by Frank Fiore , the Author of e-Marketing Strategies
JUN 15, 2001The online channel should be treated like any other marketing channel; it should be planned, designed, and marketed by businesspeople, leaving the building of the infrastructure to the IT staff. Not the other way around.
This article is provided courtesy of Que.
This article is adapted from e-Marketing Strategies.
On one of my frequent flights across the country a few years ago, having digested the reading material from the seat pocket in front of me, I asked the flight attendant for a magazine and was offered a publication geared to IT professionals. I won't disclose the name of the magazine here, but suffice to say that it proved what my suspicions had been up to at that point: IT staffs have been giving companies "the business."An editorial in the back of the magazine trumpeted the following headline: "Has the CIO Become the New CEO?" The writer argued that since Internet technology has become so complex and requires such a high level of technical expertise, it was time for the CIO to replace the traditional CEO as the leader of a company. It seemed to him that the lowly CEO with a business degree—or a market vision—just couldn't cut it in the new Net Economy. Without the skill set of an IT professional, the CEO could not meet the digital challenges of the new business environment. Thus the CIO, at the top of the food chain of engineers, was the natural choice to run companies competing in today's New Economy.
Where did IT professionals with degrees in computer science and engineering miraculously attain the knowledge of running a business? This is comparable to a construction company building a Wal-Mart and then deciding to go into the completed store to market, sell, procure, and manage the inventory. And this type of mentality is ingrained even down to lowest level of IT workers.
A year or so later, I had a heated discussion with a Webmaster who claimed that he could not only build Web sites for his business clients but also show them how to market their products on the Web, since he "knew" the Internet. After all, what's the big deal in opening a business on the Net? All you need is a Web site, a database-driven catalog, an automated shopping cart, an auto-response email program, and a contact page. And if you really want to impress your visitors, you throw in some really cool animation, Java programs, and streaming media—forgetting what true business types know—build to the customer, not the engineer. You're not in business to entertain customers, but to sell them.
As many dot-coms have become dot-bombs, the curtain has been pulled away to reveal what was true all the time: The emperor—in this case, the IT professional—has no clothes. Many business professionals think that the Internet is a technology solution, when it's really a business strategy. The business of the Internet is business; you can't automatically turn a programmer or computer engineer into a business developer. The online channel should be treated like any other marketing channel—planned, designed, and marketed by businesspeople—leaving the building of the infrastructure to the IT staff. Not the other way around.
Technology Is Not a Solution
Don't get me wrong. I have worked with some great IT professionals on many Internet projects; the best ones know the difference between technology and business. Case in point: On one recent very complex project of creating a dynamic pricing solution for merchants on the Web, my CTO offered me three options to solve one of several business problems that needed to be addressed with the technology. He said, "I have three possible technology solutions to your problem. Each one will work technically. But I need a business decision from you as to which one will work best for your business model."No matter what engineers tell you, technology is not a solution. Technology is just hardware and software—no more, no less. The solution comes from how you apply it. And that takes business savvy. Or, in other words, "It's the customer, stupid!"
You would think that today, after the dot-com collapse, everyone would get it. No so. Many in management from the CEO down still get bedazzled by their IT staff as newer technology applications become available for commerce: wireless applications, peer-to-peer systems, and so on. So what should you and your management personnel know about the Internet to speak intelligently with your IT staff when they come to you with their "solutions"?
To start, keep these rules in mind:
Does it solve a problem or create one?
Your IT staff will present potential solutions to online business problems you ask them to solve. The engineer will most often recommend the one that's easiest to implement and manage; but that might not be the best for your customers or your business. Does the technology application make life easier for your customers and managers? If not, send the engineers back to the drawing board.
Work on your priorities, not theirs.
When the business side of the business creates a program to generate revenue or market a product, and needs a technology application to achieve it, make sure that the engineers don't fight these improvements just because the schedule doesn't work for them. Here's a real-life example. One company I worked with had a state-of-the-art comparison-shopping engine. The marketing department came up with a way to generate revenue for the company by selling sponsorships to merchants, promising that their listings would come up first in the search results. But the engineering department was following their own step-by-step plan for improvement of the technology, and fought hard not to interrupt their process with a request that wasn't on their revision list. Yet, without a revenue-generating program, the company couldn't afford to continue the development of the technology.
Get your business staff to speak the language.
You don't have to have an engineering degree to understand the business uses of the Internet. Prompt your staff to learn to "walk the walk and talk the talk" so that they can communicate better with your IT staff. How? By having them receive a seminar in their email inbox every day. There are literally thousands of email discussion lists on the Net that people can subscribe to and join in the discussion. Many of these discussion lists focus on marketing, advertising, business strategy, sales, procurement, customer service, human resources, operations, and how technology of the Internet is being applied to each. One of the best places to find these email discussion lists is at http://www.topica.com. Encourage your staff to subscribe to a discussion list that matches their part of your business. Even if they just read the daily and weekly posts and don't participate in the discussion, they'll learn from those companies that are using the Internet to further their business objectives.
Be a peacemaker.
I once knew a CEO who talked about his IT staff as if they were ill-mannered relatives that needed to be hidden from everyone outside the family. Just keep the engineers locked in a room and toss a pizza under the door every so often, he said. This is not the attitude to take with your IT staff. They should be involved from the start in the strategy of the project. Make sure that all the engineers working on a project—not just the IT managers—understand the business strategy you're trying to implement and how the engineering applications will tactically achieve it. This would help alleviate the problems in rules 1 and 2 above. Let them know what you want the customer experience to be—not just the objective of the application. It's not enough to have a customer get from point A to point B on your site or on any other Internet application. The engineers have to understand what kind of experience the customer will have while doing it. If it's a bad experience, you may lose a customer for life.
In 1959, C. P. Snow, the British novelist, scientist, and government administrator, wrote The Two Cultures and the Scientific Revolution (Cambridge University Press). In the book, he argues that practitioners of each of the two disciplines—Arts and Sciences—know little, if anything, about the other, and that communication between them is difficult if not impossible. What Snow wrote then has its parallels today between the disciplines of business and technology. Yet, as Internet professionals and pioneers, we need not fall into the same trap. Business types and technology types can learn to work together to serve the most important client of all—the customer.
Too often, the average techie considers business ppl to be total idiots. Never once realizing that while companies are playing in a new sandbox called the Web, they still have to live in the "real world".
A world where intimate knowledge of finance, accounting, tax, marketing, hr and other skills apply far more than J2EE.
While merging both for those that study hard enough is entirely possible, I feel the article does a good job of seperating implementation from design concepts.
M.
Mon Oct 8 21:10:41 2001
That's why I really don't understand Broad Area buisness majors with little knowledge in IT, math, or general Tagnutry, or whatever their industry does.
I've know enough broad area buisness majors out in the "Real world" long enough to know that they have been giving everyone "The business" as well. I wonder why they are the ones making decisions as the typical Buisness major picked his course track almost by default, or because they didn't think they could hack IT, Programming, etc, or they lacked the creative talent for art, design, etc.
So essentially we have some very intellectually unambitious perhaps belonging to the lower intellegence brackets. And they make the decisions?
???????????????????????????????
The guys I'd want to hire would have the Buisness degree, with some sort of minor that is pertainent to what buisness I'm in.
These guys have my respect, nearly all the back-stabbing shmoo's I used to work for have no such regaurds from me.
Madan, you seem to have some management skills mixed with some artsy-l33tness and some solid IT know-how. In my estimation, you are far better off than the normal buisness guy.
Mon Oct 8 21:21:23 2001
Well, the article brought up another point. The Buisness only guy is ill-prepared to run a company as well because he has little testical knowledge, which is important.
"Testical" knowledge?
Freudian slip? :) Muahahahahaha!
That's why I really don't understand Broad Area buisness majors with little knowledge in IT, math, or general Tagnutry, or whatever their industry does.
A. The "real world" need not this.
B. Tax is far more pervasive and important.
C. You don't have to know about your own body to have one run successfully but you DO need an understanding of the outside world. Same with a company.
Although I DO hope biz-tech nerds ARE the future because I'd be perfectly placed for dominance! Muahahahaha!
I've know enough broad area buisness majors out in the "Real world" long enough to know that they have been giving everyone "The business" as well. I wonder why they are the ones making decisions as the typical Buisness major picked his course track almost by default, or because they didn't think they could hack IT, Programming, etc, or they lacked the creative talent for art, design, etc.
I disagree. My sister is a "business major". Accounting. She was valedictorian for her elementary school, high school AND college.
She's *extremely* smart and very business savvy. Moreso, she's an MBA student now.
She could easily study programming and I have no doubt that if she did, she could spank anyone on here.
She's *that* smart.
To say that biz students, for the most-part are washups that can't paint or code is not true.
Most don't *want* to paint or code.
BTW, as a biz student, I can both paint AND code.
To be perfectly frank, I don't think most coders would be so smug if they had to take the CPA exams. Now THAT is nasty. Those tests make the MCSE look like pre-primary!
So essentially we have some very intellectually unambitious perhaps belonging to the lower intellegence brackets. And they make the decisions????????????????????????????????
!!! That's the dumbest generalization I've heard today...
The guys I'd want to hire would have the Buisness degree, with some sort of minor that is pertainent to what buisness I'm in.These guys have my respect, nearly all the back-stabbing shmoo's I used to work for have no such regaurds from me.
Yeah, because IT ppl are sooooo civil. Look at BF. Techies fight over things even MORE trivial than money.
They fight over platforms. Moreso, they're just as vindicitive. Heck, take the emails I received.
That was jus' plain sad.
Mad.
Mon Oct 8 22:22:29 2001
So, yay for business people and their decision-making prowess. Gotta think of the bottom line, haven'tcha guys?
BTW, as a biz student, I can both paint AND code.
The article says:
Where did IT professionals with degrees in computer science and engineering miraculously attain the knowledge of running a business? This is comparable to a construction company building a Wal-Mart and then deciding to go into the completed store to market, sell, procure, and manage the inventory. And this type of mentality is ingrained even down to lowest level of IT workers.
When the business side of the business creates a program to generate revenue or market a product, and needs a technology application to achieve it, make sure that the engineers don't fight these improvements just because the schedule doesn't work for them. Here's a real-life example. One company I worked with had a state-of-the-art comparison-shopping engine. The marketing department came up with a way to generate revenue for the company by selling sponsorships to merchants, promising that their listings would come up first in the search results. But the engineering department was following their own step-by-step plan for improvement of the technology, and fought hard not to interrupt their process with a request that wasn't on their revision list. Yet, without a revenue-generating program, the company couldn't afford to continue the development of the technology.
This goes about it completely bass-ackwards anyway. Why not, maybe, decide what you want the thing to do, and how you're going to do it before you write it? Oftentimes, the engineers' priorities have to come first, because the thing simply won't work (or will need to be redone from scratch, or whatever) if they just listen to your priorities.
'cos this "tip" seems to be saying to do this:
<suits> Make a program that does X, Y, Z.
<geeks> That will take W weeks.
-- 0.95 W weeks pass --
<suits> No, stop all that, we've had a a change in direction. Make it do A, B, and C first -- and your deadline stays the same.
<geeks> But we have to finish off what we've done so far first.
<suits> No, don't do that, the tip says not to.
<geeks> ...
<geeks> But it won't work if we don't...
<suits> I don't care. My priorities, not yours.
<geeks> We quit
<suits> ...
<suits> ;_;
Which strikes me as dumb.
or perhaps:
<suits> Make a program that does A, B, and C.
<geeks> That will take V weeks (where V > W).
<geeks> After W weeks, it will do X, Y, and Z. After an additional (V - W) weeks, it will do A, B, and C first.
<suits> But I don't want X, Y, or Z. I want A, B, and C. And I want it in W weeks.
<geeks> Not gonna work like that. A, B, and C require X, Y, and Z, and X, Y, and Z will take W weeks.
<suits> But... but... my priorities, not yours!
The people doing the work don't say these things just for fun; they normally say them because they're true. If they could cut corners and just make it do what you want magically, they'd do it -- it'd save them a lot of work.
But if they're saying, "We need to do this stuff even though it's not the stuff you want" then you should listen to them, because they're quite likely telling you the truth.
Mon Oct 8 23:33:33 2001
It's business people who are responsible for hiring non-techie MCSEs for the sole reason that they're cheap, who then let their machines get exploited by [insert worm du jour here] every single time.
Please. MCSEs mean NOTHING.
MCSE is a piece of paper that indicates that you can cram for a test.
My old admin at the Univ. knew his stuff backwards, forwards and sideways and he didn't have an MCSE.
OTOH, I've known several DOZEN MCPs and MCSEs(IIS to boot) that couldn't find their way out of a paper bag.
Quote: BTW, as a biz student, I can both paint AND code.
I don't know about painting, but no, I don't think you can code. I don't mean this offensively... I don't think you have the interest in the subject. You might think "I could do it if I had to", but that isn't the same thing at all. I *could* take some godforsaken business (or accounting, or whatever) degree _if_I_had_to_, but I'd sooner work in McDonald's than do such a thing.
Wrong. I want to learn how to code. In an attempt to educate myself, I've been working as fast as I can, through as many texts as I can.
So far, in the last month, I've moved through:
1 HTML 4.1 book.
1 Mac OS 9 book.
AND I'm currently reading my way through three texts:
1 networking book. 1 hardware book. 1 SQL 6.5(we have 7 at work) book.
After that, I have a book on PS that I'd like to take a look at. One on VBS. Two on ASP. Two on ColdFusion and 2 on Java.
They're sitting on my desk and I'm reading as fast as I can.
I just am *not* a coder.
It's not that I can't do it. It's that I can't do it well.
BTW, no, I have NOT chosen a web platform yet. I *want* to learn Java but I *need* to learn ASP.
Personally, if I could, I'd drop both and just go wi CFML/Jscript but I can't get a server to run at home to practice on, so whatever....
The article says:Quote: Where did IT professionals with degrees in computer science and engineering miraculously attain the knowledge of running a business? This is comparable to a construction company building a Wal-Mart and then deciding to go into the completed store to market, sell, procure, and manage the inventory. And this type of mentality is ingrained even down to lowest level of IT workers.
Beats me. But it's worked well for Bill Gates, Paul Allen, Michael Dell, and many others (for instance, the likes of Richard Branson, for a non-computing example). So it can't be all pie in the sky, can it?
Bill Gates has never been the businessman of his company. He's a figurehead in that respect. Now, he's not even that. Dell was studying bus and tech before he left school...
Quote: When the business side of the business creates a program to generate revenue or market a product, and needs a technology application to achieve it, make sure that the engineers don't fight these improvements just because the schedule doesn't work for them. Here's a real-life example. One company I worked with had a state-of-the-art comparison-shopping engine. The marketing department came up with a way to generate revenue for the company by selling sponsorships to merchants, promising that their listings would come up first in the search results. But the engineering department was following their own step-by-step plan for improvement of the technology, and fought hard not to interrupt their process with a request that wasn't on their revision list. Yet, without a revenue-generating program, the company couldn't afford to continue the development of the technology.
Ah, yes, the time-honoured "moving goalposts", a management favourite.This goes about it completely bass-ackwards anyway. Why not, maybe, decide what you want the thing to do, and how you're going to do it before you write it?
That's what he's saying. But often times, deciding what your application must do eclipses why the application is built in the first place(much less who it's for..)
Oftentimes, the engineers' priorities have to come first, because the thing simply won't work (or will need to be redone from scratch, or whatever) if they just listen to your priorities.
"My priorities"?
A. The app. is built to serve a purpose. If it doesn't or doesn't adequately fulfill the needs of the end-user, the app is useless, no matter *how* excellently or specifically it was coded.
I don't believe a "moving target" is a valid example. "Evolution in development" is far more accurate.
The db admin we had was a prime example of a "techie" that refused to listen to the end-user and, as a result, it's taken me a *very* hard year-long crash course in SQL 7/TSQL in order to clean up his mistakes.
That shouldn't happen.
'cos this "tip" seems to be saying to do this:
<suits> Make a program that does X, Y, Z.
<geeks> That will take W weeks.
-- 0.95 W weeks pass --
<suits> No, stop all that, we've had a a change in direction. Make it do A, B, and C first -- and your deadline stays the same.
<geeks> But we have to finish off what we've done so far first.
<suits> No, don't do that, the tip says not to.
<geeks> ...
<geeks> But it won't work if we don't...
<suits> I don't care. My priorities, not yours.
<geeks> We quit
<suits> ...
<suits> ;_;
That's not what he's saying. From the article, he emphatically states that "geeks" should be in on the design phase. Geeks must be acquainted with the business process. Who is guiding them through the process? The end-users and the suits.
Often, the problem is that the "suits" don't provide specific directions on how the system/app should behave.
And often, the geeks get so swept up in a function, that they never bother to stop and think "gee, the end-user" isn't going to be happy that you can't get out of this screen without doing x,y,z..."
The people doing the work don't say these things just for fun; they normally say them because they're true. If they could cut corners and just make it do what you want magically, they'd do it -- it'd save them a lot of work.
I agree. However, I also agree that techies pull a Montgomery Scott every single time.
<suits> We need an app that will do A, B, C
<geeks>..ooOO(that should take NO new hardware and 6 weeks of work)
<geeks> We need the new SQL 7 server for that and 10 weeks to set it up...
<suits> Really? Uhm.....ok...I guess....
That's a fact because I've SEEN it happen. You can imagine how popular I was when I stopped the network guy in front of the suit and told him that wasn't "necessarily true"....
:/
But if they're saying, "We need to do this stuff even though it's not the stuff you want" then you should listen to them, because they're quite likely telling you the truth.
It depends on the relationship and person.
It also depends on the culture of the company.
It just depends.
M.
Mon Oct 8 23:49:18 2001
'cos this "tip" seems to be saying to do this:
<suits> Make a program that does X, Y, Z.
<geeks> That will take W weeks.
-- 0.95 W weeks pass --
<suits> No, stop all that, we've had a a change in direction. Make it do A, B, and C first -- and your deadline stays the same.
<geeks> But we have to finish off what we've done so far first.
<suits> No, don't do that, the tip says not to.
<geeks> ...
<geeks> But it won't work if we don't...
<suits> I don't care. My priorities, not yours.
<geeks> We quit
<suits> ...
<suits> ;_;Which strikes me as dumb.
or perhaps:
<suits> Make a program that does A, B, and C.
<geeks> That will take V weeks (where V > W).
<geeks> After W weeks, it will do X, Y, and Z. After an additional (V - W) weeks, it will do A, B, and C first.
<suits> But I don't want X, Y, or Z. I want A, B, and C. And I want it in W weeks.
<geeks> Not gonna work like that. A, B, and C require X, Y, and Z, and X, Y, and Z will take W weeks.
<suits> But... but... my priorities, not yours!
This happens far too often. This the reality of people that don't understand X, telling people that are doing X, what they need to do to get X done.
This is my argument against broad area people who don't have, nor particularily care to gain knowlegde about what the requirements of X are.
Tue Oct 9 00:13:01 2001
from Madan posted at 12:33 am on Oct. 9, 2001
Please. MCSEs mean NOTHING.
That doesn't prevent people from hiring on that basis (and, given the appalling job that these people do, that basis alone).
MCSE is a piece of paper that indicates that you can cram for a test.
My old admin at the Univ. knew his stuff backwards, forwards and sideways and he didn't have an MCSE.
It is BUSINESS PEOPLE that make the hiring decisions, and it is BUSINESS PEOPLE that hire incompetents, on the basis of their worthless paper qualifications.
OTOH, I've known several DOZEN MCPs and MCSEs(IIS to boot) that couldn't find their way out of a paper bag.
Wrong. I want to learn how to code. In an attempt to educate myself, I've been working as fast as I can, through as many texts as I can.
So far, in the last month, I've moved through:
1 HTML 4.1 book.
1 Mac OS 9 book.
AND I'm currently reading my way through three texts:
1 networking book. 1 hardware book. 1 SQL 6.5(we have 7 at work) book.
After that, I have a book on PS that I'd like to take a look at. One on VBS. Two on ASP. Two on ColdFusion and 2 on Java.
They're sitting on my desk and I'm reading as fast as I can.
I just am *not* a coder.
It's not that I can't do it. It's that I can't do it well.
BTW, no, I have NOT chosen a web platform yet. I *want* to learn Java but I *need* to learn ASP.
It doesn't matter /that/ much /what/ you're using; as long as you're doing it rather than just reading about it.
Personally, if I could, I'd drop both and just go wi CFML/Jscript but I can't get a server to run at home to practice on, so whatever....
Bill Gates has never been the businessman of his company.
He's a figurehead in that respect. Now, he's not even that.
Dell was studying bus and tech before he left school...
That's what he's saying. But often times, deciding what your application must do eclipses why the application is built in the first place(much less who it's for..)
A. The app. is built to serve a purpose. If it doesn't or doesn't adequately fulfill the needs of the end-user, the app is useless, no matter *how* excellently or specifically it was coded.
I don't believe a "moving target" is a valid example. "Evolution in development" is far more accurate.
The db admin we had was a prime example of a "techie" that refused to listen to the end-user and, as a result, it's taken me a *very* hard year-long crash course in SQL 7/TSQL in order to clean up his mistakes.
That shouldn't happen.
That's not what he's saying. From the article, he emphatically states that "geeks" should be in on the design phase.
If the suits want the geeks to not bother doing some bit just because they see it as irrelevent but which is actually fundamental to the workings of the application, the geeks' immediate priority -- getting the work done -- is more important.
You say that if it doesn't do something anyone wants then it's useless -- but equally, if it doesn't do anything at all, it's also useless.
Geeks must be acquainted with the business process. Who is guiding them through the process? The end-users and the suits.
The suits should know, from the users (or potential users) what they want. They should know who they're targetting, what they want to do for them, and why. Before the geeks are even brought into the question -- the idea for the application, its purpose, has to be known.
Until that's done, you're wasting your time.
And end-users don't know shit about the business process. They know only about what they want the program to do, and how they want to do it. There will probably be diversity in this, and someone will have to distill their desires into something that you can implement in a finite timeframe. That needs someone (or some people) who know about what's technically practical, but if you have too big a team thrashing out the issue, you'll end up with the same problem once again -- a lack of convergence in ideas.
Often, the problem is that the "suits" don't provide specific directions on how the system/app should behave.And often, the geeks get so swept up in a function, that they never bother to stop and think "gee, the end-user" isn't going to be happy that you can't get out of this screen without doing x,y,z..."
Fixing the UI is a relatively minor task once you've got a working application (as long as the application was technically well-designed in the first place).
I agree. However, I also agree that techies pull a Montgomery Scott every single time.
I'd prefer that to a Geordi La Forge. Underestimate the time and cut corners so that you just manage to finish in time. It makes problems later down the line (when it comes to maintenance) and it causes problems when you discover that there simply aren't any corners to cut.
That's a fact because I've SEEN it happen. You can imagine how popular I was when I stopped the network guy in front of the suit and told him that wasn't "necessarily true"....
It depends on the relationship and person.It also depends on the culture of the company.
It just depends.
Tue Oct 9 01:23:56 2001
I think business people do a better job of managing IT companies than tech people do. The problem is that they can make little oversights that end up biting them in the ass later on. Ideally you would have a business expert in charge, who would have good technical VP's who advised him well.
I don't think there are many people who are exceedingly strong in both areas. Even if you have a good technical background, not being "in the trenches" so to speak, on a daily basis makes them loose their edge.
Tue Oct 9 02:22:10 2001
from DuffMan posted at 2:23 am on Oct. 9, 2001
Well MCSE's don't really mean nothing. You could say the same thing about college degrees. They both just show that according to a certain standard you're an expert in something. Lack of experience, lack of interpersonal skills, lack of troubleshooting skills, and lack of just plain common sense can make these people completely useless in the "real world". But I wouldn't say that they mean nothing.
Tue Oct 9 02:31:59 2001
"Expert" is a relative term. There are many people who graduate college with no practical skill in their major. There are limitations on any form of assesment. I would say that the majority of people who pass the exams are qualified to be admins. There's always going to be people who take a class, and brute force their way to a cert. It doesn't mean they're worthless.
/me goes back to studying MCSE stuff
Tue Oct 9 13:37:06 2001
from Madan posted at 1:33 am on Oct. 9, 2001
So far, in the last month, I've moved through:1 HTML 4.1 book.
1 Mac OS 9 book.
You're a slow reader, eh?
AND I'm currently reading my way through three texts:1 networking book. 1 hardware book. 1 SQL 6.5(we have 7 at work) book.
I'm reading two very funny books by Terry Pratchett.
Just bought 'em today. I expect to be finished next week.
Tue Oct 9 21:00:50 2001
Yep. But as long as business types require it as a qualification (and they're the ones that make these decisions) it's gonna continue to be a worthless test.
Newsflash. Biz ppl wouldn't consider the MCSE a big deal if bs techies and their respective companies weren't trying to pass the MCSE as required... Especially seeing as most biz ppl are relying on techies to keep them informed.
You want to blame ppl for the MCSE? Blame MS. CNE? Blame Cisco. Don't blame the biz personnel that don't know any better.
Congratulations, Madan, you've done a fine job of missing the patently obvious point I was making.
:rolleyes:
Well, things to be reciprocative because you totally missed *my* point, which was simple:
Techies ESTABLISHED such controls.
Um. Fuck "working through texts". What *coding* are you doing. And no, HTML doesn't count.
VBS and Java(trying) for now.
Quote: AND I'm currently reading my way through three texts:
1 networking book. 1 hardware book. 1 SQL 6.5(we have 7 at work) book.This has what to do with coding?
A knowledge of such subjects are basics that a good programmer should be aware of.
Or do you think that networking, hardware and other basics are something a programmer doesn't need to know about?
Then why did YOU learn it?
That's cute. So you'll be a well-read non-coder.Less reading, more coding, Madan.
That's funny, because I thought I have to read about it FIRST before I can try it. Y'see, if I knew the material, I wouldn't be reading a book on it, would I?
:rolleyes:
* Madan's Point * Peter---> missing
And...?
And ASP sucks. It's almost as hard as Java and not nearly as powerful.....
CFML is *much* easier and take tens of lines of code less...
This is why you're not a coder, and not of the coding mentality.
No, that's why I'm an IT person. Because I'd rather get results quickly than spend my time dicking wi some code to get the same effect.
Quote: Bill Gates has never been the businessman of his company.
Yes, he was.
Uhm, no he wasn't. Read any of his bios and you'll see that he provided the leadership for where to take the Win platform. He dealt very little with operations and the actual *managing* of the company. Now, he doesn't even SEE such reports...
But he left school and decided to actually do something (and something practical, at that).
Not before he spent some time there. He saw an opportunity.
I love the way you're trying to pass college off as a waste of time.
I suppose Amazon's CEO(a "spic" btw) and Coca Cola's(ditto) and AOLs' degrees...they're not worth anything either.
Then the "deciding what your application must do" has been done wrong. Filling a particular need (i.e. why it's built and who for) has to be one of the design criteria -- an application might be built differently depending on the target, for instance.
Yes, very good. Keep repeating my comments.
And if you don't let the engineers do the things that they have to do so that it can serve your purpose, then there is no application at all (useful, useless, or otherwise).
"Doing" things has limits. Buying needless hardware, taking excessive time or obsessing over little things is dangerous, time-consuming and costly.
Quote: I don't believe a "moving target" is a valid example. "Evolution in development" is far more accurate.
Each time you change the specification of the project it will cause a problem.
Nice try putting words in my mouth. :)
Specification, as in, purpose and general functions DON'T change. Features and modes of functions should.
The later down the line you make a change, the longer it will take to rectify (though time and cost can be traded off against one another to a certain extent). If there are certain bits of a project that need completing before it can progress further, management have to simply suck it down.
True, if the core of the design is off. That's not what I'm implying. I'm implying evolving the design because NO amount of design will *ever* catch all the inherent problems in a project, nor will they catch all the pitfalls or design-based disagreements. Simply sticking with a design, even if you find out parts are wrong is closed-minded and creates a system that the end-user will avoid.
Then the ONLY winners are the programers. They get paid and everyone else is stuck with a system *they* decided would work a certain way.
The key is to balance the two. To allow coders into the design phase and to include them in the JAD discussions with the end-users. To familiarize them with the process the end-users use and *then* to design a detailed plan that will be revised before implementation or building begins.
However, coders should *always* understand that minor changes are part of the job and that while the purpose and functions of the task shouldn't change, parts must be adapted as time goes on.
To do otherwise is to basically become a slave to a system. To waste your time including coders in order to have them bite you on the ass.
I've personally been on both ends. Neither tastes particularly better than the other.
If you want to fool yourself into thinking that coders inherently have a better clue about the project than the end-users or biz ppl do. Be my guest. But you're wrong. It takes all groups working together to get the job done...properly.
Quote: The db admin we had was a prime example of a "techie" that refused to listen to the end-user and, as a result, it's taken me a *very* hard year-long crash course in SQL 7/TSQL in order to clean up his mistakes.Techies shouldn't be listening to users. They should be listening to project managers and they to suits.
Wrong.
End-users *should* talk to the developers. Especially in a meeting built and hosted by the "suits". This will give developers an excellent insight into features or functions that might have been missed by the interviews the "suits" had wi them.
If they listened to every single user they would get /nothing/ done. There needs to be a distillation of input between users and the techies, unless you can let your project remain unfinished indefinitely.
No. You're there to work for the suits and you're building objects for the end-user. If you don't like that, get a new job.
That's the way the system works. You're not there to exercise your leet coding expertise. Noone gives a damn about that. They want a system they can use.
While some goals and features have to be omitted by the coders, a good IT "biz" person will eliminate such tasks for the developer already.
The purpose of talking to the end-user(in the presence of the biz) is in order to expose hidden problems and to nail down procedure.
If the techie was directly told to do X, Y, and Z, and didn't, why did the company continue to employ him?
He did do X, Y, Z but he did so in a fashion that was unusable to the end-user.
He put a database together that did include the fields provided but made them very difficult to cross-query.
The point? A waste of time by an ego-centric db admin that, I shouldn't have to mention, is no longer employed by us...
Quote: That's not what he's saying. From the article, he emphatically states that "geeks" should be in on the design phase.But then he says it must meet the suits' aims, not the geeks'.
Precisely. Geeks should do what they can and explain it to the biz ppl. The process necessary. A good biz person will listen. A bad one won't.
Just like good devs will listen to the end-user's needs and bad devs will build the app however the hell they feel like it....
If the suits want the geeks to not bother doing some bit just because they see it as irrelevent but which is actually fundamental to the workings of the application, the geeks' immediate priority -- getting the work done -- is more important.
...
Or times when coders exagerrate the importance of something to buy them time?
I've seen both happen.
Give us an example where you aren't jumping to stereotypical conclusions...
I'm not inclined to agree.
And that's why you have problems with "suits". They're your boss. Oh sure, you tell them what you need and a good "suit" will listen but you, and I don't mean this in a bad way, seem very "high maintenance".
Biz ppl hate coders that presume they're there for show. Most ppl on OSY wouldn't know how to write their names on a complete incorporated tax form and yet coders have this conception that "it's my way or the highway".
They're paying you. If you don't like the terms...leave. There are PLENTY of tech ppl around.
The suits should know, from the users (or potential users) what they want. They should know who they're targetting, what they want to do for them, and why.
I agree. In my experience, they do. A good IT person does, anyways.
Before the geeks are even brought into the question -- the idea for the application, its purpose, has to be known.
I never disputed this. Again, someone good at their job does this.
You're simply inferring that, collectively, they don't.
Until that's done, you're wasting your time.
Agreed.
And end-users don't know shit about the business process.
You're wrong. They know more about the business process than ANYONE. It's geeks that come in and don't know the foggiest thing about business.
Example:
We wanted to build a new web-based system for the HeraldStore to take orders for backissues, merchandise and photos online.
Who knows how backissues orders are taken? The geeks? No, the users.
Who knows tax is applied over districts? Geeks? No. Users.
Who knows how copyright functions or how personalized items are allowed for SOME products but not others or how certain photos can't be reprinted or how some orders must be double-entry or how the process of entering the order unfolds?
Geeks?
No.
Users.
Unfortunately, we had one guy that REFUSED to listen. He had the attitude: "I'm a db admin badass and you're all minimum wage-knownothings". The result was a system that I had to try and operate with, when they hired me later on....
The process was done totally out of order. A total waste of money.
In the end, he didn't even get fully paid. Why? He refused to make changes(couldn't because he didn't listen to what the process needed to be like)....
Quote: Often, the problem is that the "suits" don't provide specific directions on how the system/app should behave.And often, the geeks get so swept up in a function, that they never bother to stop and think "gee, the end-user" isn't going to be happy that you can't get out of this screen without doing x,y,z..."
'cos if they're told "make something that does X" that's all they're gonna do (though the interface shouldn't be a big deal to change; if the application is done properly, you should be reasonably free to rip the front-end off and replace it). If they don't know how the thing is expected to work, they're not going to waste time worrying about stuff that they haven't been told. They'll finish it and move on.
Which is why speaking to the end-users can be so hazard-preventative....
Fixing the UI is a relatively minor task once you've got a working application (as long as the application was technically well-designed in the first place).
Going back in a process is not UI.
The VB code built by the admin couldn't go back once something had been entered. Imagine that. Great common sense. A user mistypes something and can't correct himself because the code won't allow you to move back up the process.
Waste.
Quote: I agree. However, I also agree that techies pull a Montgomery Scott every single time.Overestimate the required time and finish weeks before your deadline every time?
Always happens. How much time do you need for so and so?
Double the time and that's what you get.
When I made a change on the site to the ASP, my boss a "suit" actually emailed me and told me "wow, don't be so efficient" we might actually start using you more"....
That's sad. It's my JOB. He'd been lied to so often, he was unaware of how developments can really be quick...
Out of idle curiosity, how did you /know/ that it wasn't true?
Funny you should mention it.
Win2k. YOU told me requires no additions of hardware to fit it into a network.
Are you and OSY changing your minds now?
The culture of the company seems to be a function of management, as geeks are much the same the world over.
True.
Then again, MOST geeks tend to be snobbish. Which is quite sad.
Riso
Commander
--------------------------------------------------------------------------------Quote: from Madan posted at 1:33 am on Oct. 9, 2001
So far, in the last month, I've moved through:
1 HTML 4.1 book.
1 Mac OS 9 book.You're a slow reader, eh?
You're such an ass.
Seriously.
Firstly, I work two jobs.
Secondly, I have 2-3 hrs a day free to myself, tops.
Thirdly, I started in HTML because I needed the brush up on 4.1 and XHTML.
Fourthly, I wanted some review on MacOS 9 because I use the Mac everyday and I needed my brushup on AppleScript
Fifthly, as a web dev, HTML is the basics of my career...
Sixthly, the HTML book alone was over 1000 pages(sybex) and was probably bigger than your under-developed bicep.
And finally, did you forget that I'm working through another three books? Each over 700 pgs? Gee, sounds pretty good for a guy that has 2hrs free a day.
:rolleyes:
M.
Wed Oct 10 02:05:54 2001
from Madan posted at 10:00 pm on Oct. 9, 2001Newsflash. Biz ppl wouldn't consider the MCSE a big deal if bs techies and their respective companies weren't trying to pass the MCSE as required... Especially seeing as most biz ppl are relying on techies to keep them informed.
You want to blame ppl for the MCSE? Blame MS. CNE? Blame Cisco. Don't blame the biz personnel that don't know any better.
Well, things to be reciprocative because you totally missed *my* point, which was simple:Techies ESTABLISHED such controls.
A knowledge of such subjects are basics that a good programmer should be aware of.
Or do you think that networking, hardware and other basics are something a programmer doesn't need to know about?
Networking? It rather depends what you want to do. Want to write an IP stack or devise a new protocol? Then I'm sure it's important to know about networking in extensive detail. Want to write a web server? Well, you have to know how to listen to and communicate with sockets, that's about it. Want to write a word processor? Don't need to know a thing. Want to write a front-end to a database? Ditto.
Oftentimes a good programmer doesn't need to know anything of the sort.
Then why did YOU learn it?
That's funny, because I thought I have to read about it FIRST before I can try it. Y'see, if I knew the material, I wouldn't be reading a book on it, would I?
There's the question of familiarity with the language's libraries (C++'s STL, or Java's java.*, or .NET's System.* or Delphi's VCL), but familiarity is best achieved through experience, not reading a book.
* Madan's Point * Peter---> missing
And ASP sucks. It's almost as hard as Java and not nearly as powerful.....
CFML is *much* easier and take tens of lines of code less...
No, that's why I'm an IT person. Because I'd rather get results quickly than spend my time dicking wi some code to get the same effect.
Uhm, no he wasn't. Read any of his bios and you'll see that he provided the leadership for where to take the Win platform. He dealt very little with operations and the actual *managing* of the company. Now, he doesn't even SEE such reports...
Not before he spent some time there. He saw an opportunity.I love the way you're trying to pass college off as a waste of time.
I suppose Amazon's CEO(a "spic" btw) and Coca Cola's(ditto) and AOLs' degrees...they're not worth anything either.
Yes, very good. Keep repeating my comments.
"Doing" things has limits. Buying needless hardware, taking excessive time or obsessing over little things is dangerous, time-consuming and costly.
Maybe a bit more obsessing was in order.
Nice try putting words in my mouth. :)Specification, as in, purpose and general functions DON'T change. Features and modes of functions should.
Specifications very regularly *do* change. The example in the article you quoted -- the comparitive pricing engine -- is an example of the specification being changed after the fact. If the business people wanted to be able to let people buy prominent positions in the listings, they should have specified that ability from day 1. Not some time down the line once the project was started.
True, if the core of the design is off. That's not what I'm implying. I'm implying evolving the design because NO amount of design will *ever* catch all the inherent problems in a project, nor will they catch all the pitfalls or design-based disagreements. Simply sticking with a design, even if you find out parts are wrong is closed-minded and creates a system that the end-user will avoid.
Then the ONLY winners are the programers. They get paid and everyone else is stuck with a system *they* decided would work a certain way.
The key is to balance the two. To allow coders into the design phase and to include them in the JAD discussions with the end-users. To familiarize them with the process the end-users use and *then* to design a detailed plan that will be revised before implementation or building begins.
However, coders should *always* understand that minor changes are part of the job and that while the purpose and functions of the task shouldn't change, parts must be adapted as time goes on.
To do otherwise is to basically become a slave to a system. To waste your time including coders in order to have them bite you on the ass.
If you want to fool yourself into thinking that coders inherently have a better clue about the project than the end-users or biz ppl do. Be my guest. But you're wrong. It takes all groups working together to get the job done...properly.
Wrong.
End-users *should* talk to the developers. Especially in a meeting built and hosted by the "suits". This will give developers an excellent insight into features or functions that might have been missed by the interviews the "suits" had wi them.
No. You're there to work for the suits and you're building objects for the end-user. If you don't like that, get a new job.
That's the way the system works. You're not there to exercise your leet coding expertise. Noone gives a damn about that. They want a system they can use.
While some goals and features have to be omitted by the coders, a good IT "biz" person will eliminate such tasks for the developer already.
The purpose of talking to the end-user(in the presence of the biz) is in order to expose hidden problems and to nail down procedure.
He did do X, Y, Z but he did so in a fashion that was unusable to the end-user.
He put a database together that did include the fields provided but made them very difficult to cross-query.
The point? A waste of time by an ego-centric db admin that, I shouldn't have to mention, is no longer employed by us...
Precisely. Geeks should do what they can and explain it to the biz ppl. The process necessary. A good biz person will listen. A bad one won't.Just like good devs will listen to the end-user's needs and bad devs will build the app however the hell they feel like it....
Or times when coders exagerrate the importance of something to buy them time?I've seen both happen.
Give us an example where you aren't jumping to stereotypical conclusions...
And that's why you have problems with "suits". They're your boss. Oh sure, you tell them what you need and a good "suit" will listen but you, and I don't mean this in a bad way, seem very "high maintenance".Biz ppl hate coders that presume they're there for show. Most ppl on OSY wouldn't know how to write their names on a complete incorporated tax form and yet coders have this conception that "it's my way or the highway".
They're paying you. If you don't like the terms...leave. There are PLENTY of tech ppl around.
You're wrong. They know more about the business process than ANYONE. It's geeks that come in and don't know the foggiest thing about business.
What do you know about the inner workings of Amazon, or Wal-Mart, or Apple, or Microsoft, or Ford, or GEC, or Boeing, or whatever?
You don't know a damn thing about them. And you don't need to know, either.
Example:
We wanted to build a new web-based system for the HeraldStore to take orders for backissues, merchandise and photos online.
Who knows how backissues orders are taken? The geeks? No, the users.
Really?
So the people who want to buy these back-issues know how they're going to do that?
Well, I'd guess it'd go along the lines of "contact the publication, ask them for X copies of issue Y, pay them, receive goods" -- but evidently, as a coder, I'm wrong. How, out of interest, does the process work?
(that's been how it's worked for me in the past, mind you, but I must have been using a mechanism designed by geeks, or something, apparently)
Who knows tax is applied over districts? Geeks? No. Users.
I dunno, I rather figured that expecting people who visit a site to know the vagaries of tax legislation to be a little optimistic. I know for a fact it doesn't work adequately over here, and that explanations of who has to pay VAT and why have to be given on the website (to explain to those businesses VAT registered in other European countries didn't have to pay VAT, or however it is the system works).
End users don't know about the business process, and shouldn't have to.
Who knows how copyright functions or how personalized items are allowed for SOME products but not others or how certain photos can't be reprinted or how some orders must be double-entry or how the process of entering the order unfolds?Geeks?
No.
Users.
You're smoking crack.
The end users don't know a damn thing about such issues. They just expect to be able to visit a web site and buy whatever it is they want. Or double click your program and be able to type, or whatever it is they want to do.
Unfortunately, we had one guy that REFUSED to listen. He had the attitude: "I'm a db admin badass and you're all minimum wage-knownothings". The result was a system that I had to try and operate with, when they hired me later on....The process was done totally out of order. A total waste of money.
In the end, he didn't even get fully paid. Why? He refused to make changes(couldn't because he didn't listen to what the process needed to be like)....
Which is why speaking to the end-users can be so hazard-preventative....
Going back in a process is not UI.The VB code built by the admin couldn't go back once something had been entered. Imagine that. Great common sense. A user mistypes something and can't correct himself because the code won't allow you to move back up the process.
Waste.
Always happens. How much time do you need for so and so?Double the time and that's what you get.
When I made a change on the site to the ASP, my boss a "suit" actually emailed me and told me "wow, don't be so efficient" we might actually start using you more"....
That's sad. It's my JOB. He'd been lied to so often, he was unaware of how developments can really be quick...
Funny you should mention it.Win2k. YOU told me requires no additions of hardware to fit it into a network.
Are you and OSY changing your minds now?
Then again, MOST geeks tend to be snobbish. Which is quite sad.
Wed Oct 10 10:26:16 2001
You're such an ass.
I know :biggrin:
Seriously.
:manygrin:
Sixthly, the HTML book alone was over 1000 pages(sybex) and was probably bigger than your under-developed bicep.
It surely was bigger than your biceps.
:biggrin: :asshole: :biggrin:
Wed Oct 10 21:56:43 2001
News flash: genuine technical people do not give weight to the MCSE, as they're aware of its many failings.
ERRRRNT! Bill Gates was the original "founder" of the MCSE and he, by your admission, is a "geek"....
Nope. MS devise a qualification. If people stopped thinking it to be valuable, they would change it so that it was perceived as worthwhile. Genuine technical people don't see it as worthwhile.
Nope. If ppl know why it isn't worthwhile, then they'd be able to stop demanding it. Unfortunately, techies hoard information like squirrels in winter and the average person neither has the time nor the aptitude to learn a "foreign language" like networking.
It's called division of labor. The same reason why you don't give yourself a root canal or defend yourself in court.
Just like you don't have to be an expert in law or tax, lawyers and actuaries don't have to be experts in tech.
Quote: Well, things to be reciprocative because you totally missed *my* point, which was simple:Techies ESTABLISHED such controls.
If by "controls" you mean "qualifications", no, it doesn't appear that they did. Hence the low regard the MCSE is held in.
Covered.
Quote: A knowledge of such subjects are basics that a good programmer should be aware of.
Or do you think that networking, hardware and other basics are something a programmer doesn't need to know about?Hardware is regularly irrelevent. Unless you're writing drivers or something, all you need to know is that you have persistent storage (i.e. a disk), you have working memory (i.e. RAM), you have user I/O (i.e. a screen/keyboard/mouse), and you have a processor. There's a large number of programmers that are ignorant of anything more than that, because they don't need to know.
Ignorant <> Me.
A good programmer will endeavor to know.
Networking? It rather depends what you want to do. Want to write an IP stack or devise a new protocol? Then I'm sure it's important to know about networking in extensive detail. Want to write a web server? Well, you have to know how to listen to and communicate with sockets, that's about it. Want to write a word processor? Don't need to know a thing. Want to write a front-end to a database? Ditto.
Web? No DB? Of course you need it. No networking? Of course you need it.
Tell me again why I *don't* need it?
You aren't [apparently] learning any quirky (non-imperative) languages. Once you're familiar with procedural and OO programming concepts,
I'm not.
the rest is just a matter of syntax. The ideas are the same between Java, C++, newer versions of VB, C#, Delphi, whatever. The way you express the ideas might be a bit different -- if(...) { ... } as opposed to If ... Then ... End If -- but the mechanics remain the same.
See above.
That's a nonsensical statement, for a start. ASP is a set of classes. And whilst Java's class library is broader, it's not as good at the things that ASP's classes do. If you mean Java-the-language, there is no ASP language, so they're not comparable. If you're comparing it to JScript, their syntax is near-identical, because they both have C-family syntax (though JScript is much looser).
Java <> Javascript.
I'm talking about the Java platform vs. ASP.
Quote: CFML is *much* easier and take tens of lines of code less...
It's also *much* less capable.
Not anymore.
CF 5.0 integrates new Java libraries that are easy AND powerful. Pick it up sometime. You'll hate it....
Which of course means the average person will LOVE it.
Uhhh. You know MS was around for maybe five years before Windows? He didn't just sit around twiddling his thumbs during that time.
Before Windows, MS was developing different apps and working towards other OSes that eventually transfigured into 3.1. Gates was a "leader" but a technical one.
He is not a business man. He couldn't draft a resource acquired statement or compound income statement if his life depended on it. Oh sure, he could take classes, but that's not the point. It's not that he could learn how to do it. It's that he doesn't do it(never did) NOW.
You say that "obsessing ... is dangerous", but you also complain bitterly about bugs in applications crashing them.
No. read what *I'M* saying.
Bugs <> design/process misdesigns...
Specification, as in, purpose and general functions DON'T change. Features and modes of functions should.
Wrong, Madan.
Yes, I know you're wrong.
Specifications very regularly *do* change. The example in the article you quoted -- the comparitive pricing engine -- is an example of the specification being changed after the fact. If the business people wanted to be able to let people buy prominent positions in the listings, they should have specified that ability from day 1. Not some time down the line once the project was started.
No, you misunderstood.
It doesn't change if the IT guy is worth his salt. Does it change in the real world? Sure. Do crappy apps and systems also get built in the real world? Sure.
Quote: True, if the core of the design is off. That's not what I'm implying. I'm implying evolving the design because NO amount of design will *ever* catch all the inherent problems in a project, nor will they catch all the pitfalls or design-based disagreements. Simply sticking with a design, even if you find out parts are wrong is closed-minded and creates a system that the end-user will avoid.
No, it doesn't. MS DOS is evidence enough of that.
MS DOS is a great example. Thanks for proving my point.
BTW, you're wrong.
Quote: Then the ONLY winners are the programers. They get paid and everyone else is stuck with a system *they* decided would work a certain way.Because that's how it was specified to start off with.
No. I've seen systems specified in a certain fashion and I've seen devs take it in the wrong directions simply because they "feel like it" and "know better". That's irresponsible and wasteful.
Quote: The key is to balance the two. To allow coders into the design phase and to include them in the JAD discussions with the end-users. To familiarize them with the process the end-users use and *then* to design a detailed plan that will be revised before implementation or building begins.
End users are only important in the first stage -- deciding what you're going to do, why, and for who -- and the last stage -- what it looks like. End users have to know nothing about how it works,
Wrong. The system has to be a reasonable alternative for the one that exists already or has to be easy, powerful and flexible(and must follow process or business protocol) otherwise it is a flop. Spoken as a coder with no business training whatsoever.
as long as it works in a way that enables them to do what they want with the minimum of fuss.
No. "Minimum of fuss" isn't the coder's responsibility, it's the IT or suit's. Moreso, the coder rarely knows the business process and, therefore, rarely knows how to minimize "fuss".
Evidently our idea of "small change" is different. You might /see/ something as a "small change", but that doesn't mean that it is.
An anxillary process or a UI or an input format change is a minor change.
End users don't need to know anything about anything. The system should be a black box, that just magically works in the way they want.
Wrong. They should indicate how the process works.
If they always take taxes before discount because the system *must* function that way in legacy systems OR because the products or laws of the state mandate such protocol, it isn't the coder's right to alter that..."just because".
Horseshit. If I responded to end users nothing would ever get done. I would end up writing a dozen different interfaces to the program.
Again, you're missing the point. You listen to their concerns and suggestions. You add those, along wi the IT/IS person to the design, if necessary but YOU don't do anything until the IT person gives you a *firm* design.
Just because YOUR bosses are clueless doesn't mean everyone else is.
And so do I. But if some of them can't use it, too bad.
Yes, for YOU. Because you'll get fired or never get contracted again, if the suit has a clue.
You job is to make it easy. If they used to have forms that had three number sets for entry and you break that into four or decide to add uncessary pages or prevent editing or alter the process so that one set of numbers is collected at the end, to make your job easier....it's YOUR problem.
Because often, you won't get paid until the job's done right.
Quote: The purpose of talking to the end-user(in the presence of the biz) is in order to expose hidden problems and to nail down procedure.There is no "the" end user. There are tens, hundreds, thousands of them.
It's called "JAD". You grab a couple of ppl.
Not everyone. Obviously, one woul have to excercise common sense and restraint. Besides, the suits would be setting the meetings up.
Quote: He did do X, Y, Z but he did so in a fashion that was unusable to the end-user.Was the front-end specified? Or left up to him?
It was specefied.
He simply argued that "his way was better".
It wasn't. Not even for pseudo techies like me.
Quote: He put a database together that did include the fields provided but made them very difficult to cross-query.
I'm a little surprised that such a thing is even possible.
No keys in tables linking one group to the next. Makes it a bitch no?
Errors in the table cause changes in order status and even he didn't know why.
Overlap in orders spontaneously occurred. Guess what? He didn't know why either.
He said it was "too complex" ...our system. All we're doing is an online shopping mall. Complex?
You can put one together in a couple days probably...
Quote: The point? A waste of time by an ego-centric db admin that, I shouldn't have to mention, is no longer employed by us...An ego-centric DB admin who sounds like he was given a woeful lack of direction.
No. He was given everything down to the last field. Literally. I can even post screen caps if you want.
He simply *didn't* or *couldn't* do things that way...
Quote: Precisely. Geeks should do what they can and explain it to the biz ppl. The process necessary. A good biz person will listen. A bad one won't.Just like good devs will listen to the end-user's needs and bad devs will build the app however the hell they feel like it....
No. Someone needs to specify what they want. And that shouldn't be any single end user, because they are all different. It needs an average.
I never said this.
Quote: Or times when coders exagerrate the importance of something to buy them time?I've seen both happen.
Give us an example where you aren't jumping to stereotypical conclusions...
The problem is, I need convincing that you're accurate in your appraisal of the situation.
Sure. How long does it take to add a couple of columns to a SQL DB with less than 40k rows? How long does it take to add two queries and one function?
Both small?
Oh, and add a change in VarTYPE in one column.
How much? A week? Two?
Try 1 month for our guy. What a joke. I got it done in 8 hours.
Quote: And that's why you have problems with "suits". They're your boss. Oh sure, you tell them what you need and a good "suit" will listen but you, and I don't mean this in a bad way, seem very "high maintenance".Biz ppl hate coders that presume they're there for show. Most ppl on OSY wouldn't know how to write their names on a complete incorporated tax form and yet coders have this conception that "it's my way or the highway".
Well, here's the thing. If I needed to fill out a tax form, rather than take the time to learn something that holds no interest to me whatsoever, I would hire an /accountant/, and not tell him how to do his job.
True. But then, you would tell him what your goals are.
You certainly wouldn't give him your money and say "do whatever the hell you want with it...I trust you".
No, there isn't. There's still a skills shortage.
Uhm, no there isn't. The ONLY job field in IT that hasn't shrunk massively is networking. Every other is crappers.
What the fuck are you talking about?What do you know about the inner workings of Amazon, or Wal-Mart, or Apple, or Microsoft, or Ford, or GEC, or Boeing, or whatever?
I'm not talking about a web-company. I'm talking about a travel airlines app, for example. The end-user would be the person taking the check-in orders.
If you want to talk about amazon, you STILL need to have an idea of what features the customer wants. Companies that do that the best, perform the best.
Or do you think Amazon just gave its coders the job and never researched its customers' wants....
Yeah, that's it. :rolleyes:
So the people who want to buy these back-issues know how they're going to do that?
A. if the system is for company employees for order taking(like ours), then yes, they know much more than geeks.
B. if the system is online for online use(also like ours) then yes, the geeks need to know what features and classification mechanisms are easy for the customer and which are desirable.
Well, I'd guess it'd go along the lines of "contact the publication, ask them for X copies of issue Y, pay them, receive goods" -- but evidently, as a coder, I'm wrong. How, out of interest, does the process work?
Ok, coder, how would you classify back issues? I'll be happy to give you HOW it's actually done.
Quote: Who knows tax is applied over districts? Geeks? No. Users.
What's the tax in Fl? Do geeks in Wyoming know? No. Fl customers do. You have to take that into account.
The end users don't know a damn thing about such issues. They just expect to be able to visit a web site and buy whatever it is they want. Or double click your program and be able to type, or whatever it is they want to do.
You're focusing solely on the web. What if the end-user is a researcher in a company? Or if the system is intra-systemic?
Still think the user is biz process clueless?
So why did none of the suits explain how it should work?
Down to the last field.
That's a UI issue.
Not once credit card numbers are sent to our bank.
Was the ability to fix your mistakes part of the specification?
Yes.
What the hell does requiring additions of hardware got to do with SQL Server? Your example doesn't appear to make a great deal of sense.
The SQL server uses a VB-built front-end. The VB front end is home-made and buggy as hell. It requires an updated MDAC. Because our users had 95 A, the MDAC couldn't be updated(according to the network ppl) and the app wouldn't run. When I suggested 2k, which WOULD have the MDAC installed on it already(better OS anyways), they gave me a silly excuse( you all said)...
How exactly does that *not* make sense?
I even posted the problem asking for help ON here two months ago....
In the face of people telling you -- incorrectly -- how to do your job, it's sometimes hard not to be.
That and when you think you've got all the answers.
M.
Thu Oct 11 00:52:29 2001
ERRRRNT! Bill Gates was the original "founder" of the MCSE and he, by your admission, is a "geek"....
Nope. If ppl know why it isn't worthwhile, then they'd be able to stop demanding it. Unfortunately, techies hoard information like squirrels in winter and the average person neither has the time nor the aptitude to learn a "foreign language" like networking.
... pay them to be teachers.
It's called division of labor. The same reason why you don't give yourself a root canal or defend yourself in court.Just like you don't have to be an expert in law or tax, lawyers and actuaries don't have to be experts in tech.
These people aren't knowledgable in technical matters, but still think themselves to be able to pick and choose competent staff.
Ignorant <> Me.A good programmer will endeavor to know.
Web? No DB? Of course you need it. No networking? Of course you need it.Tell me again why I *don't* need it?
I'm not.
See above.
Java <> Javascript.
I'm talking about the Java platform vs. ASP.
Not anymore.CF 5.0 integrates new Java libraries that are easy AND powerful. Pick it up sometime. You'll hate it....
Which of course means the average person will LOVE it.
Before Windows, MS was developing different apps and working towards other OSes that eventually transfigured into 3.1. Gates was a "leader" but a technical one.He is not a business man. He couldn't draft a resource acquired statement or compound income statement if his life depended on it. Oh sure, he could take classes, but that's not the point. It's not that he could learn how to do it. It's that he doesn't do it(never did) NOW.
No. read what *I'M* saying.Bugs <> design/process misdesigns...
Yes, I know you're wrong.
No, you misunderstood.It doesn't change if the IT guy is worth his salt. Does it change in the real world? Sure. Do crappy apps and systems also get built in the real world? Sure.
MS DOS is a great example. Thanks for proving my point.
BTW, you're wrong.
No. I've seen systems specified in a certain fashion and I've seen devs take it in the wrong directions simply because they "feel like it" and "know better". That's irresponsible and wasteful.
Wrong. The system has to be a reasonable alternative for the one that exists already or has to be easy, powerful and flexible(and must follow process or business protocol) otherwise it is a flop. Spoken as a coder with no business training whatsoever.
No. "Minimum of fuss" isn't the coder's responsibility, it's the IT or suit's. Moreso, the coder rarely knows the business process and, therefore, rarely knows how to minimize "fuss".
An anxillary process or a UI or an input format change is a minor change.
Wrong. They should indicate how the process works.
The end users do not know and do not have to know how the business processes work.
This is why people make a lot of money writing front-ends to SAP to hide these kinds of details.
If they always take taxes before discount because the system *must* function that way in legacy systems OR because the products or laws of the state mandate such protocol, it isn't the coder's right to alter that..."just because".
Again, you're missing the point. You listen to their concerns and suggestions. You add those, along wi the IT/IS person to the design, if necessary but YOU don't do anything until the IT person gives you a *firm* design.
Just because YOUR bosses are clueless doesn't mean everyone else is.
Yes, for YOU. Because you'll get fired or never get contracted again, if the suit has a clue.You job is to make it easy. If they used to have forms that had three number sets for entry and you break that into four or decide to add uncessary pages or prevent editing or alter the process so that one set of numbers is collected at the end, to make your job easier....it's YOUR problem.
If 5% of users want two fields' positions reversed, too bad. It might make things easier for them, it might simultaneously make things harder for 95% of the users.
The majority rules, Madan. If a minority don't like something, that's too bad. We can't please them all.
Because often, you won't get paid until the job's done right.
It's called "JAD". You grab a couple of ppl.
Not everyone. Obviously, one woul have to excercise common sense and restraint. Besides, the suits would be setting the meetings up.
It was specefied.He simply argued that "his way was better".
It wasn't. Not even for pseudo techies like me.
Was there a technical reason for it (say, time constraints), or was his manager simply failing to do his job?
No keys in tables linking one group to the next. Makes it a bitch no?
Errors in the table cause changes in order status and even he didn't know why.
Overlap in orders spontaneously occurred. Guess what? He didn't know why either.
He said it was "too complex" ...our system. All we're doing is an online shopping mall. Complex?
You can put one together in a couple days probably...
No. He was given everything down to the last field. Literally. I can even post screen caps if you want.He simply *didn't* or *couldn't* do things that way...
Sure. How long does it take to add a couple of columns to a SQL DB with less than 40k rows? How long does it take to add two queries and one function?
Both small?Oh, and add a change in VarTYPE in one column.
How much? A week? Two?
Try 1 month for our guy. What a joke. I got it done in 8 hours.
True. But then, you would tell him what your goals are.You certainly wouldn't give him your money and say "do whatever the hell you want with it...I trust you".
Uhm, no there isn't. The ONLY job field in IT that hasn't shrunk massively is networking. Every other is crappers.
I'm not talking about a web-company. I'm talking about a travel airlines app, for example. The end-user would be the person taking the check-in orders.
If you want to talk about amazon, you STILL need to have an idea of what features the customer wants. Companies that do that the best, perform the best.
Or do you think Amazon just gave its coders the job and never researched its customers' wants....
A. if the system is for company employees for order taking(like ours), then yes, they know much more than geeks.B. if the system is online for online use(also like ours) then yes, the geeks need to know what features and classification mechanisms are easy for the customer and which are desirable.
Ok, coder, how would you classify back issues? I'll be happy to give you HOW it's actually done.
What's the tax in Fl? Do geeks in Wyoming know? No. Fl customers do. You have to take that into account.
You're focusing solely on the web.
What?
What if the end-user is a researcher in a company? Or if the system is intra-systemic?Still think the user is biz process clueless?
Not once credit card numbers are sent to our bank.
Yes.
The SQL server uses a VB-built front-end. The VB front end is home-made and buggy as hell. It requires an updated MDAC. Because our users had 95 A, the MDAC couldn't be updated(according to the network ppl) and the app wouldn't run. When I suggested 2k, which WOULD have the MDAC installed on it already(better OS anyways), they gave me a silly excuse( you all said)...How exactly does that *not* make sense?
Start from the beginning.
You had a database application with a VB front-end.
The front-end couldn't run on Windows 95 because of a software dependency.
You wanted to upgrade (presumably the clients?) to Win2K but for some reason you feel to be fallacious, that wasn't an option.
The network guy said that a new SQL Server was necessary.
You said that wasn't necessary.
It's those last two things I don't understand -- I don't see why needing a new SQL Server should be related to Win2K's networking capabilities.
I even posted the problem asking for help ON here two months ago....