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.
posted by Acyd Burn @ 11/08/2004 05:38:00 pm
4 comments
4 Comments:
This is a good article, although I think that you just removed one excuse that software-developers use. It is always good for the developers to say, that they need more time to fix this and that because they know that the publisher or the final customer will bring the developer under huge pressure until there is a final release.
When I started programming, I tested my scripts after each printf(). Now, I create complex parent and child-classes and write whole programs without testing them in the development. But I would never tell the customer that I already KNOW this works. The customer has to think that designing code is the most difficult thing in the world because otherwise he will stand behind you with a large stick and hit you everytime you exceed the deadline...
thanks Acyd Burn, for removing the last excuse we as programmers have ;)
Remindes me of an interesting quote by Ted Nelson:
"I am a design chauvinist. I believe that good design is magical and not to be lightly tinkered with. The difference between a great design and a lousy one is in the meshing of the thousand details that either fit or don't, and the spirit of the passionate intellect that has tied them together, or tried. That's why programming-- or buying software-- on the basis of "lists of features" is a doomed and misguided effort. The features can be thrown together, as in a garbage can, or carefully laid together and interwoven in elegant unification, as in APL, or the Forth language, or the game of chess."-dhn
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
http://agilemanifesto.org/
-- Sascha Carlin aka itst
As several studies have shown, there are several orders of magnitude of difference between programmers with repsect to how fast they can programm something. So there really is no point in making a general statement where you deride code-quality from time spent.
So when you are saying:
>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 don*t know what "people" are assuming, but when I myself say that, I am thinking "with everything else being the same". If the same programmer (with the same skill and the same experience) sits down and finishes something in 30 rather than 10 minutes (actual time spent with focus on the task), I assume that in the former case the code will in some way be better than in the latter case (of course you can't extrapolate indefinitely).
And then of course there are those infamous nightly coding sessions. You get into a flow and code an insane amount of time without stop and feel like everything is so easy and clear, and everythings coming along perfect - until you go back and look at it when you are fit and have slept well a few days later and find out you did some really horrible stuff. The mind (and body) can play some incredible tricks on you in extreme situations. ;)
With most of the other things you write however, I would agree.
Post a Comment
<< Home