People with a PhD in some non-technical dicipline have no real need to know HTML; they just need to get information out in a context that is meaningful to their students, handicapped accessable, and technically accurate.
The solution lies in restricting or structuring their input: think of the filling out forms approach in stead of putting them in front of a blank canvas and letting them do anything they want. The line is pretty blurry: i know Dreamweaver allows you to lock down template areas (and yes, i've heard of contribute) and there are tools like fckeditor which can turn a text area into something the average MS Word user would recognize. It's one of the key ironies of development that sometimes it is much harder for the developer to make things easier for his users.
I think all developers expect some measure of volitility. I think the bigger problem behind requirements volitility is "the customer isn't sure what they want, and can't express what they do want to the developer."
There is almost always in the life of a project, a moment in which the client can tell you *exactly* what he wants: right after you give him what he said he wanted....
Requirements volatility is certainly a major cause of project failure, but it's been held up as "the" major cause for too long. If you look at the practice of (corporate) IT these days, you see a lot of methodologies being tried out, a lot of reorganizations, a lot of permutations to try and find the "magic" that can make the difference between a cost center and a core competitive function. A lot of people - and management consultants too - are preaching the Industrial Science of Software Engineering (everyone seems to agree that the key to making TONS of money out of your IT department starts with giving them some of it). One thing is certain: no one's cracked it yet. You would have noticed.
Now, while a lack of any sort of methodology is a disaster waiting to happen, I have a difficult time believing that a bad fit for a project creates more risk than project complexity and shifting requirements combined, as they suggest.
While i'm not too sure i agree about the exact percentages, but i am glad to see "Requirements volatility" at the bottom. I find it ironic that the products of the urge to hammer down requirements is one of the key enablers of outsourcing. You certainly can't "pop down the hall" to India. As for lack of a methodology, i think most developers would agree on two things: a source code control tool and a methodology are both a Good Thing. It doesn't really matter which one you use or follow - just do.
I understand what you mean when you say it's the point of view of IT managers, not project managers or developers that's taken into account - but it's their zillion schmooleans:)
One interesting thing about the whole SAP/ABAP world: during the most recent downturn in IT hiring, demand for SAP developers was one of the least affected.
That poor requirements problem is part of what's keeping your job from going to India. Once they've gone through the hassle of writing everything down as use cases... they might as well fax it offshore.
Think about that next time some guy from marketing drops by to ask for a new feature.
replying to my own post, and that, but does anybody else think this is some kind of script thing? Comments are increasing rapidly, and (take a look)... even worse than usual, if you get my drift. I especially like the trolls that are pure slashbot with the exception of references to something called "GNAA/Linux"...
or maybe i'm just paranoid. If it is, it's a shitty thing to do today.
As a general rule you don't mind 'em in software, but you'd rather keep the total number of hardware units low, allowing for performance and disaster recovery needs.
You can already get all that today from big blue. Are you really going to buy it next year from Apple?
If you can't make a closed fork, then many people who would otherwise want to make one are instead motivated to either contribute back to the main project, or not use it at all.
You can't contribute if the committers aren't interested in your patches and won't put them in CVS. Most of the time this is due to a quality or style issue, but sometimes it's just due to the fact that the committers might have another vision of the project than you do. In a case like that, where you are quite willing and able to do the work, you have two choices: patch every new version with your changes or fork the project. If enough people value your choices you might be able to develop a viable fork.
Although forking should never be undertaken lightly, it is the sine qua non of freedom in software.
Can you use Oracle for nickle and dime stuff like small business customer management or a bug tarcking system? Yes, but why in God's green earth would anyone ever want to go through that expense and learning curve?
The usual answer is "because you're already using Oracle for something/everything else". The other day i created a schema with one table - not my proudest moment - because creating a pissant schema on an existing instance is still easier than installing a new product (and that's without talking about getting the approval to install a new product, which, around here, is not easy.)
In the mean time, no ammount of skill on the part of an orange producer will make an apple into a better tasting orange than one that any idot could pick off a tree and hand to you.
I read a much better analogy the other day - instead of the tired "apples and oranges", try "pencil vs. pen" - they're both writing instruments, and you can interchange them within reason, but saying "pencils are better than pens" is meaningless unless you follow it with "...for the purpose of X"
It's certainly true that Oracle can sell into the corporate environment using arguments like this (company X uses Oracle to manage a three terrabyte database! And they only accept one picosecond of downtime per decade otherwise all the DBAs get disembowled with a spoon!) - mostly in the hopes of triggering some mid level IT manager's penis envy. In practise, reliability is more a function of how good your people are than what products you use - guru + MySql > idiot + Oracle any day of the week, for 99 out of 100 common cases.
This isn't Oracle bashing btw: i've got MySql installed on my workstation because all the demo apps seem to use it, but i work on Oracle - TOAD is *always* open - and i've always said that if it could cook i'd marry it.
I think most "typical" Oracle customers are much less sticker-price sensitive than you'd think, since they realize that the cost of developers and DBAs you need to actually do something with your shiny new DB usually far outweighs the cost of the software. If anything, Oracle wins a lot of business in the db world just like Microsoft wins a lot of business in the productivity suite world: most corporate customers think "Database" = "Oracle" and never really go out there to investigate the alternatives.
Slashdot Mirror
Skip on over to your neighbors at Gnuwin32.sourceforge.net - all kinds of *nix command line goodness ported to windows.
People with a PhD in some non-technical dicipline have no real need to know HTML; they just need to get information out in a context that is meaningful to their students, handicapped accessable, and technically accurate.
The solution lies in restricting or structuring their input: think of the filling out forms approach in stead of putting them in front of a blank canvas and letting them do anything they want. The line is pretty blurry: i know Dreamweaver allows you to lock down template areas (and yes, i've heard of contribute) and there are tools like fckeditor which can turn a text area into something the average MS Word user would recognize. It's one of the key ironies of development that sometimes it is much harder for the developer to make things easier for his users.
ObPA
Scratch which thought? The first thought? Or the second thought?
i'm confused...
I think all developers expect some measure of volitility. I think the bigger problem behind requirements volitility is "the customer isn't sure what they want, and can't express what they do want to the developer."
There is almost always in the life of a project, a moment in which the client can tell you *exactly* what he wants: right after you give him what he said he wanted....
Requirements volatility is certainly a major cause of project failure, but it's been held up as "the" major cause for too long. If you look at the practice of (corporate) IT these days, you see a lot of methodologies being tried out, a lot of reorganizations, a lot of permutations to try and find the "magic" that can make the difference between a cost center and a core competitive function. A lot of people - and management consultants too - are preaching the Industrial Science of Software Engineering (everyone seems to agree that the key to making TONS of money out of your IT department starts with giving them some of it). One thing is certain: no one's cracked it yet. You would have noticed.
Dude, put that to music. You'll sell no copies, but it'll go gold on bittorrent ;)
Now, while a lack of any sort of methodology is a disaster waiting to happen, I have a difficult time believing that a bad fit for a project creates more risk than project complexity and shifting requirements combined, as they suggest.
:)
While i'm not too sure i agree about the exact percentages, but i am glad to see "Requirements volatility" at the bottom. I find it ironic that the products of the urge to hammer down requirements is one of the key enablers of outsourcing. You certainly can't "pop down the hall" to India. As for lack of a methodology, i think most developers would agree on two things: a source code control tool and a methodology are both a Good Thing. It doesn't really matter which one you use or follow - just do.
I understand what you mean when you say it's the point of view of IT managers, not project managers or developers that's taken into account - but it's their zillion schmooleans
One interesting thing about the whole SAP/ABAP world: during the most recent downturn in IT hiring, demand for SAP developers was one of the least affected.
That poor requirements problem is part of what's keeping your job from going to India. Once they've gone through the hassle of writing everything down as use cases ... they might as well fax it offshore.
Think about that next time some guy from marketing drops by to ask for a new feature.
replying to my own post, and that, but does anybody else think this is some kind of script thing? Comments are increasing rapidly, and (take a look)... even worse than usual, if you get my drift. I especially like the trolls that are pure slashbot with the exception of references to something called "GNAA/Linux"...
or maybe i'm just paranoid. If it is, it's a shitty thing to do today.
do you think it could have happened at a worse time? Someone in support is having a shitty kickoff to their christmas weekend.
maybe if they make it in black and put an IBM logo on it. but i'm not promising anything.
hey, don't get me wrong, i see the ads, i dream as well, but i can't see myself telling the ops manager i'm installing Macs in those big cold rooms.
Irony is a virus, and lots of people seem to have nortonized.
As a general rule you don't mind 'em in software, but you'd rather keep the total number of hardware units low, allowing for performance and disaster recovery needs.
You can already get all that today from big blue. Are you really going to buy it next year from Apple?
a ppc version of the nt kernel will run the next xbox.
It should be "News.com.com (a Com.com company)", but then people would just laugh.
sometimes its due to unbelievably large egos who never learned what "sharing" actually means.
... laugh, it's funny ;)
Yessssss, yessssssssssss - release your anger!
If you can't make a closed fork, then many people who would otherwise want to make one are instead motivated to either contribute back to the main project, or not use it at all.
You can't contribute if the committers aren't interested in your patches and won't put them in CVS. Most of the time this is due to a quality or style issue, but sometimes it's just due to the fact that the committers might have another vision of the project than you do. In a case like that, where you are quite willing and able to do the work, you have two choices: patch every new version with your changes or fork the project. If enough people value your choices you might be able to develop a viable fork.
Although forking should never be undertaken lightly, it is the sine qua non of freedom in software.
Can you use Oracle for nickle and dime stuff like small business customer management or a bug tarcking system? Yes, but why in God's green earth would anyone ever want to go through that expense and learning curve?
The usual answer is "because you're already using Oracle for something/everything else". The other day i created a schema with one table - not my proudest moment - because creating a pissant schema on an existing instance is still easier than installing a new product (and that's without talking about getting the approval to install a new product, which, around here, is not easy.)
In the mean time, no ammount of skill on the part of an orange producer will make an apple into a better tasting orange than one that any idot could pick off a tree and hand to you.
I read a much better analogy the other day - instead of the tired "apples and oranges", try "pencil vs. pen" - they're both writing instruments, and you can interchange them within reason, but saying "pencils are better than pens" is meaningless unless you follow it with "...for the purpose of X"
It's certainly true that Oracle can sell into the corporate environment using arguments like this (company X uses Oracle to manage a three terrabyte database! And they only accept one picosecond of downtime per decade otherwise all the DBAs get disembowled with a spoon!) - mostly in the hopes of triggering some mid level IT manager's penis envy. In practise, reliability is more a function of how good your people are than what products you use - guru + MySql > idiot + Oracle any day of the week, for 99 out of 100 common cases.
This isn't Oracle bashing btw: i've got MySql installed on my workstation because all the demo apps seem to use it, but i work on Oracle - TOAD is *always* open - and i've always said that if it could cook i'd marry it.
I think most "typical" Oracle customers are much less sticker-price sensitive than you'd think, since they realize that the cost of developers and DBAs you need to actually do something with your shiny new DB usually far outweighs the cost of the software. If anything, Oracle wins a lot of business in the db world just like Microsoft wins a lot of business in the productivity suite world: most corporate customers think "Database" = "Oracle" and never really go out there to investigate the alternatives.
on the other hand, your domain name is now worth much more!
lies, damn lies, benchmarks,... and press releases.