September 8, 2015 at 8:40 am
Yes, I understand your point.
September 8, 2015 at 10:04 am
Yes, testing (including testing end user reaction to interfaces) and reworking when the tests indicate it's needed is similar to the scientific method. It won't deliver perfect, proven correct, software except for some pretty simple software, but it's the best we've got at present.
But I don't like the statement "Eventually come up with an explanation that's proved by the evidence" as part of a description of the scientific method, although it's a pretty common misunderstanding. Science doesn't take anything as proven - if it did, we would still believe in Newtonian gravity, space that has an intrinsic Euclidean geometry, and many other things that science now recognises as not correct. The scientific method is about testing hypotheses and either disproving them or devising more tests, understanding that the hypotheses apply in some cases (those that have been tested) but may not apply in others.
Most software is pretty complex, and testing every possible combination of inputs at all relevant degrees of parallelism is beyond our capacity for complex software. If we don't test every possible combination, we don't know it works unless we have used formal methods (logic and mathematics) to prove that if it works for a particular set of combinations it will work for all possible combinations, and that particular combination is small enough for us to test it all. This is usually too difficult to be practical, and it is better to apply some common sense and use formal methods to improve quality and reduce costs rather than trying to use them to reach perfection (and allowing the "perfect" to drive out merely very good adequate solutions). And we often don't know what "it works" means because we have only an approximate requirement, not a precise one. And of course formal methods are upopular because people have all too often tried to do the impossible with them and got burnt. IBM's work with OxPRG is one example of applying common sense and doing it right with a formal method, but I suspect that a properly controlled test-oriented development approach with users involved in determining what should be prototyped would work just as well or perhaps even better for a specific app development as opposed to middleware development.
Tom
September 8, 2015 at 10:11 am
Steve Jones - SSC Editor (9/7/2015)
However the one thing in the talk that was the most telling to me is that something isn't finished until a customer can see it and give feedback.
Great article Steve.
One of the lessons I gained from agile is how important it is to get the product in the hands of the actual end-users quickly. I had an agile dashboard project that didn't go very agiley because the product owner held the product back from the intended end-users until he personally felt it was finished. We were basically doing agile sprints/stories inside a waterfall process. There were lots of subtle negative effects from that:
1. The end-users were left using the old solution for a lot longer than necessary when what we had built, though not final, was a lot better than what they had today
2. Development time was spent on low-benefit tasks simply because they were a condition of release rather than because they were valuable
3. The product was far from final at the time of the release because, shocker, the end-users had opinions that differed from the product owner
4. The product owner felt like agile was slow & inefficient when in reality the slowness & inefficiencies were because we were holding the product back from end-users, waterfall style.
Leonard
Madison, WI
September 8, 2015 at 1:42 pm
This sounds like a good way to actually build a piece of software.
Software isn't science, it's engineering. (And a lot of it is Redneck Engineering...) 😛
September 8, 2015 at 1:50 pm
Jeff Moden (9/8/2015)
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.
And sometimes, only the happy path of what they were modifying. No testing to ensure that everything else still works. (Sorry, an old issue from a previous employer, by a developer who still works there.)
September 8, 2015 at 3:17 pm
For me, in my lifetime, the dishwasher. And I used the scientific method to determine that.
September 8, 2015 at 3:35 pm
jhbelalc (9/8/2015)
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.
Not sure why you need to make that point. I believe that we all agree on that. The point of many of the posts on this article are saying that the scientific method fits very nicely into development and is a whole lot better than the nothing that people frequently use. 😉
--Jeff Moden
September 8, 2015 at 4:08 pm
chrisn-585491 (9/8/2015)
This sounds like a good way to actually build a piece of software.
Software isn't science, it's engineering. (And a lot of it is Redneck Engineering...) 😛
Usually, it's just dishwashing... everyone is just trying to get it off their plate. If they understood the science of how to keep their code from coming back faulted, they'd have more time to engineer it properly. 😛
--Jeff Moden
September 9, 2015 at 8:59 am
Jeff Moden (9/8/2015)
chrisn-585491 (9/8/2015)
This sounds like a good way to actually build a piece of software.
Software isn't science, it's engineering. (And a lot of it is Redneck Engineering...) 😛
Usually, it's just dishwashing... everyone is just trying to get it off their plate. If they understood the science of how to keep their code from coming back faulted, they'd have more time to engineer it properly. 😛
yes
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
December 2, 2015 at 3:16 am
Sadly,
we continue to pile additional caveats and restrictions to our hypothesis and try to force the system to work a certain way.
I see this in unit testing ALL THE TIME. :crying:
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
Viewing 10 posts - 16 through 24 (of 24 total)
You must be logged in to reply to this topic. Login to reply