Let’s untether ourselves for a minute from the world of physical goods and try to see software development as a creative problem. Creative problems like designing an interface, writing a novel, inventing a machine, or composing a symphony have much more in common with the challenges of software development than does building a house or manufacturing a car.
Some might argue that software has specifications: design documents, business requirements, visual mockups and so on, which specify a single solution, but they don’t.
From a development perspective, those documents are the problem definition, not the solution. Software can only be specified in code, in the same way that a book can only be specified through its writing. Code itself is nothing more than an unambiguous and complete specification. If business requirements were complete specifications, you’d be able to compile and run them, but you can’t.
Coding is a creative problem. Every time a developer writes code, he is taking a non-deterministic path towards an unknown solution?—?a unique solution that has never been created before. If the work weren’t unique, he wouldn’t need to write it, he’d simply copy and paste it.
Looking at development through this lens, it’s clear that there’s a mismatch between the type of problems we’re facing and the processes we use to solve them today. Even Agile methodologies are still rooted in the flawed construction metaphor. The mismatch between the type of problems we face and the way we choose to model them is responsible for much of the pain, frustration, and absurdity we’ve come to accept as the norm in our industry today.