Passionate Programmer - Programming as an art

[Pedro Fracarolli]

Some programmers often regard programming as an art. They develop software because they have an urge to create things, like all artists. Moreover, they want to express themselves through software development.
However, an artistic programmer often faces the dilemma of belonging to an organization. The organization's objectives are often priorized over art, thus making the artistic programmer unhappy with his work. He doesn't want to fix bugs in the customer's code base; he wants to put his imagination at work.
In the company side, the software created by the programmers must deliver value to the customer. It doesn't matter how beautiful is the code, the only important thing is whether the software can improve the customer's competitiveness (and thus justify the big amounts of money that he's been putting on development).
The question is: how can we solve such conflict if interests? Is there any way to bind the artistic aspirations of the passionate artist to the organization's objectives? Or, more directly: could art become competitive in its entirety?

Thanks.

Pedro.

[Chad Fowler]

Hi Pedro. I used to be a professional musician. I made the switch to software because I was excited about creating software. I practice programming just like I practiced music. So I get what you're talking about.

But your points about having to deliver valuable functionality that makes a business run are well taken. I think that makes Craft a slightly better metaphor for what we do than Art. Woodworkers, potters, writers, etc. are all craftspeople who blend an art with the business of creating something functional. There may be lessons in how they approach these problems.

It's true that ultimately the internal quality of code is irrelevant to the business for which it's created. What is relevant (and on this topic) is whether the code performs well, is easy to maintain, is "free" of bugs, and so on. As experts, we know that the internal quality of the code is what drives those real business factors. So it's up to us to practice our art/craft in such a way that doesn't sacrifice its integrity but such that the business for which we're working understands the real benefits of a job well done. Don't try to communicate with a business person about the "beauty" of your code. But your defect rate, productivity, etc. are all things they can understand.

As for how to always do challenging and interesting work, I have two perspectives on that. The first is that my book (and my career) are about how to constantly put myself in situations where I can do interesting and challenging work. To me, that is the definition of career success: making it possible to love your career.

On the flip side, even the most mundane work can be done in such a way to make it interesting and challenging. It's all in how you approach it.

[Katrina Owen]

What about specializing in prototyping? Creating and iterating over high-fidelity prototypes is a niche area in programming that takes a special skill set. It is fast, it is creative, it doesn't worry about bugs and error handling.

Doing prototyping right can save a company hundreds of thousands of dollars.

I would recommend taking a look at the book Inspired: How to Create Products Customers Love by Marty Cagan for an excellent discussion of product development and the role that prototyping has in that.

Had to edit to say: I don't like prototyping, so I'm not speaking from experience there (I get a kick out of writing automated tests. Go figure) - but I have two colleagues who are awesome at prototyping, and seeing them create is mind-bogglingly cool.

[Ilja Preuss]

It's not exactly "programming as an art", but you might still be interested in the recent Software Craftsmanship movement: http://manifesto.softwarecraftsmanship.org/

[Tim Holloway]

Chad Fowler wrote:
It's true that ultimately the internal quality of code is irrelevant to the business for which it's created. What is relevant (and on this topic) is whether the code performs well, is easy to maintain, is "free" of bugs, and so on.

Since performance, reliability, and maintainability are my primary definition of internal quality, what's left to be irrelevant?

[Chad Fowler]

Tim Holloway wrote:
Since performance, reliability, and maintainability are my primary definition of internal quality, what's left to be irrelevant?

Are you sure "definition" is the right word? I'd call those "measures" of quality, and that's kinda my point. When I say internal quality, I mean stuff like the cleanliness of the code or the "beauty" of the code. The things we software craftspeople concern ourselves with which business people never seem to understand the importance of.

[Tim Holloway]

Ah, semantics. I'm generally not in favor of the bipolar mode of thought that infects so much of our age, but when it comes to RAS - Reliability, Availability, Servicability, I'm not over-generous myself, so I don't consider that a metric, but rather a standard. Just as I make the distinction between a dishwasher door handle that lasts the life of the appliance and something that has to be replaced on an annual basis - but I'm not going to mention brands that claim more quality than they display. Usually when a system fails, the boss doesn't want to hear about it only "slightly failed".

My own experience - and that includes a fair amount of OS-level internal code, which has pretty tight restrictions - is that quality code is beautiful code. Edsger Djikstra wrote a book on that concept, in fact, but I came to my own conclusions even before I owned a copy of it. A true craftsperson is a craftsperson in all things. You can't sweat the details selectively and expect good results.

It never ceases to amaze me. In art, "hacking" is something that you do e.g., with an axe. The results are unpolished and crude. A good artist can achieve remarkable results even with the crudest tools. But a good artist is also capable of more polished works. Only in computers can the work "hack" be considered to be the pinnacle of praiseworthiness.

[Leandro Coutinho]

well... I think beautiful code results in better software.

[Chad Fowler]

Leandro Coutinho wrote:well... I think beautiful code results in better software.

Certainly. Most of us do. But we're programmers and it's our job to know and care about this. It's not the job of a non-programmer business client to care about our code. So we have to frame the results of this beauty in terms they can understand and appreciate.

[manuel aldana]

I think software development is a great mixture of art (creation, ideas, vision) and craft/engineering (following principles like refactoring, test-automation, iterations).

[Chad Fowler]

manuel aldana wrote:I think software development is a great mixture of art (creation, ideas, vision) and craft/engineering (following principles like refactoring, test-automation, iterations).

Speaking as an artist (a musician) I'd say that refactoring, automation, and iterative creation all apply equally well to art.

I agree with you. We should choose whatever metaphor makes us more creative and whatever discipline from which we can draw inspiration and years of learning. In that way, software development is also sport, game, entertainment, and communication.

[arulk pillai]

It also depends on where you work environment, work culture, and processes followed. Sometimes you do not have luxury to treat it like an art. IMHO, it is a mixture of both.

[Tim Holloway]

Chad Fowler wrote:So we have to frame the results of this beauty in terms they can understand and appreciate.

Unfortunately, that generally means that the system performs reliably, efficiently, and is easy to service. Hmmm. I think I'm singing a refrain here.

The problem is, since the infamous "All You Have to Do" concept (Verse 1, reprised) comes in even before the orchestra starts tuning up, there's rarely appreciation shown for a good-quality product, even though far too many systems are demonstrably anything but.

Software development is full of paradoxes,

[manuel aldana]

Chad Fowler wrote:

manuel aldana wrote:I think software development is a great mixture of art (creation, ideas, vision) and craft/engineering (following principles like refactoring, test-automation, iterations).

Speaking as an artist (a musician) I'd say that refactoring, automation, and iterative creation all apply equally well to art.

I agree with you. We should choose whatever metaphor makes us more creative and whatever discipline from which we can draw inspiration and years of learning. In that way, software development is also sport, game, entertainment, and communication.

I also play guitar for quite a while and think music has its craft bits also (of course to a much lesser degree as other professions). The technique of moving fingers or playing in a band with tight rhythm takes quite a while and needs a lot of practice

I think the most challenging and therefore interesting professions are the ones which combine arts and craft.

[Billy Tsai]

do we need to apply design patterns (including solution architecture) all the time to be artistic?

[Ilja Preuss]

Billy Tsai wrote:do we need to apply design patterns (including solution architecture) all the time to be artistic?

Isn't that like asking a musician "do we need to play harmonies all the time to be artistic?"

[Hong Anderson]

Billy Tsai wrote:do we need to apply design patterns (including solution architecture) all the time to be artistic?

Do you know why do we have patterns? Because we don't want to find a solution to the same problem again and again.

Patterns are similar to mathematics formulas, like we can calculate area of a rectangle by multiplying its width and height. We don't need to rediscover the formula every time we want to calculate after we know the formula.

I cannot think of how knowing some formulas make us artistic.

[Hong Anderson]

About question of this topic, make it happens, make it beautiful and satisfy customers at the same time, it's our job.

[Tim Holloway]

Kengkaj Sathianpantarit wrote:

Billy Tsai wrote:do we need to apply design patterns (including solution architecture) all the time to be artistic?

Do you know why do we have patterns? Because we don't want to find a solution to the same problem again and again.

Patterns are similar to mathematics formulas, like we can calculate area of a rectangle by multiplying its width and height. We don't need to rediscover the formula every time we want to calculate after we know the formula.

I cannot think of how knowing some formulas make us artistic.

A software "formula" is an algorithm. One of the distinguishing things about algoriithms is that they can be compiled into libraries and plugged in as "black box" modules by persons whose knowledge of their internal workings is minimal. Every manager's dream, since it reduces software development to unskilled manual labor wit a fixed price and duration of implemention.

The emergence of the concept of design patterns is a relatively recent thing, although I began to notice a certain sameness to my code productions back in the '80's when I was implementing C++ classes and variations of the Iterator pattern kept showing up in my work.

A pattern is more of a form, like a sonnet or a haiku. The framework and rules are rigidly defined, but the implementations are up to the composer.

[Hong Anderson]

Actually patterns are solutions that happens again and again, so we call it "patterns".

It's usual that somebody might create a solution that is exactly the same with some design pattern, design patterns are nothing new, they are just collection of solutions that have already been discovered, used, applied. GoF just name and document into Design Patterns. They don't create even a single pattern.

[Lee Kian Giap]

First, I attest that there is not much of artistic in programming, the art for programming in my dictionary merely means how good is the code can be expand and maintain.

do we need to apply design patterns (including solution architecture) all the time to be artistic?

design patterns ? Do you have experience using design pattern in complex software development with frequent changes in business rules ? (For example, Insurance software with underwritting guideline which change all the way)

I confirm that it is totally not related to the word "artistic" !!! Don't because of a word "Design", to judge that it is for artistic programmer to play around with. As Kengkaj Sathianpantarit mentioned, patterns are solutions that happens again and again, so we call it "patterns".

I can attest, if one programmer go through a full development cycle on a messy code with no proper design, having nightmare to maintain and expand it, and that programmer pick up a design pattern book and study, he/she will get the feeling of "Eihh, if I know Design Pattern earlier, I should have use this pattern on that code. Yahhh, that pattern is for this code. So I won't struggle now to modify code. And the code won't tied together, changing one part of code affect all other part which cause collateral error"

A programmer who know Object Oriented Philosophy very well but without knowing Design Pattern will still produce unmaintainable and non-flexible code. Therefore, Design Pattern is a MUST in software development, or better said for Software Company which can foresee the expandability on their product and thus on their business, and I don't see there is any conflict of interests. To forcefully talk about conflict of interest, the only difference is how good a programmer with the skill for implementing design pattern, and thus it is related to how good is the programmer does the Company employed to work in your team ... so, if you are in a team that think that programming is just "for, loop, if...else", then don't think about having design pattern and thus don't think of having expandable and maintainable code, prepare for nightmare. On the other hand, if you work with good development team (I will said with design pattern, testing framework, versioning control, autobuild ... not just using but using it with the correct practice), then you will gain a rich experience which worth for programmer career life !

I don't expect customer to understand why we doing this , but at least I expect a good Software Company to understand that writing good code is actually helping them to grow their business !