The only possible way that it takes off is if MSFT literally GIVES IT AWAY.
I've watched several thin client manufacturers try to leverage into this space, essentially betting the whoel company, and then failing.
Jst because MSFT is doing it doesnt mean its a good idea. Why would anyone choose to cripple perfectly good PC's, especially if they have to pay for it?
I'm saying that the current high-ritual processes, such as UML, RAD, etc. have not significantly increased the chance that a certain software project will succeed.
Without a doubt, there is a need for a cogent, coherent software process, thats not my argument. My argument is that our processes are awful, and the documentation we produce is generally useless; being either too vague, too explicit or not related to the finished product.
I've recently begun to appreciate the lesser-ritual approqches, such as SCRUMM and to a lesser extent XP and Agile. They produce enough documentation to be useful, but focus on producing a real, working, testable product quickly and efficiently.
In SCRUMM, if you need a feature, you first write a test case that will prove you contain that feature, and its working. If you dont have a working test-case, you dont have a working feature. Period.
In other methodologies, you spend more time with a word-processor open than you do truly designing, implementing and testing requirements.
If you're organization requires a strict documentation regimine (ISO-XXXX, CMM-$FOO), then you make that one of the features, and have a test case for that.
The biggest problem with this approach is that you need fairly ego-less programmers that can divorce themselves fromtheir creation, and throw away bits that better implementations suggested.
If you can create an appropriate work environment, and trust me this is the hard part, this approach works amazingly well, and will produce great products, quickly and cost-effectively that will meet your stakeholders needs.
There is a huge problem with Prima-Donnas in our industry, and I have been lucky enough to work in one environment that simply doesnt allow Ego's to run wild. I'm still trying to decipher how you create this environment, and am simply astounded that it can be done.
I truly hope that our industry matures in my working lifetime. I think that we need a formal accreditting trade group that is elitist, like every other engineering field. I also think that "programmers" need to be seperated from "engineers" formally.
Yeh, its elitist, but you never hear about a Lineman calling themself an "electrical engineer", they're skilled workers who work under the direction of an educated, certified engineer.
So basically, I see two problems with our field: 1) Our current processes are ineffective. 2) There is no formal method of seperating the Wheat from the Chaffe.
It needs to be done. Reboot monkeys are not engineers, whether or not Microsoft says they are.
How the fuck is software a "new" thing? Last I've checked moden programming has been around for 40 years, and modern languages for at least 30. Why is this attitude of "its brand new, oh my god we dont know what we're doing??!??!" still prevalent?
and as for your prima-donna programmers, they need to grow the fuck up, this isnt highschool anymore.
You're stating that 70% of software projects fail. Can you imagine if 70% of Civil Engineering projects failed? 70% of bridges designed?
All you are saying to me is: We suck at this whole "design and implementaion" thing, but if we produce a lot of documentation, at least it we'll have a record of why we suck so badly.
First, let me clarify, when I was talking about reimplimenting API's, I meant only their implementation, and not the interface. Changing the interface is akin to changing water rough-ins and electric homeruns and drops after installing all teh end fixtures:-)
There are often times when you absolutely, positively need to trash an implementation, yet ego's involved will force you to patch the shoddy work endlessly, and fruitlessly.
If your foundation is cracked, or leaking, or crumbling, you try to fix it, and failing that, you replace it.
In that same vein, if the requirements changed from a two story dwelling, into a 20 story skyscraper, you would have to find a way to change everything to engineered steel instead of wooden beams.
The problem is, that programmers have these entirely too large of egos to divorce themselves from their implementation. When clear and conclusive evidence demonstrates that a piece needs to be scrapped, you will hear howls of derision. They simply can not admit that their implementation is faulty at its core.
If a foundation is crumbling, you will never hear the Civie scream how the design was fine, and the implementation perfect, and how dare we suggest that it needs to be scrapped! They'll fix the damn thing.
As I've said elsewhere in this thread; Software Engineering has a ton of maturing to do, in a hurry.
but what is harder to remove, a foundation that was poured incorrectly, or a jack-assed implementation of your core API's?
it has been argued (About Face: Alan Cooper) that it is harder to remove the code than the tons of concrete, because ego's are attached to the code, whereas nobody cares if you rip out the foundation, hell the construction crew would be happy - they're going to be paid for it!
Imagine telling your senior engineers that the implementation they just laid down needs to be totally scrapped because its... retarded? They would kick and scream and bitch and moan.
the problem with nuke plants is the "worst case scenario".
If you have a Coal plant, and lose it - you might burn to the fence line.
If you have a Nuke plant, and really lose it, you have Chernobyl.
Nuke energy is relatively expensive due to regulatory compliance. Needed regulations mind you, but thats why you dont see many nuke plants go up these days.
Coal is going to be the big electriciy producing thing for the forseeable future. Its insanely cheap, and the US has a whole lot of it.
Slashdot Mirror
This project will go nowhere, fast.
The only possible way that it takes off is if MSFT literally GIVES IT AWAY.
I've watched several thin client manufacturers try to leverage into this space, essentially betting the whoel company, and then failing.
Jst because MSFT is doing it doesnt mean its a good idea. Why would anyone choose to cripple perfectly good PC's, especially if they have to pay for it?
however, widespread electrical use is 100 years?
And somehow, they have managed to get their shit together, and acredit and build their profession.
i really think that its time that software engineering grew up and starting policing its own ranks.
sorry about my earlier tone, too.
I'm saying that the current high-ritual processes, such as UML, RAD, etc. have not significantly increased the chance that a certain software project will succeed.
Without a doubt, there is a need for a cogent, coherent software process, thats not my argument. My argument is that our processes are awful, and the documentation we produce is generally useless; being either too vague, too explicit or not related to the finished product.
I've recently begun to appreciate the lesser-ritual approqches, such as SCRUMM and to a lesser extent XP and Agile. They produce enough documentation to be useful, but focus on producing a real, working, testable product quickly and efficiently.
In SCRUMM, if you need a feature, you first write a test case that will prove you contain that feature, and its working. If you dont have a working test-case, you dont have a working feature. Period.
In other methodologies, you spend more time with a word-processor open than you do truly designing, implementing and testing requirements.
If you're organization requires a strict documentation regimine (ISO-XXXX, CMM-$FOO), then you make that one of the features, and have a test case for that.
The biggest problem with this approach is that you need fairly ego-less programmers that can divorce themselves fromtheir creation, and throw away bits that better implementations suggested.
If you can create an appropriate work environment, and trust me this is the hard part, this approach works amazingly well, and will produce great products, quickly and cost-effectively that will meet your stakeholders needs.
There is a huge problem with Prima-Donnas in our industry, and I have been lucky enough to work in one environment that simply doesnt allow Ego's to run wild. I'm still trying to decipher how you create this environment, and am simply astounded that it can be done.
I truly hope that our industry matures in my working lifetime. I think that we need a formal accreditting trade group that is elitist, like every other engineering field. I also think that "programmers" need to be seperated from "engineers" formally.
Yeh, its elitist, but you never hear about a Lineman calling themself an "electrical engineer", they're skilled workers who work under the direction of an educated, certified engineer.
So basically, I see two problems with our field:
1) Our current processes are ineffective.
2) There is no formal method of seperating the Wheat from the Chaffe.
It needs to be done. Reboot monkeys are not engineers, whether or not Microsoft says they are.
Most likely, you have been around database application shops.
honestly, when you get a bug report froma project that completed 2 years ago do you:
A) Search for the Design Doc before debugging
B) Look at the damn code
How the fuck is software a "new" thing? Last I've checked moden programming has been around for 40 years, and modern languages for at least 30. Why is this attitude of "its brand new, oh my god we dont know what we're doing??!??!" still prevalent?
and as for your prima-donna programmers, they need to grow the fuck up, this isnt highschool anymore.
You're stating that 70% of software projects fail. Can you imagine if 70% of Civil Engineering projects failed? 70% of bridges designed?
All you are saying to me is: We suck at this whole "design and implementaion" thing, but if we produce a lot of documentation, at least it we'll have a record of why we suck so badly.
I disagree.
:-)
First, let me clarify, when I was talking about reimplimenting API's, I meant only their implementation, and not the interface. Changing the interface is akin to changing water rough-ins and electric homeruns and drops after installing all teh end fixtures
There are often times when you absolutely, positively need to trash an implementation, yet ego's involved will force you to patch the shoddy work endlessly, and fruitlessly.
If your foundation is cracked, or leaking, or crumbling, you try to fix it, and failing that, you replace it.
In that same vein, if the requirements changed from a two story dwelling, into a 20 story skyscraper, you would have to find a way to change everything to engineered steel instead of wooden beams.
The problem is, that programmers have these entirely too large of egos to divorce themselves from their implementation. When clear and conclusive evidence demonstrates that a piece needs to be scrapped, you will hear howls of derision. They simply can not admit that their implementation is faulty at its core.
If a foundation is crumbling, you will never hear the Civie scream how the design was fine, and the implementation perfect, and how dare we suggest that it needs to be scrapped! They'll fix the damn thing.
As I've said elsewhere in this thread; Software Engineering has a ton of maturing to do, in a hurry.
you cant call yourself an engineer without an EIT or PE...
and as soon as you point me to an authority that accredits Software Engineers, I'll gladly submit myself to the process.
but what is harder to remove, a foundation that was poured incorrectly, or a jack-assed implementation of your core API's?
it has been argued (About Face: Alan Cooper) that it is harder to remove the code than the tons of concrete, because ego's are attached to the code, whereas nobody cares if you rip out the foundation, hell the construction crew would be happy - they're going to be paid for it!
Imagine telling your senior engineers that the implementation they just laid down needs to be totally scrapped because its... retarded? They would kick and scream and bitch and moan.
As a discipline, we need to mature, a lot.
blech.
A "Computer Scientist" is a mathematician specializing in an obscure branch of mathematics. There is no "science" involved.
A "Software Engineer" is an applied mathematician, closing in on acutal engineering, depending on how close to the metal they get.
This is coming from a Software Engineer, with a CompSci degree.
right, and the marginal cost for a song is close to 0, so eventually we should be paying close to 0 for music.... right?
what you're talking about is collusion, and very very very illegal.
hand compile?
surely, you mean "compile from source"....
i know of very, very very few people who actually "hand compile"... and even then, it would only be gcc...
a blow torch is acceptable, too...
and how much more expensive are those keyboards over whatever-the-cheapest-crap-from-china-is-today.
i have a hard time believing that for-profit hospitals are about to spend NEMA-like rates for computer equipment to be more bacteria resistant,
good lord.
what major tech school would you recommend people go to instead?
if you can get in to MIT or CalTech, you go. period.
you use citrix for old vb apps, and they work?
that depends.
bank interest, yes?
muni bonds? only to the muni and state gov, no fed taxes.
so is "creationism"
and if you're taking a biology course, arguing against evolution is akin to arguing against the fact of 2+2=4 .
did anyone ever read Family Circus?
or "Dick Tracy"
or "Cathy"?
the problem with nuke plants is the "worst case scenario".
If you have a Coal plant, and lose it - you might burn to the fence line.
If you have a Nuke plant, and really lose it, you have Chernobyl.
Nuke energy is relatively expensive due to regulatory compliance. Needed regulations mind you, but thats why you dont see many nuke plants go up these days.
Coal is going to be the big electriciy producing thing for the forseeable future. Its insanely cheap, and the US has a whole lot of it.
youre just an unapolegetic racist. its really disgusting in this day and age.
and you're a racist bastard.
what the fuck, you actually believe that white flight was due to blacks being more violent, and not forced desegregation?
i cant believe the utter ugly racism that you are espousing.