é interessante como a internet, blogs e tweets conseguem movimentar certos assuntos e fazer que eles tomem proporções enormes.

um dos assuntos que está sendo recorrente e gerando muitas conversas e opiniões nos últimos dias é sobre o movimento de “software craftsmanship”.

um post que está gerando uma grande movimentação de comentários foi do dan north. o título é “programming is not a craft”. em português seria “programação não é um ofício”.

só pelo título você já deve conseguir imaginar o burburinho que ele está gerando.  ele aborda que o valor do software está no que ele oferece ao usuário,  independente de quão feio ou bagunçado é o código. que somente desenvolvedores apreciam código bonito.
isto é uma verdade. para o usuário final o que importa é realmente se o software atende as suas necessidades.

ele também demonstra o receio, de que de alguma maneira, o movimento de “software craftsmanship” faça que o código seja mais importante que a necessidade do cliente.

“Software Craftsmanship risks putting the software at the centre rather than the benefit the software is supposed to deliver, mostly because we are romantics with big egos. Programming is about automating work like crunching data, processing and presenting information, or controlling and automating machines.
Non-programmers don’t care about the aesthetics of software in the same way non-plumbers don’t care about the aesthetics of plumbing – they just want their information in the right place or their hot water to work. (Although it’s fair to say they appreciate decent boiler controls.)

The thing is, at one level software can be described by the utility it provides. It doesn’t matter how ugly it is under the hood as long as it delivers the goods. A programmer can show beautiful software to another programmer, but that’s where the appreciation stops for software per se.” – Dan North

mas parece que dan north 1) desconsidera os benefícios de um código bem escrito. que o código muito provavelmente 2) precisará de manutenção. que o mesmo usuário satisfeito ao usar o software 3) pensará e desejará novas funcionalidades. e que dependendo do código, estas novas funcionalidades podem levar muito tempo para serem entregues. e que dependendo do código talvez elas nem funcionem direito (em alguns casos nunca funcionarão direito). 

o fato do movimento de “software craftsmanship” incentivar o ofício em nenhum sentido ou momento quer dizer que a necessidade do cliente deve ser colocada em segundo plano.

jason gorman fez um excelente post – “Why Software Craftsmanship Is Not Just About "Beautiful Code".  não sei se era uma reposta direta ao dan north. mas se não for, bem que poderia ser.

jason destaca que o “software craftsmanship” é sobre construir a coisa certa, ou esperada pelo cliente, mas da maneira certa. o resumo de quão bem ele demonstra como o pensamento de dan north está errado é o trecho abaixo.

“Do programmers who dedicate themselves to improving in the technical practices (because programming is a technical practice, in case you were wondering) tend to be blinded to the customer's needs?

To me, that sounds like "musicians who strive to perfect their chops don't play with feeling". And there's absolutely no evidence of that.” – Jason Gorman

um segundo ponto  é que ele mostra como um desenvolvedor que não melhora suas competências e habilidades tendem a desagradar seu clientes mais facilmente.

“What's certainly true is that programmers who don't strive to improve at programming tend to dissatisfy customers by delivering software that is unreliable and expensive to change, regardless of what it does. Sure, the customer may be delighted with the first release - hooray for our side - but considerably less delighted when the bug reports start flooding in and we have to tell them how long a second release is going to take.

Because, you see, all those horrendous legacy systems we end up waist-deep in were once bad jobs of something useful. By delivering buggy, unmaintainable software that the customer could use, we effectively hung a millstone around their necks, and we know from experience that the pain comes sooner than we think.” – Jason Gorman

O que é legal e importante, como comentei no post do dan, é atendermos as necessidades do cliente, mas o mesmo tempo, tratarmos o software como um ofício.

o que você acha? o software é ou não um ofício?

[]s