From Coding Horror:

For as long as I’ve been a software developer and used bug tracking systems, we have struggled with the same fundamental problem in every single project we’ve worked on: how do you tell bugs from feature requests?

It’s an insoluble problem. Furthermore, I think most bug tracking systems fail us because they make us ask the wrong questions. They force you to pick a side.

It’s an interesting question, being a programmer for so long I can’t help to think that users just don’t care (as Jeff points out) about the distinction, but worst, users don’t care of the trouble. Software Engineering is a relatively new field of work, and methods are not quite well established. It’s unthinkable for someone to ask a building contractor to move a wall after the plaster has been set and painted, however, that happens all the time with software development (or more exactly in my limited experience, with web development). Specifications are often forgotten by both parties, and it’s our duty as developers to try to at least have a good solid set of rules in order to start developing.

From Coding Horror:

The longer you write programs and the older you get, eventually you come to realize that in order to truly succeed, you have to write programs that can be understood by both the computer and your fellow programmers.

That’s a very good piece of wisdom. I’ve been following Jeff’s blog for some months now, and I think most of his posts are very interesting, in a “programmish” kind of way. I find this one in particular very good, being a programmer for 14 years I’ve seen a lot of colleagues, specially new ones fresh out of college to program in a very academic kind of way, full of semantic tricks and always trying to use cutting edge technology. Frequently their code is apparently good, but in time serious flaws begin to surface, from simple things like not checking a string for null, to slightly bigger problems, for instance the realisation on the eve of launch that that person has completely missed the purpose of every aspect of the transaction control framework that we were using, down to the point where the freshly built pages were completely useless unless you followed a very specific navigation path.

However, what really cought my attention was the next paragraph:

Of all the cruel tricks in software engineering, this has to be the cruelest. Most of us entered this field because the machines are so much more logical than people.

Where he links to a post titled In Programming, One Is The Loneliest Number, from where I extract the following quote:

Like many programmers, I was drawn to computers as a child because I was an introvert. The world of computers– that calm, rational oasis of ones and zeros– seemed so much more inviting than the irrational, unexplainable world of people and social interactions with no clear right and wrong. Computers weren’t better than people, exactly, but they were sure one heck of a lot easier to understand.

Well, I’m not sure about me, but I’m reasonable sure of the “introvert” and “unexplainable world of people and social interactions” and completely identify myself with this view. Sometimes I joke with my friends to not let their children play with computers too much, because this is an hell of a life that no one should be forced to have, but at least I do understand what the compiler is trying to accomplish… well, maybe not when I’m with C#…

And now, back to the calm, rational oasis of ones and zeros…

From code.flickr:

A few weeks ago we released a version of the Flickr site tailored specifically for the iPhone. Developing this site was very different from any other project I’ve worked on; there seems to be a new set of frontend rules for developing high-end mobile sites. A lot of the current best practices get thrown out the window in the quest for minimum page weight and fastest load times over slow cellular connections.

Here are a few of the lessons we learned (sometimes painfully) while developing this site.

Interesting details to pay attention…