My analogy is that we are designing bowling alleys. Setting up pins and creating the lanes with the hopes that people will bowl correctly. When a beginner comes along we inflate the bumpers to help them down the lane.<p>Up until today this has been my understanding. But now, after releasing a specific feature to production, I realize the "beginners" aren't toddlers that need a little help getting the ball down the lane... they are actually 900lb gorillas walking in to my bowling alley, finding the stash of 22 pound bowling balls, facing with their back to the pins, and launching them wildly like the first pitch at the world series.<p>What's your analogy to software engineering?
Building software is like building a road through a thick, uncharted jungle. You know where you are, and you know (approximately) where you're going, but there are many many problems to be solved along the way. Do you need to hack through thick underbrush? Is there a hill that needs to be flattened? A river to be bridged? No way to know until you get there.<p>This is also why traditional delivery planning fails. "How long is it going to take to build this road?" "Well, we know <i>roughly</i> how long, be we don't yet know the exact route we will take or the obstacles we will encounter, so we'll report on our progress and let you know when we arrive."
At school, developers dream of creating their masterpiece like Michelangelo sculpting the Pieta. At work, developers realize instead of creating purpose built product they are often tasked with updating, modifying, and configuring a code base which they may not even have all the source code to. Think playing with sets of tinker toys purchased at different times that may not be 100% compatible with each other and some of them are broken.