Is programming really art?

Disclaimer: I love programming.

 The other day Meza went to great length discovering the nature of programming. His conclusion is that programming is art.

I beg to differ.

 I don't think carpenters and painters are the same. Neither are musicians and programmers. Silence and a problem to be solved are not the same. A painter wants to say or to show something, and then the audience can decide whether or not they like it. A programmer is presented with a problem, and they go about solving it. It's not an empty canvas, it's not what the programmer has to tell the world. There is nothing artsy about it. It's creative, it's rewarding, but it's not art.

There is however a great deal of craftsmanship involved. Now. Not all crafts are the same. A plumber for example is pretty much bound by the way a pipeline can run, by the placement of the bathtub or the mainline. He has quite little room to maneuver. A carpenter on the other hand only has to make sure that the table's surface more or less flat, or not even that.

A programmer is as free as it gets. Software is called soft for a reason. Not a single element of the program to be written is bound by anything other than the programmer's mind. And now you might think I'm exaggerating. Think again.

The greatest thing about being a programmer is that you can solve a problem literally in thousands of ways. You can even create your own tools while at it. I know of no other craft that you can say the same about. And that's why I love programming.
Read full post...

The true cost of any given feature

There is a new wave of discussion lately in the evergreen topic of estimates and planning (e.g. #NoEstimates). But all sides seem to agree on the motivation for estimates, they just want to answer the need by different means. The need namely is to know the cost of any given development. The return of a feature is then estimated on the business side, and if cost < return then we should implement it. The cost of maintenance is very rarely considered seriously, even-though we all know that maintenance can cost just as much as development. But it's not what I'm getting at. My problem is that the unconsidered cost is usually much higher than what you would typically assume as the cost of maintenance. Any additional cost varies greatly depending on how well the feature was

• concepted
• implemented
• documented
• communicated  

Here is how it usually goes down:

You have a huge application, with tons of interrelated features. And/but the customer/product manager has yet a new idea about a relatively small enhancement that would make the customers' lives much easier.  (You know it's small because you hear phrases like "It shouldn't take more than a day", "It's just an extra checkbox that we can even hide optionally". ) It gets specked out. It turns out that it's not that simple because many surrounding feature, that seemed unrelated at first, are interfering. The effort start to seem more like 10 days now. This is an important moment because you have to make a choice: 

• Option A: you go ahead and do it anyway
• Option B: you build lots of limitations around the new feature as to protect it from all the interference that would screw up the initial estimation

The problem with Option A is obvious: you mess up the original equation of cost < return. So you are left with Option B, and now you are in real trouble, because you didn't even notice, you just got into trouble.

The trouble is that a half-baked, poorly concepted feature is very hard to communicate. The harder it is to communicate, the more questions and complaints you get, typically placing you at the beginning of the loop: "And/but the customer/product manager has yet a new idea about..." And to make everything worse you just added yet another feature to your system, that will once again increase the interference with the next new thing. 

You do this loop enough times and even the really small enhancements will take ages to implement. I wouldn't be in your shoes, man.

Is there a Option C? Think about what that could be? In the next post I want to talk about my Option C.

Read full post...

On the other hand - mloc.js summed up subjectively

Last week the mloc.js was held in Budapest and I was lucky to be there.

The conference for me was about dualities. Well maybe not just for me, as the audience was clearly split into two camps. The Static Camp and the Dynamic Camp. The former's central reasoning could be summed up as 'We know that JS is here for the long haul, but we really like unambiguous syntax'. The latter's reasoning was more emotional: 'If you can't code in JS, go home' :)

It turns out we're running out of stupid words - Crockford

But let's start at he beginning. Mr. Crockford talked about how we need the syntax to be emotional. And I knew I wasn't gonna create a new programming language next week, but on the other hand by the end of his talk I really wanted to. The keynote speech really was a keynote for me, as my mind was split for the rest of the conference.
Orion for example looks quite flexible, on the other hand to have my source files "in the cloud" has this  tingling feeling to it...

 It was interesting to see the all the meta-programming talks, but it was really good to see the purists in action. Juha Paananen, the smart and casual author of bacon.js and Enrique Amodeo, who also spoke about FP and FRP, eventstreams and promises. You could tell that both of these guys have a lot experience and they not only did their home work, but have a real passion for JS.

 Day 2 started with the lightning talks, where you could have a glimpse at how competent(in web develoment) and honest(in relation to their unsuccessful attempts) Prezi - the organizer -  is.

It's not that bad to write JavaScript, guys. We also write CSS - Fisher

Next stop on my duality-journey was Nick Fisher@soundcloud, their struggle with soundwaves made me feel guilty for the thought of just guessing the outline, but then he confirmed that indeed it was what they came up with.

    function(a) { return a; } - McKenna

Finally Brian McKenna tested(no pun intended) my faith in TDD, but the world was back in order the next morning. How this went down I explain in another post. But I should mention that the TDD workshop by  Enrique Amodeo also helped.

As I said this is an arbitrary selection of talks, but to be fair it was a great conference from beginning to end. See you next year.
Read full post...