Opposite of Spherical Cows? Inventor's Paradox
-
Wow, while reading the wikipedia entry for Dependency inversion principle - Wikipedia[^] I stumbled upon... The Inventor's Paradox[^], which states:
From wiki entry:
"The inventor's paradox is a phenomenon that occurs in seeking a solution to a given problem. Instead of solving a specific type of problem, which would seem intuitively easier, it can be easier to solve a more general problem, which covers the specifics of the sought-after solution."
Very interesting, because this often explains why problems take longer than expected to solve. You're actually solving an entire classification of problems. This also made me think about the Spherical Cow[^] solution (kind of the opposite):
from wiki entry
Milk production at a dairy farm was low, so the farmer wrote to the local university, asking for help from academia. A multidisciplinary team of professors was assembled, headed by a theoretical physicist, and two weeks of intensive on-site investigation took place. The scholars then returned to the university, notebooks crammed with data, where the task of writing the report was left to the team leader. Shortly thereafter the physicist returned to the farm, saying to the farmer, "I have the solution, but it works only in the case of spherical cows in a vacuum."
-
Wow, while reading the wikipedia entry for Dependency inversion principle - Wikipedia[^] I stumbled upon... The Inventor's Paradox[^], which states:
From wiki entry:
"The inventor's paradox is a phenomenon that occurs in seeking a solution to a given problem. Instead of solving a specific type of problem, which would seem intuitively easier, it can be easier to solve a more general problem, which covers the specifics of the sought-after solution."
Very interesting, because this often explains why problems take longer than expected to solve. You're actually solving an entire classification of problems. This also made me think about the Spherical Cow[^] solution (kind of the opposite):
from wiki entry
Milk production at a dairy farm was low, so the farmer wrote to the local university, asking for help from academia. A multidisciplinary team of professors was assembled, headed by a theoretical physicist, and two weeks of intensive on-site investigation took place. The scholars then returned to the university, notebooks crammed with data, where the task of writing the report was left to the team leader. Shortly thereafter the physicist returned to the farm, saying to the farmer, "I have the solution, but it works only in the case of spherical cows in a vacuum."
:cough: Scope Creep :cough: Targeting a "general case" can be a slippery slope. It's not always a good thing.
-
:cough: Scope Creep :cough: Targeting a "general case" can be a slippery slope. It's not always a good thing.
PIEBALDconsult wrote:
Targeting a "general case" can be a slippery slope. It's not always a good thing.
* If it's a one-off and you won't have to maintain it and it'll "just work", then just get 'r dun. * But, if you will have to maintain it in the future and the customer will want changes and you'll be endlessly touching the code? Then you better get the general case right. It's a freakin' paradox!! :rolleyes:
-
:cough: Scope Creep :cough: Targeting a "general case" can be a slippery slope. It's not always a good thing.
PIEBALDconsult wrote:
Targeting a "general case" can be a slippery slope. It's not always a good thing.
Besides, agile principles says that you should never, ever, make any sort of preparations for future extensions.
Religious freedom is the freedom to say that two plus two make five.
-
PIEBALDconsult wrote:
Targeting a "general case" can be a slippery slope. It's not always a good thing.
Besides, agile principles says that you should never, ever, make any sort of preparations for future extensions.
Religious freedom is the freedom to say that two plus two make five.
trønderen wrote:
agile principles says that you should never, ever, make any sort of preparations for future extensions.
Which one[^]? :rolleyes: Oh, you probably mean Scrum, right? :-D I only believe in the original Principles, not all the add-ons that were created to allow authors to make $$$. :laugh:
12 Agile Principles
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicity--the art of maximizing the amount of work not done--is essential. 11. The best architectures, requirements, and designs emerge from self-organizing teams. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
-
PIEBALDconsult wrote:
Targeting a "general case" can be a slippery slope. It's not always a good thing.
Besides, agile principles says that you should never, ever, make any sort of preparations for future extensions.
Religious freedom is the freedom to say that two plus two make five.
trønderen wrote:
says that you should never, ever, make any sort of preparations for future extensions.
I kind of like that one. Because the vast majority of time the developer is coding for something that might happen 10 years from now. Versus the much smaller and more reasonable case where they have seen a future Epic already broken down that adds an additional case. Of course the correct path in that case is to modify the current Story/Epic to insure it accounts for the future case.
-
trønderen wrote:
says that you should never, ever, make any sort of preparations for future extensions.
I kind of like that one. Because the vast majority of time the developer is coding for something that might happen 10 years from now. Versus the much smaller and more reasonable case where they have seen a future Epic already broken down that adds an additional case. Of course the correct path in that case is to modify the current Story/Epic to insure it accounts for the future case.
-
trønderen wrote:
agile principles says that you should never, ever, make any sort of preparations for future extensions.
Which one[^]? :rolleyes: Oh, you probably mean Scrum, right? :-D I only believe in the original Principles, not all the add-ons that were created to allow authors to make $$$. :laugh:
12 Agile Principles
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicity--the art of maximizing the amount of work not done--is essential. 11. The best architectures, requirements, and designs emerge from self-organizing teams. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
raddevus wrote:
Which one[^]? :rolleyes:
In theory, there is no difference between theory and practice. In practice, there is. A major reason why I asked to be moved to another project in my last job was that the project leader at several occasions made his corrections to my design, 'we do not have the resources to do that now!'. E.g. we were making a monitor, a minimal OS, for embedded systems, and in my proposal the request code was transferred in a register. The chip had an alternative software interrupt with an 8 bit request code embedded in the instruction. We 'didn't have the resources' to be prepared for more than 256 requests. So the design was changed to use the limited instruction. Less than a year later, the code range was exceeded, and software interrupts had do be rewritten to handle more request codes. I had a couple other very similar issues where I had suggested solutions that allowed for extensions, that were rejected because 'We will cover the needs we have today, and that is it!' - and a year later, the simplified solution from the first round was replaced with my original proposal (or something very similar). The project leader's rejection of more future oriented designs was fully supported by the majority of the development team. Avoid unnecessary complexity! --- As if transferring the request code in a register instead of in the instruction would lead to 'increased complexity'. This is how I have experienced 'agile' software development in practice carried to its extremes. Thinking just a little bit ahead was like swearing in church; everyone who know anything about agility would try to silence you. If you want to attach it to a single one of the principles, it would be 10. Simplicity--the art of maximizing the amount of work not done--is essential. Agile people, as I have met them, tend to live by the first part of Albert Einstein's pronouncement: Make it as simple as possible, fiercely fighting the second part, but no simpler. I think this development group was at the extreme end. Yet I see a lot of the same in other environments. It was prevalent in internet protocols for the first 30 years or so - I wasn't the one pointing out that a lot of the protocols was missing a 'T': SMTP should be named 'TOO Simple Mail Transfer Protocol', SNMP should be 'TOO Simple Network Management Protocol', and so on. (I think SNMP was where I heard about the missing 'T' for the first time, and it immediately ran
-
Exactly… think of all of the software that was obsolete before Y2K so it never needed the updates!
-
raddevus wrote:
Which one[^]? :rolleyes:
In theory, there is no difference between theory and practice. In practice, there is. A major reason why I asked to be moved to another project in my last job was that the project leader at several occasions made his corrections to my design, 'we do not have the resources to do that now!'. E.g. we were making a monitor, a minimal OS, for embedded systems, and in my proposal the request code was transferred in a register. The chip had an alternative software interrupt with an 8 bit request code embedded in the instruction. We 'didn't have the resources' to be prepared for more than 256 requests. So the design was changed to use the limited instruction. Less than a year later, the code range was exceeded, and software interrupts had do be rewritten to handle more request codes. I had a couple other very similar issues where I had suggested solutions that allowed for extensions, that were rejected because 'We will cover the needs we have today, and that is it!' - and a year later, the simplified solution from the first round was replaced with my original proposal (or something very similar). The project leader's rejection of more future oriented designs was fully supported by the majority of the development team. Avoid unnecessary complexity! --- As if transferring the request code in a register instead of in the instruction would lead to 'increased complexity'. This is how I have experienced 'agile' software development in practice carried to its extremes. Thinking just a little bit ahead was like swearing in church; everyone who know anything about agility would try to silence you. If you want to attach it to a single one of the principles, it would be 10. Simplicity--the art of maximizing the amount of work not done--is essential. Agile people, as I have met them, tend to live by the first part of Albert Einstein's pronouncement: Make it as simple as possible, fiercely fighting the second part, but no simpler. I think this development group was at the extreme end. Yet I see a lot of the same in other environments. It was prevalent in internet protocols for the first 30 years or so - I wasn't the one pointing out that a lot of the protocols was missing a 'T': SMTP should be named 'TOO Simple Mail Transfer Protocol', SNMP should be 'TOO Simple Network Management Protocol', and so on. (I think SNMP was where I heard about the missing 'T' for the first time, and it immediately ran
Great story. My take-away is that "Good principles are always corrupted by bad people." In your case, the Boss who has veto power but questionable knowledge nixes a perfectly good feature. Boss has mentioned "Agile" somewhere along the line, so you attach the idea to this error-Boss. Every Principle ever considered has exceptions and vast numbers of people who say the principle is a thing that it is not. So it goes. It's why, in IT, I've learned that my motto is: "Blithely I roll on." (see definitions 2 & 3 below) :-D
wornik dictionary:
blithely adverb 1. In a blithe manner. 2. Without care, concern, or consideration. 3. In a joyful, carefree manner.
-
Wow, while reading the wikipedia entry for Dependency inversion principle - Wikipedia[^] I stumbled upon... The Inventor's Paradox[^], which states:
From wiki entry:
"The inventor's paradox is a phenomenon that occurs in seeking a solution to a given problem. Instead of solving a specific type of problem, which would seem intuitively easier, it can be easier to solve a more general problem, which covers the specifics of the sought-after solution."
Very interesting, because this often explains why problems take longer than expected to solve. You're actually solving an entire classification of problems. This also made me think about the Spherical Cow[^] solution (kind of the opposite):
from wiki entry
Milk production at a dairy farm was low, so the farmer wrote to the local university, asking for help from academia. A multidisciplinary team of professors was assembled, headed by a theoretical physicist, and two weeks of intensive on-site investigation took place. The scholars then returned to the university, notebooks crammed with data, where the task of writing the report was left to the team leader. Shortly thereafter the physicist returned to the farm, saying to the farmer, "I have the solution, but it works only in the case of spherical cows in a vacuum."
After solving a few specific problems in animation, I came to the "general conclusion" that the only things one needs to accomplish the full range of motion for a "shape", is x and y displacement and rotation (in 2D). A general solution has emerged that now drives all the others; "saving" time and mental energy.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
Wow, while reading the wikipedia entry for Dependency inversion principle - Wikipedia[^] I stumbled upon... The Inventor's Paradox[^], which states:
From wiki entry:
"The inventor's paradox is a phenomenon that occurs in seeking a solution to a given problem. Instead of solving a specific type of problem, which would seem intuitively easier, it can be easier to solve a more general problem, which covers the specifics of the sought-after solution."
Very interesting, because this often explains why problems take longer than expected to solve. You're actually solving an entire classification of problems. This also made me think about the Spherical Cow[^] solution (kind of the opposite):
from wiki entry
Milk production at a dairy farm was low, so the farmer wrote to the local university, asking for help from academia. A multidisciplinary team of professors was assembled, headed by a theoretical physicist, and two weeks of intensive on-site investigation took place. The scholars then returned to the university, notebooks crammed with data, where the task of writing the report was left to the team leader. Shortly thereafter the physicist returned to the farm, saying to the farmer, "I have the solution, but it works only in the case of spherical cows in a vacuum."
Is the opposite of a Spherical Cow a Cubecumber?
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated. I’m begging you for the benefit of everyone, don’t be STUPID.
-
Wow, while reading the wikipedia entry for Dependency inversion principle - Wikipedia[^] I stumbled upon... The Inventor's Paradox[^], which states:
From wiki entry:
"The inventor's paradox is a phenomenon that occurs in seeking a solution to a given problem. Instead of solving a specific type of problem, which would seem intuitively easier, it can be easier to solve a more general problem, which covers the specifics of the sought-after solution."
Very interesting, because this often explains why problems take longer than expected to solve. You're actually solving an entire classification of problems. This also made me think about the Spherical Cow[^] solution (kind of the opposite):
from wiki entry
Milk production at a dairy farm was low, so the farmer wrote to the local university, asking for help from academia. A multidisciplinary team of professors was assembled, headed by a theoretical physicist, and two weeks of intensive on-site investigation took place. The scholars then returned to the university, notebooks crammed with data, where the task of writing the report was left to the team leader. Shortly thereafter the physicist returned to the farm, saying to the farmer, "I have the solution, but it works only in the case of spherical cows in a vacuum."
I know a company in India which is moving chips from general to particular. They are designing chips for very specific purposes, almost with that particular instruction set (plus a small delta, maybe). They aim to lower memory and power consumption ... and more importantly, cost.
-
raddevus wrote:
Which one[^]? :rolleyes:
In theory, there is no difference between theory and practice. In practice, there is. A major reason why I asked to be moved to another project in my last job was that the project leader at several occasions made his corrections to my design, 'we do not have the resources to do that now!'. E.g. we were making a monitor, a minimal OS, for embedded systems, and in my proposal the request code was transferred in a register. The chip had an alternative software interrupt with an 8 bit request code embedded in the instruction. We 'didn't have the resources' to be prepared for more than 256 requests. So the design was changed to use the limited instruction. Less than a year later, the code range was exceeded, and software interrupts had do be rewritten to handle more request codes. I had a couple other very similar issues where I had suggested solutions that allowed for extensions, that were rejected because 'We will cover the needs we have today, and that is it!' - and a year later, the simplified solution from the first round was replaced with my original proposal (or something very similar). The project leader's rejection of more future oriented designs was fully supported by the majority of the development team. Avoid unnecessary complexity! --- As if transferring the request code in a register instead of in the instruction would lead to 'increased complexity'. This is how I have experienced 'agile' software development in practice carried to its extremes. Thinking just a little bit ahead was like swearing in church; everyone who know anything about agility would try to silence you. If you want to attach it to a single one of the principles, it would be 10. Simplicity--the art of maximizing the amount of work not done--is essential. Agile people, as I have met them, tend to live by the first part of Albert Einstein's pronouncement: Make it as simple as possible, fiercely fighting the second part, but no simpler. I think this development group was at the extreme end. Yet I see a lot of the same in other environments. It was prevalent in internet protocols for the first 30 years or so - I wasn't the one pointing out that a lot of the protocols was missing a 'T': SMTP should be named 'TOO Simple Mail Transfer Protocol', SNMP should be 'TOO Simple Network Management Protocol', and so on. (I think SNMP was where I heard about the missing 'T' for the first time, and it immediately ran
When I see the term "agile" I insert adaptive. Over the years of software dev. I learned that bottom-up and top-down usually occurs together, in tandem so to speak. One needs a big picture but one must also understand getting there from the bricks. It's natural and wise to plan ahead, but not to an extreme. As the sign says "the future is tomorrow". Also, from time to time, play the user as best as one can. They are part of the target. Don't know what this has to do with Spherical Cows, but dogs run in circles because it is too hard to run in squares.
"A little time, a little trouble, your better day" Badfinger
-
Exactly… think of all of the software that was obsolete before Y2K so it never needed the updates!
-
Think of all of the software that will be obsolete after the year 9999. No time like the present to start coding for that.
-
not our problem… Just wait a few hundred years for Mars Central Time Zone still with daylight saving time! I hate time zones/DST and the fact that US legislators like to change them too often.
