http://lemire.me/blog/archives/2007/02/04/why-building-software-is-hard/ Computer Scientist and Open Scholar: Databases, Information Retrieval, Business Intelligence. Wed, 23 May 2012 02:45:26 +0000 hourly 1 http://wordpress.org/?v=3.3.2 http://lemire.me/blog/archives/2007/02/04/why-building-software-is-hard/comment-page-1/#comment-49392 Aani Tue, 10 Jul 2007 17:25:16 +0000 http://www.daniel-lemire.com/blog/archives/2007/02/04/why-building-software-is-hard/#comment-49392 My comment to developers has been that if they see their job as to simply implement what’s on the card, their job might as well go to the cheapest offshore supplier My comment to developers has been that if they see their job as to simply implement what’s on the card, their job might as well go to the cheapest offshore supplier

]]> http://lemire.me/blog/archives/2007/02/04/why-building-software-is-hard/comment-page-1/#comment-49163 Paul Meagher Tue, 06 Feb 2007 00:13:38 +0000 http://www.daniel-lemire.com/blog/archives/2007/02/04/why-building-software-is-hard/#comment-49163 I agree with your post. I think alot of the misunderstanding arises because people equate software development with project management where the cardinal sin is not to meet the deadline. IMO, this should be replaced with a "quest for value" where software developers and other stake holders communicate regularly about whether the feature set is sufficiently rich, coherent and debugged enough to trigger it's roll out. It is a process that needs a certain amount of open-endedness to produce the "value" that all parties are ultimately "questing" after and will "discover" when the project starts to to come together. The metaphor of a "quest" is probably more descriptive of the software development process than the metaphor of a "project" governed by deadlines. I agree with your post. I think alot of the misunderstanding arises because people equate software development with project management where the cardinal sin is not to meet the deadline. IMO, this should be replaced with a “quest for value” where software developers and other stake holders communicate regularly about whether the feature set is sufficiently rich, coherent and debugged enough to trigger it’s roll out. It is a process that needs a certain amount of open-endedness to produce the “value” that all parties are ultimately “questing” after and will “discover” when the project starts to to come together. The metaphor of a “quest” is probably more descriptive of the software development process than the metaphor of a “project” governed by deadlines.

]]>