Principal Software Engineer at Grass Valley, A Belden Brand
In a sense, your colleague has it right. Software is an example of production via prototype replication. We create the original, replicate it and distribute the replicas. However, I doubt that's what he meant.
He probably thinks of a prototype as something that demonstrates some attributes of the real thing but not all. If this is his definition then he is missing that what is delivered at the end of the sprint *is the real thing*.
In the late 80's and into the 90's we learned that sw prototypes were relatively expensive compared to the real thing. HW prototypes usually serve their purpose at much less cost than creating a real thing. Not so for sw. Also, too often the sw prototype seemed close enough and was shipped. The quick-n-dirty code lacked non-functional features and was costly in the long run.
This ties into the value of documentation. If prototypes were expensive, why not just document what the product will look like and then build it? Well, turns out we are not so good at describing a software product on "paper." We can do screen-shots and such but over time we realized that documenting the product was less useful than prototyping and almost as expensive (or even more expensive).
As much as we wish we were effective at validating the product on paper, we cannot seem to do it. We have to create a functional program to validate it. We learned that developing something that is functionally close, but lacking non-functional characteristics, was too expensive. We have to build it right the first time (ironic, eh?). Since we have to go to the extent of meeting both functional and non-functional requirements, we had better make sure we are building the right thing. Thus, we build it in small functional steps that are implemented well. Theoretically, we should be able to come up with something more efficient but every attempt as been less efficient or ineffective (or both).
He probably thinks of a prototype as something that demonstrates some attributes of the real thing but not all. If this is his definition then he is missing that what is delivered at the end of the sprint *is the real thing*.
In the late 80's and into the 90's we learned that sw prototypes were relatively expensive compared to the real thing. HW prototypes usually serve their purpose at much less cost than creating a real thing. Not so for sw. Also, too often the sw prototype seemed close enough and was shipped. The quick-n-dirty code lacked non-functional features and was costly in the long run.
This ties into the value of documentation. If prototypes were expensive, why not just document what the product will look like and then build it? Well, turns out we are not so good at describing a software product on "paper." We can do screen-shots and such but over time we realized that documenting the product was less useful than prototyping and almost as expensive (or even more expensive).
As much as we wish we were effective at validating the product on paper, we cannot seem to do it. We have to create a functional program to validate it. We learned that developing something that is functionally close, but lacking non-functional characteristics, was too expensive. We have to build it right the first time (ironic, eh?). Since we have to go to the extent of meeting both functional and non-functional requirements, we had better make sure we are building the right thing. Thus, we build it in small functional steps that are implemented well. Theoretically, we should be able to come up with something more efficient but every attempt as been less efficient or ineffective (or both).
- Like (2)
- Reply privately
- Flag as inappropriate
- 2 days ago
Leo R., Steve B. like this