Language communities and best practices
-
Momony wrote:
A lot of these methodologies are just different ways of doing research.
Exactly. Or looking at the problem from different perspectives.
Momony wrote:
The reality is there is always a little research that goes into a software project
:) The projects I work on, it seems that most of the software development is a parallel process of researching whether the whole concept is even feasible! I think those are the most fun projects, actually.
Momony wrote:
and when you do find a usable answer, to document the idea
Aye!!! That is so important, and is something I don't see being done (even by myself) leading to a lot of gnashing of teeth when repeating work, and even worse, in understanding later what the steps were that led up to that usable answer. Marc
Marc Clifton wrote:
A lot of these methodologies are just different ways of doing research. Exactly. Or looking at the problem from different perspectives.
Hopefully finding the best approach to tackling the problem in the process.
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
-
The Write Stuff[^] This article makes the rounds every now and then. Doing it right is very expensive, although in many cases so is doing it wrong.
Even then they issue each Shuttle mission crew with a list of the known problems that are too difficult/expensive to fix in time (or indeed ever) and which should therefore be avoided. "Discrepancy reports cause changes in software to make it match the requirements. Early in the program, the software found its way into the simulators after less verification because simulators depend on software just to be turned on. At that time, the majority of the discrepancy reports were from the field installations. Later, the majority turned up in the SPF. All discrepancy reports are formally disposed of, either by appropriate fixes to the software, or by waiver. Richard Parten said, "Sometimes it is better to put in an 'OPS Note' or waiver than to fix (the software). We are dependent on smart pilots". If the discrepancy is noted too close to a flight, if it requires too much expense to fix, it can be waived if there is no immediate danger to crew safety. Each Flight Data File carried on board lists the most important current exceptions of which the crew must be aware. By STS-7 in June of 1983, over 200 pages of such exceptions and their descriptions existed. Some will never be fixed, but the majority were addressed during the Shuttle launch hiatus following the 51L accident in January 1986." http://www.hq.nasa.gov/office/pao/History/computers/Ch4-5.html[^]
DoEvents: Generating unexpected recursion since 1991
-
Marc Clifton wrote:
A lot of these methodologies are just different ways of doing research. Exactly. Or looking at the problem from different perspectives.
Hopefully finding the best approach to tackling the problem in the process.
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
Paul Conrad wrote:
Hopefully finding the best approach to tackling the problem in the process.
Not to be pedantic, but I don't think there is such a thing as a best approach. Rather, there are often several viable approaches, each with their benefits and drawbacks. Marc
-
Paul Conrad wrote:
Hopefully finding the best approach to tackling the problem in the process.
Not to be pedantic, but I don't think there is such a thing as a best approach. Rather, there are often several viable approaches, each with their benefits and drawbacks. Marc
Marc Clifton wrote:
there are often several viable approaches, each with their benefits and drawbacks.
I agree. With many different clients I've had over the years, no one particular process is a magical-cure-all silver bullet. Have to look at each case and weigh out the pro's and con's.
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
-
Do this long enough and you will come to intimately realize why most of that is utter crap. Most 'best practices' are ways of herding large groups of substandard programmers in a software factory all the while thoroughly killing the productivity of the truly talented who know when to apply those rules and most importantly when not to. I fully understand why they are necessary in a factory setting with cheap labour and it pays to understand them and their philosophy but it reduces the fine art of software development to the level of any production line worker. A good developer, a truly talented and motivated and experienced one, can outperform any number of factory programmers following the ritual of their best practices religion. I say any number because as you add more factory programmers to a problem you get exponentially decreasing productivity.
Hockey wrote:
Anyways, my question is,
? And your question was??? ;)
When everyone is a hero no one is a hero.
John C wrote:
A good developer, a truly talented and motivated and experienced one, can outperform any number of factory programmers following the ritual of their best practices religion. I say any number because as you add more factory programmers to a problem you get exponentially decreasing productivity.
True. But the vast majority of developers work with and are in fact average developers themselves. By definition. So consequently practices that increase the productivity of those developers cannot be ignored.