features != features

First of all i wanted to comment on a sentence i read often in the past few weeks:

"rather good/reliable work than fast/buggy work"

huh? I do not understand why people always assume creating code fast means having buggy or "not-so-good" code in it's own hands. I think it is more an excuse than really founded science. :D Or i am lousy at reading english and they all mean "not thought through work"?

As more practise you get in a programming language, the faster you are getting to produce standard design patterns, if you created an admin page for inserting and evaluating data more than a dozen times you begin to not think about what you are typing. And if you learned good structures (i mean those codes readable!) you can be sure others know what happens. You have some "ways" to do something, grown and growing... you know, you are learning every day.


Sometimes i have the feeling the letters are passing by... have i really produced that much of (functional) code in such a short period of time? wow. Because previous knowledge floats into the code it is mostly exactly doing what you wanted it to do. This is fast, reliable, extensible and maintainable (ok, we all have our perspective of "maintainable" ;)) code.

But what really is taking some time and where it comes to real thinking is to plan new things, to plan structures/features and how to integrate them well with the other parts of your software. To code it afterwards is not the big task (optimizing it and having clean and lean code is another story).

Most features i see nowadays in software products are "clumpsy", they are not well thought through, just thrown in with basic functionality. Why add it if you can't get it right with the other parts? Customer pressure maybe? ;) This is getting to my final point: do not compare features by their pure existence, compare them by their value. is it easy to understand, is it easy to use, do you need it at all? I am not a fan of overloaded functionality, but, come on, a little bit of thinking can go on. Afterwards you are mostly fixing parts... why not get it right at the beginning?

And those going "over the top" - realize it's the user using your product, not a technician. IMO you can require some basic knowledge or require this knowledge to be learned, but do not require technical skills in day to day use of your product (if it is not targeted to this group of people).

Recently i read a discussion about BBCode and it's usefulness and several people wanting to replace them with WiKi Codes. The BBCode System might not be perfect (it could use more descriptive names) but using WiKi Codes is like introducing a not known language to the user, weird characters for things we have "names" for. Why try to crypt something a user can get from it's name... not to speak about it's implementation into forum software where you have to think about so many possibilities.

Maybe it's just the luxury of ignorance.