19.9.14
17.9.14
Creating ISO images from a folder in OSX
https://berther.io/2008/12/14/creating-iso-images-from-a-folder-in-osx
16.9.14
The Diva Discussion in LinkedIn
I found this topic in the recent discussion in LinkedIn very interesting:
And I especially agreed with what Thad Scheer said and would like to share here for future references:
This is my comments.
And I especially agreed with what Thad Scheer said and would like to share here for future references:
This is my comments.
12.9.14
What is Agility?
I really like the Agile Manifesto:
Individuals and interactions over Processes and tools
Working software over Comprehensive documentation
Customer collaboration over Contract negotiation
Responding to change over Following a plan
That is, while there is value in the items on the right, we value the items on the left more.
To me, being Agile is a very natural thing: to develop successful software products. And I define successful software products in a very simple way:
- A software product can be sold, and continuously sold successfully.
Although this is not applicable to open source software, but I still like it.
Subscribe to:
Posts (Atom)
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