For what I see, if we had the tools we have today with the requirements of 25 years ago, we could do fast and good software.
"Cheap, Good, Fast in detail"
Cheap: our marketing/management wants it cheap to get more money ------ More programmers? They'd be useful. I know about "The Mythical Man Month" but I know also about "Under-staffed Death March Project". But unless the project is already in crisis, the senior management won't give developers
Good: just the developers/end users want it good ----- Sure the customer claims it wants a good product, but such a claim is not supported by realistic time requirements and superficial attention to the results.
Fast: the customer needs it yesterday ----- I've heard a customer revolutionizing all the requirements for a project (when we were 60% of the schedule) changing the framework we should have worked on and telling "Give me you're new estimate, even though it is clear we won't accept any change of the release date"
So my opinion: the sw dev process has improved but hasn't kept the pace with the market requirements and senior management greed
I'm trying to see it from the developer side and expand your reason (2)
In the IT business world the first choice you have to face is "make or buy".
In the OpenSource world it is more a "create or join" thing: you can develop your own version of a software or decide to join another project.
How could you join a "Ransom" project? You ask for a preview of the code to see if you want to join? I don't think so..
Maybe this economical model is sound for 1-2 programmers (maybe friends or colleagues) projects but I don't see it working for bigger or "heterogenous staffed" projects.
After all, you'd probably decide to join a project if you think it is interesting and well architectured: what if I sign in (???) for working in a "Ransom" project just to discover it is a bunch of "spaghetti-code", "lava flow", "blob" and "legacy code" sort of things?
I'm afraid we would see A LOT of similar "Ransom" project where programmers would not group together to make a better product.
(...)
"The simplest way is to make sure you have no
trusted publishers, including Microsoft. If you do
that, any attempt by either a web page or an HTML
mail to download an ActiveX control will generate a warning message."
(...)
We could use this idea also with SPAM. Why use Bayesian filters (that aren't still 100% safe)?
We could open every single message and decide if it is SPAM or not. If it is SPAM we can then delete it... it's easy!!
I'd like to see the questions they have made...
Have they really made any difference between CRT and LCD? Have they just asked about "How many hours you spend in front of a monitor"?
And after all, I guess there are a lot of reasons for "reluctance to go to work". I have it sometimes indipendently by the fact that I have an LCD.. it is more about scarse work satisfaction and mismanagement:-(
Slashdot Mirror
Obviously, we are more accustomed to "Plato's Cave" myth..
But, as someone already pointed out, "The Matrix" has been a "visually innovative" film that is worth watching... it was not a philosophy essay :-)
I had to... My first Google query after having seen this article has been "mind your own business :-)"
Talking about System Integrators Industry...
For what I see, if we had the tools we have today with the requirements of 25 years ago, we could do fast and good software.
"Cheap, Good, Fast in detail"
Cheap: our marketing/management wants it cheap to get more money
------
More programmers? They'd be useful. I know about "The Mythical Man Month" but I know also about "Under-staffed Death March Project". But unless the project is already in crisis, the senior management won't give developers
Good: just the developers/end users want it good
-----
Sure the customer claims it wants a good product, but such a claim is not supported by realistic time requirements and superficial attention to the results.
Fast: the customer needs it yesterday
-----
I've heard a customer revolutionizing all the requirements for a project (when we were 60% of the schedule) changing the framework we should have worked on and telling "Give me you're new estimate, even though it is clear we won't accept any change of the release date"
So my opinion: the sw dev process has improved but hasn't kept the pace with the market requirements and senior management greed
In the IT business world the first choice you have to face is "make or buy".
In the OpenSource world it is more a "create or join" thing: you can develop your own version of a software or decide to join another project.
How could you join a "Ransom" project? You ask for a preview of the code to see if you want to join? I don't think so..
Maybe this economical model is sound for 1-2 programmers (maybe friends or colleagues) projects but I don't see it working for bigger or "heterogenous staffed" projects.
After all, you'd probably decide to join a project if you think it is interesting and well architectured: what if I sign in (???) for working in a "Ransom" project just to discover it is a bunch of "spaghetti-code", "lava flow", "blob" and "legacy code" sort of things?
I'm afraid we would see A LOT of similar "Ransom" project where programmers would not group together to make a better product.
(...)
"The simplest way is to make sure you have no
trusted publishers, including Microsoft. If you do
that, any attempt by either a web page or an HTML
mail to download an ActiveX control will generate a warning message."
(...)
We could use this idea also with SPAM. Why use Bayesian filters (that aren't still 100% safe)? We could open every single message and decide if it is SPAM or not. If it is SPAM we can then delete it... it's easy!!
This message doesn't need a signature
And after all, I guess there are a lot of reasons for "reluctance to go to work". I have it sometimes indipendently by the fact that I have an LCD.. it is more about scarse work satisfaction and mismanagement :-(
Well, the sentence is more connected to "AntiPatterns" :-)