Zen and the Art of Programming
As a teacher of programming, I come across a lot of new developers that are just like I was earlier in my career. They see software projects as finite things. Something to be built and finished. There are deadlines. There are so many more projects. This mindset leads to a lot of stress and an overwhelmed feeling. How can I get all of the functionality built? It is going to take forever, and I just spent 3 hours on a simple bug that should have taken 5 minutes.
Relax. Software programs are not a finite thing you build and finish. They are more like a living organism that grows and changes over time. They are never done growing, and unlike a real living being, they rarely die. I have software I wrote over 20 years ago still in production. Think of Microsoft Word. A word processing program that has been around since the 80’s. The first version came out in 1983. It is still growing and evolving. Microsoft still releases new versions.
When you view a software system as a living being that grows and evolves it changes your whole mindset. It is not about completing the project. It is about finishing this phase. What doesn’t make phase 1 can come in phase 2. On a side note, you see this evolution in the Software development lifecycle models. The industry used to use the classic Waterfall method. You gather all of the requirements, build every possible feature and then release the product. Done. Finish. Well this didn’t work so well so the industry moved to Agile, where you are never finished. You just release new features every couple weeks. To now, Devops. Where you continuously build, test, and deploy. It is the industry progression of viewing software as a finite object that is built to a living organism that is fed and maintained on a daily basis.
As a developer the sooner you get to this mindset the better. I find it much more relaxing and sustainable. No longer do you need to stress about getting all of the features built and finished. You just focus on today and what feature you want to add today. Each day you make the system better. One day at a time. Progress not perfection. Everyday when you go home you know you software system is better than the day before. Next thing you know, you look back a few months later and it is amazing how many features and pieces of functionality have been added. It is also amazing, given the constant changes in technology and business, how many new features you need to add. All in due time. One day at a time.
I recently taught a beginner C# class. It was 4 weeks long on Tuesday and Thursday nights for 3 hours with one Saturday. I told the students the first night that we would build a full functioning card game application that could play Blackjack, Poker, and War by the end of the class and it would include multiple players and games and remember a players game history. They thought I was kidding. They thought it a noble effort but not something we could actually do. After all they were new to programming and C#. But each day we bit off a new piece of the pie and slower but surely we whittled away. I told them all along not to focus on the whole effort or all the things we needed to do. Each night just focus on the piece we were doing that night. I even told them that maybe we won’t finish it. Maybe it isn’t reasonable. Who cares if we finish. It’s the journey not the destination. Enjoy the ride. Have fun. Focus on just what we need to do today. If we don’t finish today we’ll finish the next class. No worries.
But in the end we did finish at least the initial functionality of the games (Remember programs are never finished. We can always add more to it). And they did enjoy it. They weren’t overwhelmed and stressed by the effort. They enjoyed the journey knowing that if we didn’t finish tonight we would at least make it better tonight. They left the class with a working program but also many more changes they can build to continuously grow and evolve the system.
Since I started viewing software as a living system that grows and evolves everyday. I have learned to enjoy the art of programming much more. Everyday is spent teaching, growing, and learning as I evolve along with the system I am building. It is a journey we are traveling together.
Top comments (4)
I agree completely. There's a lot of pressure to know and account for every corner of a system, and it's just not possible. Even for relatively "simple" systems. I do think there are a lot of situations where leadership treats things this way (out of ignorance, ego, or otherwise). And it can be hard to navigate those situations regardless of your personal mindful approach.
One of my bosses catchphrases (there are many) is "...so we can bring this project to completion." I truly don't know what he means by that, because these projects are always a WIP even if it's just superficial maintenance. I'll have to ask them if "bring to completion" is actually a codeword for "send the client a final bill". That would make way more sense than actually thinking a project is "complete" in some true sense.
With very very few exceptions, "complete" as in not growing just means "dead" as in not used anymore. Languages like C and C++ get updated every decade or so. Protocols like HTTP and TCP/IP continue to evolve albeit much slower. Most successful software continually releases new versions, with no predetermined stopping point. (Which I actually will argue is a huge problem with our industry, and the lack of scope control results in overly complicated software.)
The only exceptions I can think of are things that are elegant because of their simplicity. The syntax of LISP or JSON are probably never going to be modified, because they are "complete" in the Dijkstra-esqe sense that there is nothing left to take away.
Ask if bring completion meant bring to an end and kill the project ;)
You guys are right. The project is never complete. It grows. People get used to good things and want even more. And sometimes what they want is not what they get so there's always some rework to do. The software requirements are hard to capture, especially that both sides use different languages (despite both speaking the same ;)). But it requires some effort on every person (party) included in a project to create an environment that everyone feels comfortable to work at.
So practice Zen and spread the Zen to everyone engaged int the project! :)
I think it is also up to us in the software community to help educate leadership.. Many in leadership are used to projects and building things(i.e. buildings, manufacturing plants, etc.) where there is an end to the project.
Once you apply some analogies people start to understand the difference. That being said though, managers and leaders still have to be able to hold people accountable and manage budgets. A fixed project with a timeline and budget is a lot easy to manage.