Writing requirements is hard. Rarely is enough thought put into them, and even when a lot of time is spent, gaps are inevitable. Thus the most important feature to build into a system’s architecture at the beginning is the ability to change. Without that, all other features will quickly become obsolete.
Does anyone else have a hard time finishing a project? I suspect it’s a common theme among developers. At the beginning, a project is fresh and new, and it’s fun setting up new tools, cleaning the slate, and getting that first prototype up and running. But as time goes on and the needed features pile up, excitement wanes. Your clean initial bits of code have been cluttered by refactoring and redesign as requirements evolved and unexpected complexities emerged. What was once new is now routine when you’re adding feature 42 of 50, and by the time a task is 90% done, you’re tired of looking at it and desperate for something different.
You’re not alone in this feeling; it’s a well documented phenomenon across a variety of creative disciplines. But fight that tendency, my friends, and push through, because a finished imperfect project is better than a perfect unfinished one.
My theory is that the inability to finish is a combination of the 80/20 rule, unavoidable code rot, and the Creator’s Curse. Naming these issues is the first step to mitigating them, so don’t be afraid to call them out when you see them, both on your team and especially in your own work.
I know personally it was a barrier to getting this blog going again, and it’s a problem I still fight. Am I totally happy with this post? No, not really (writing it while trying to listen in on a teleconference doesn’t help). But I’m clicking publish anyways.
Yesterday we looked at how theology can inform software development, today we consider physics. The second law of thermodynamics states:
The total entropy of an isolated system can only increase over time.
This statement has a specific technical meaning which is worth investigating on its own merits, but the general principle is that systems tend towards decay. Software systems are no exception to this rule, variously described as software entropy or code rot. Anyone who has worked with software for any length of time knows firsthand how clean code quickly devolves into spaghetti.
How can one combat this seeming inevitability? The key lies in the second law and the little phrase “of an isolated system”. Essentially entropy can be held steady or even reversed in a system if it is properly influenced from outside that system. In the world of software this means that every time a change is made, one should not just do the minimum required to implement the change, because any edit likely increases entropy. Instead the developer must go further to leave the code better than she found it (what Uncle Bob described as the Boy Scout Rule). The best developers work to make this second nature.
Yes this takes more time in the short run. But it’s essential to the long-term health of a software system.
Last night I was reading an article on characteristics of a good startup, and this nugget jumped out at me (it was originally said by Marc Benioff):
People overestimate what you can do in a year and they underestimate what you can do in a decade.
Software folks tend to be impatient for success, perhaps fueled by seeing the lucky few like Mark Zuckerberg who achieve near-instant greatness. The temptation of moving around to chase pay increases is also ever-present. And it’s really easy to get tired of a particular project at about the 80% complete mark and leave it unfinished (that’s worth a post all its own).
However, great products and great companies almost always take time to develop. And deep satisfaction awaits the person who, through years of toils, takes an idea to completion or builds a fantastic engineering culture. When I was (finally) looking for a change after 12 years at one place, why did I turn down offers from the typical dream companies? Because they’re essentially solved problems, and the chance to make a long-term transformation is minimal.
My current workplace is far from perfect. Without a doubt it’s been more challenging than I expected since I started 3 years ago. But I’m learning to be patient. There’s no guarantee of success, but if it comes, I know it’ll be more satisfying than if it had come quickly.
It reminds me of a story I heard from Andrew Peterson of the designers of Central Park. Told briefly, the folks who planted those first trees knew they would never even see the fruits of their labor, since a generation had to pass before their landscapes could mature. But what a result it was! That kind of patience inspired a great song and it inspires me as well.
Sidenote: the title of this post comes from a book I snatched from the free table outside the library at Judson Baptist Church in Nashville. I highly recommended it (the book, not the church).
Typically when a software person says he is “full stack developer” what is meant is “I can do UI, business logic, and databases.” All well and good, those kind of folks are important to have around.
But there’s another dimension to development that I consider even more useful. Let’s call it the “life-cycle stack”:
“I can write requirements, design, implement, test, deploy, and maintain.”
An engineer who can do everything across that spectrum is tremendously valuable.