“Good job for finishing 80% of the project. Now go get some rest because the other 80% is waiting to be done.” I know that you've had that conversation. Nearly every software project inspires the same conversation. As soon as significant development takes place, the scope increases.
There are many reasons for this. Building the software uncovers business process improvements and the software shows a path of opportunity that never existed before the new development. Simply put, you just didn't estimate the real scope of the work. Or maybe the customer changes the whole focus - you still need to include the work you already did, but now there's a whole new whatzit that's now the main selling point of the development.
Or how many times have you heard this one. “I have a great idea for an app and if you build it, I'll cut you in.” I've had conversations with friends and family where, as soon as they learn that I'm a software engineer, they profess to possess the secret recipe for untold riches if only they had someone to build it. Non-coders seem to think that the simplicity they see in their interactions with completed software apps is all it takes to make (and market) the numerous apps they consume. What they fail to understand is just how long these applications take to build and how difficult they can be to implement. And how much real work it is to make something look simple. What we do is magic to some.
Projects of value take time to design, code, test, and deploy. Building software isn't like writing a term paper in college - you can't construct the entire thing in a giant code binge and be content with a passing grade because you convinced one person that you have a tiny corner of a clue. Software has a skadillion moving parts. It has to be a home run or it never makes it out of the dugout. I learn this every time I come up with my own wild idea. I open the IDE, create a project, and start hacking away like Indiana Jones in a South American jungle.
It doesn't take much time before I move on to the next great idea.
Or how about this one? “Hey, this is Jamie in the marketing department. Can you please create a report on the air-speed velocity of our new shipping carrier? The customer needs it Monday.” Of course, this request comes at the last minute on Friday afternoon. You head home for a late night of Red Bull and Pop-Tarts and get the feature coded, tested, and deployed in the wee hours of what has become Saturday morning, salvaging your weekend despite sleep deprivation. Later the next week, you call Jamie to see what the customer thought and get the all-too-common news. The meeting got postponed to next week. “I'll let you know.”
There are always productivity and project management tools that someone who knows little to nothing about writing code thinks will be the solution to all our coding woes. Every company in the industry has said, “Wow, this new IDE/library/tool/gizmo/widget will be a game changer. Software development will never be the same.” As the late Fred Brooks said in his seminal book “No Silver Bullet - Essence and Accident in Software Engineering,” no IDE, library, or tool will ever change the principal rules of software development. The universal principles of time, scope, and resources control the destiny of all projects.
You've probably heard “Here, let me make this simple cosmetic change and push it to production. No need to test. It won't affect anything.” And of course, it affected everything.
Even when your project is up and running, there will be bugs. Or rather, there will always be bugs. Check out Figure 1. This check comes from Donald Knuth, who paid people to find legitimate bugs in the LaTeX project source code. These checks are the prized possessions of the developers they were awarded to. Knuth did this because finding the “last bug” doesn't mean there aren't more.
Being a coder is a great gig. You can work from an office in Hawaii (where shoes are frowned upon), in a bank vault in Central Oregon, or in a high-rise office in the London financial district. You can listen to Metal at 100 decibels or just code away to low-fi. It's your choice. The compiler calls and you listen… And there's always the next project, some interesting quirky little thing to test your creative skills against.
Such is the way of the coder…
