Over the many years I've been in software, trends have come from out of nowhere and become mainstream and themselves been replaced with new trends.
There was the object-oriented jihad against the infidels of (even good) procedural programming. Then there was the writing solid code/code complete movement of defect reductionism and root cause analysis which eventually begat an evidence-based movement, while being eclipsed initially by an extreme programming discipline. Which then begat test-driven development and behavior-driven development, which coexisted with the great battle of waterfall vs. agile. All the while the Gang of Four were using patterns to find a Quality without a Name, and standard language for describing the pretty pictures was unified. And now, software craftsmanship and SOLID principles, all combined with an healthy injection of inversion of control containers, continuously integrating software to save the world.
I think at some point talking about programming got more interesting than building great software.
Ultimately, all those techniques, strategies and tactics, all the talk and methodologies, the architectures and patterns and practices: they mean nothing. The systems produced (both within software and around the software) either live or die. They may live for decades until quietly disappearing or they may be killed suddenly and dramatically before birth.
I was reflecting recently with coworkers on a system I helped build with a very small team (two programmers, two experts - our own Gang of Four). This software has lived now for over 12 years, providing a crucial operational system for a company I am no longer involved with. I would estimate its value in millions of dollars over that time. Like any child, it cost a lot of money to modify upgrade and maintain, many programmers and support staff, all putting a lot of love and frustration into the product. But like all successful software, it provided a tremendous value. It's gradually being decommissioned to be replaced with COTS software which has its own failings (and costs).
The love we put into that software was not love for the program - it wasn't terribly lovable code, nor was it sexy or exciting as code goes (although all programmers find joy in code). It wasn't love for the company - the business wasn't terribly compelling, nor would it change the world. I'll admit that I always thought that it was important to preserve the integrity of the system - that loyalty to the principles the software was founded would result in a successful product if those principles had value and the system embodied those principles.
But the system was not something one could interrogate to understand its purpose in life - we imbued it with life, there must have been something providing those principles. Sure, we were a business and we needed to provide value, but what brought those principles into focus is still somewhat of a mystery to me. Why did the software have a principle that the user should not be made to feel stupid? Why did the software have a no-modal dialogs policy? How much of this came from Alan Cooper? How much of this was important to the software's success and how much was incidental? Why did we have such strong feelings about how the users would interact with the software in as natural a way as possible? To this day, I don't know if this was just something about us, the team?
I strongly believe that there was a spark that the software we were building would help people achieve their goals. Knowing their goals, one only had to make their path to those goals easier and they would also eventually come to love the software, and own the future of that software. Because building software is about building things for people and when you make something for a person which adds something to their life, that is programming with love.
No comments:
Post a Comment