Monday, October 15, 2012

Software as an Art

I see software as an art. Although it can be used simply a mundane tool to get something to work, that's not what energizes me when working with software. What does excite about it is the art in a beautiful solution, in a nice abstraction, in a great architecture, in a readable and maintainable code.

In spite of seeing software as an art, I've been able to deliver in all the projects I've participated in by making the right prioritizations. After all, it must serve a concrete need and be part of a business, adding some sort of value. However, even then, it's been an art and I'm vested into making it better, nicer, even if it requires some harder work.

The problem, though, is to be in environments where software is just viewed as a tool, where achieving a result is more important than anything else (even if it's totally shortsighted), where getting something done simply annihilates the art behind the software, where achieving the reward for doing something (even if crappy) is more important than doing it well or right.

In these environments, you seem to become merely a cog in a machine of results, because your creativity and your heart are not really that required as long as you solve the problem in any way or form. That shifts software from an art or a craft into an almost mechanical task. That simply kills the joy of software development.

If you have similar view of software, how do you actually cope with this in your work environment? Do you try to shield yourself? Or is there any work environment where software as an art/craft is still preserved? I'd love to know about your experiences.

Post a Comment