September 7, 2015 at 10:15 pm
Comments posted to this topic are about the item The Scientific Method
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
September 7, 2015 at 10:58 pm
Oooooo.... don't get me started... especially about some of the idiotic test methods and totally ridiculous conclusions that their faulty testing leads them to. Unfortunately, some of the folks doing these things are well known and trusted (not by me) individuals that command the respect of many followers and some of the conclusions arrived at are bloody well dangerous especially in areas of performance. I can only hope that their followers are smart enough to write their own tests but, unfortunately, I have evidence of otherwise.
--Jeff Moden
September 7, 2015 at 11:11 pm
One can truly argue that science is probably the greatest invention but in the adoption of scientific methods in the software industry it has somehow gotten lost in translation. Hypothesis turned into assumptions etc. in something more like the flat Earth concept: Software is flat, resides in the centre of the Universe and Business, the Sun and everything else rotates around it.
😎
September 8, 2015 at 4:54 am
There is nothing new in scientific method, that's just some steps that need to be done to learn something. I mean that's is not a human invention, that's the result of us trying to understand why things happen.
Now, software works or not, yes that easy. Normally the development tool is the one generating errors due the development team are not specialist using it and/or the requirements to be done are confuse.
September 8, 2015 at 5:34 am
jhbelalc (9/8/2015)
Now, software works or not, yes that easy.
If that were only true.
--Jeff Moden
September 8, 2015 at 6:17 am
Why not? it's just a way of thinking. If the developer says, yes the software is working but..... With any "but", you can understand the software is not complete, so it must not to be working.... I know, I know if We expect a software to be 100% complete to be on production, it will never be.
So if the software is powered by artificial intelligence it will be ok with any but because he will be "learning from experience". :w00t:
September 8, 2015 at 6:25 am
That's a very simplistic view.
If the developer says the software is working 100%, and to his knowledge it is working 100%, does that mean that it works and there are no undiscovered errors, no misunderstood requirements, no features which were left out of the initial analysis etc?
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
September 8, 2015 at 6:34 am
Yes, that is a good point of view. I agree with that too. If the software has specific boundaries and those were properly filled, we can say it's done 100%
September 8, 2015 at 6:41 am
Ok, now how do you tell that the boundaries are 'properly filled'?
The developer says so?
The items are checked off on a list?
No bugs have been found?
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
September 8, 2015 at 7:24 am
the boundaries are 'properly filled' only if the client say so.
The person in charge of deliver the software to the client can say it's finished but finally only the client is right.
This is no end discussion, finally almost every developer creates software to satisfy client's expectations. So the client has the final word.
September 8, 2015 at 7:33 am
jhbelalc (9/8/2015)
the boundaries are 'properly filled' only if the client say so.The person in charge of deliver the software to the client can say it's finished but finally only the client is right.
This is no end discussion, finally almost every developer creates software to satisfy client's expectations. So the client has the final word.
I'll say that a lot of developers aren't actually qualified to determine what the client's expectations are. That's why there's such a thing as "requirements" and use cases. The really big problem (no pun intended) is that things like future scalability are neither posed as a requirement/use case nor anticipated by the developer because of things like schedule pressure (failure on management's part) or a simple lack of knowledge or determination. A lot of developers also violate the scientific method by only testing the happy path if they actually do any testing at all.
--Jeff Moden
September 8, 2015 at 7:55 am
Jeff Moden (9/8/2015)
I'll say that a lot of developers aren't actually qualified to determine what the client's expectations are. That's why there's such a thing as "requirements" and use cases. The really big problem (no pun intended) is that things like future scalability are neither posed as a requirement/use case nor anticipated by the developer because of things like schedule pressure (failure on management's part) or a simple lack of knowledge or determination. A lot of developers also violate the scientific method by only testing the happy path if they actually do any testing at all.
Absolutely, that's also why there are developers, testers, requirement analyst, installers, project manager, account managers, CEO, etc.
In the perfect escenario: Each one must do "their job only" with 100% accuracy/accomplishment and deliver to the next stage with perfection. But we are only humans, and such extremely important fact is the main factor of the problems. No scientific method yet for human obstinacy to keep reinventing the wheel year after year, only changing the name of the processes....
September 8, 2015 at 8:02 am
jhbelalc (9/8/2015)
Jeff Moden (9/8/2015)
I'll say that a lot of developers aren't actually qualified to determine what the client's expectations are. That's why there's such a thing as "requirements" and use cases. The really big problem (no pun intended) is that things like future scalability are neither posed as a requirement/use case nor anticipated by the developer because of things like schedule pressure (failure on management's part) or a simple lack of knowledge or determination. A lot of developers also violate the scientific method by only testing the happy path if they actually do any testing at all.
Absolutely, that's also why there are developers, testers, requirement analyst, installers, project manager, account managers, CEO, etc.
In the perfect escenario: Each one must do "their job only" with 100% accuracy/accomplishment and deliver to the next stage with perfection. But we are only humans, and such extremely important fact is the main factor of the problems. No scientific method yet for human obstinacy to keep reinventing the wheel year after year, only changing the name of the processes....
That's a large part of the problem. Poorly defined jobs and obstinacy (and a few other "anti-traits"). Add all that to some ridiculous schedule requirements and no one is doing anything 100%. That's why folks that take the little bit of time to correctly practice the scientific method have so little code come back as "faulted". They actually know how to do their job and aren't obstinate about it. 😉
--Jeff Moden
September 8, 2015 at 8:12 am
Regardless of how good something performs in initial testing, I always try to find people who are less computer savvy to field test. They do the "stupid stuff": things you would never in a million years think anyone would try. I've found LOTS of things that way, and even then problems would sometimes crop up after deployment to production when several dozen or more people start using it.
My boss had a similar tale. A call center application where he worked suddenly began to randomly crash every so often and they couldn't figure out why. After a great deal of analysis, they tracked it down to one user.
The problem? The guy would get bored and start clicking the "Submit" button just to see how fast he could make the colors change. Effectively he was causing a DoS attack by overloading the system with bogus submissions.
Did it work? Yes. Did it meet client expectations? Yes. Was it done? Nope.
I was watching one of those behind-the-scenes DVD documentaries for Star Wars: Attack of the Clones some time ago, and the guy who was in charge of sound (can't remember his name offhand) made the comment: "movies are never finished: they escape." His point being that movies are a creative process and if you wait until everything is technically 100% perfect, you'll never release the movie. You do the best job you can have given your time and budget constraints and then off it goes into the theaters.
Producing software is a creative process very similar to that. You do the best you can (which includes testing) given your project constraints and release it to production with the knowledge there's probably something you forgot, something that may not work as well as you'd like, someone who will find a bug you never imagined could be a problem, or any number of other things. Then you deal with them.
It's probably better to think of it as a creative, iterative cycle rather than just an assembly line to get it out the door.
____________
Just my $0.02 from over here in the cheap seats of the peanut gallery - please adjust for inflation and/or your local currency.
September 8, 2015 at 8:19 am
Jeff Moden (9/8/2015)
Jeff Moden (9/8/2015)That's a large part of the problem. Poorly defined jobs and obstinacy (and a few other "anti-traits"). Add all that to some ridiculous schedule requirements and no one is doing anything 100%. That's why folks that take the little bit of time to correctly practice the scientific method have so little code come back as "faulted". They actually know how to do their job and aren't obstinate about it. 😉
Ok 🙂 your final paragraph drives us directly to the title of this post "The Scientific Method" applied by developers will make their job better. I agree with that too.
My initial point that I still keep, is that the scientific method is not "THE invention" of humankind, it's just some steps to do things better.
Viewing 15 posts - 1 through 15 (of 24 total)
You must be logged in to reply to this topic. Login to reply