What If Productivity Isn’t About Delivery? What If It’s About Learning?

If software development isn’t construction, and isn’t manufacturing, and isn’t “delivery”, then what is it? And what does it mean to be “productive” at it? I’ve long thought of software development as essentially a learning process. It’s primary product isn’t code or features or executables – those are secondary byproducts. The primary product is KNOWLEDGE. What did we learn about the problem? What did we learn about the technology? What did we learn about the design? What did we learn about the process? What did we learn about each other and how we work together? We get the most meaningful feedback from releasing working software into the world, but we mistake that for the gold and miss the real gold in the feedback we get from it. And when you look at software development that way, it becomes a whole different ball game. The dominant conceptual models of software development coming from systems theory focus on batch sizes, bottlenecks, queues and maximising the “flow” of “value”…

Commenting on Bubbles has been removed. Why? If you want to talk about this post, write to the author, use the comments on their blog if it has them, or reply with a "RE:" post on your own blog. Suggestions? feedback@bubbles.town