Salvatore Iovene

Thanks to Digg I just found out a cer­tain video on YouTube. Steve Ballmer, Microsoft’s CEO, is asked what he thinks about the iPhone. I won­der how much the MS guys are aware of their image, or con­scious of what they do and say. I’m sorry, I don’t want to be harsh, nor I want to dis­re­spect Mr. Ballmer, whom I don’t know per­son­ally, but his com­ments in that inter­view were out­ra­geously ridicu­lous. Mean­ing that they made me laugh my head off.

First of all, Mr. Ballmer was shout­ing pretty loud, and that’s ter­ri­bly impo­lite. His all line of answer was about mock­ing the com­peti­tor (Apple, in this case) with an eery smile between sar­cas­tic and fright­ened. It’s really an old tech­nique of blab­bers like him: under­min­ing the com­peti­tors’ value, and pre­tend­ing it doesn’t pose a threat at all. He says “That is the most expen­sive phone in the World and doesn’t appeal to busi­ness cus­tomers because it doesn’t have a key­board, which makes it not a very good email machine”. First of all, this is totally and absolutely ques­tion­able. Sec­ondly, the iPhone might be plugged to a blue­tooth key­board. In any case, that doesn’t mat­ter at all. Mr. Ballmer was dar­ing to express his lousy per­sonal opin­ion on the sole obvi­ous pur­pose to under­mine the com­peti­tor. He’s just try­ing to blow smoke in the eyes of the users. I don’t want to start any anti-Microsoft issue here, but it’s def­i­nitely obvi­ous that Ballmer is scared and falling into pathetic attempts to dam­age the competitor.

He then con­tin­ues with “We have our strat­egy, we have great Win­dows Mobile devices in the mar­ket today, you can get a Motorola Q phone now for 99 dol­lars”. He stresses the “99 dol­lars” a lot. Well, if hav­ing low-cost lousy device (which you don’t actu­ally build! It’s a Motorola, isn’t it?) is the only way to keep your share, then be my guest, but I see no sense in mock­ing Apple for the price of the iPhone, and then giv­ing no real argu­ments. It looks like they want to sell their Win­dows Mobile pow­ered (under pow­ered?) devices by the pound. That’s lousy. He con­tin­ues talk­ing about the Motorola Q, say­ing that it’s a very capa­ble machine, it can do music, it can do Inter­net, it can do email, it can do Instant Mes­sag­ing. “So I kinda look at that, and I say I like our strat­egy, I like it a lot”. The orig­i­nal ques­tion he was asked was about the iPhone (which he just mocked for the price) and the Zune (which he didn’t men­tion at all). So the inter­viewer felt about hav­ing to repeat the thing, because it was obvi­ous that Ballmer was kinda afraid of the sub­ject. The inter­viewer asks, talk­ing about the phones mar­ket and the music mar­ket, “How do you com­pete with that?” — and there you can see Ballmer go with a sort of dull expres­sion for a moment — then replies “Let’s start with the phone” (appar­ently he really doesn’t want to go to the Zune) and says that at the moment Microsoft is sell­ing “mil­lions and mil­lions and mil­lions” (how many is that? 3 mil­lions?) of phones, and Apple is sell­ing zero. I’m amused: that was his argu­ment. “How do you com­pete to the iPhone?” — “That’s not a threat”. That was his answer, minus the bull­shit. Then he says again that the Apple iPhone will be the most expen­sive phone “by far” ever in the mar­ket — then smiles — and says “Let’s see”.

Then he finally men­tions the Zune, and says they’ve got 20% of the mar­ket. What mar­ket? The mar­ket of the devices over 249$. That’s not the mar­ket. It’s only a part of it. I don’t know what you peo­ple will think about this, but it gives me the impres­sion that the phones mar­ket is going to shake badly.

By the way, it’s so funny how he goes on and on about the price, when they dare sell­ing a com­pletely bloated Oper­a­tive Sys­tem for 400$ or some­thing, but that’s just my opin­ion.

Besides, Mr. Ballmer prob­a­bly is not aware that when every­thing will set­tle up in one year or so, this video is going to get back at him, and be extremely hilar­i­ous. Good job, Microsoft. On the other hand, what else can you say about this man?

A week ago I stum­bled upon this arti­cle from Stu­art Brown, which actu­ally even got a fair amount of Diggs. As soon as I read it, I felt obliged to reply exten­sively to it, as I think it mostly rep­re­sent every­thing which is wrong in the cur­rent web design trends (or should I say all time web design trends?).

Some­thing that really annoyed me about the arti­cle, was the lack of seri­ous points and the abun­dance of use­less words like “some stan­dards evan­ge­list”, “Obsess­ing over seman­ti­cally cor­rect markup”, “a few stan­dards zealots”, “zealotry accom­plishes noth­ing but a col­lec­tion of smug faces and a col­lec­tion of ‘XHTML 1.1 Com­pli­ant’ bylines”. Those were only fruit­less diver­sions and not real arguments.

The authors gets one thing right, though, and it’s that

your users don’t care about XHTML, they care about how your site appears.

Alright, we all can agree that most of the aver­age Inter­net users com­pletely ignore every­thing about words like HTML, CSS, JavaScript, PHP and so on. We can’t, at these point blame the users: I don’t know any­thing about the inner work­ings of most of the things I use on a dally basis myself, so no big deal. In spite of this, serv­ing the user is not quite equiv­a­lent to fool­ing him. Giv­ing the user some­thing that actu­ally works, but whose inner work­ings are totally crip­pled, is absolutely wrong. The author of the men­tioned arti­cle fur­ther­more says:

If you can sat­isfy the usabil­ity needs of 100% of your users, yet your code doesn’t val­i­date, then arguably you need do no more.

I’m really strong about my dis­agree­ment here. Val­i­da­tion serves a pur­pose: that is to min­i­mize dif­fer­ences when ren­der­ing the web­site in dif­fer­ent browsers. A well val­i­dated page doesn’t need any guess-based cor­rec­tion by the browser. And Stu­art talks about usabil­ity, whereas a web­site that doesn’t val­i­date will have a harder time in meet­ing usabil­ity require­ments for impaired per­sons. On Feb­ru­ary 2006 there was a story about Tar­get (a retailer), being sued because its pages were unac­ces­si­ble by visu­ally impaired users. The retailer was accused of vio­lat­ing the Cal­i­for­nia Unruh Civil Rights Act, the Cal­i­for­nia Dis­abled Per­sons Act and the Amer­i­cans with Dis­abil­i­ties Act. Need­less to say, the web­site still doesn’t val­i­date (it doesn’t even have a DOCTYPE).

So, why else stan­dards (and espe­cially web stan­dards) are needed?

1. Stan­dards make it eas­ier for your browsers to ren­der the pages.

   HTML or CSS are, in a way, stan­dards. I.e. a set of rule, meant as a markup lan­guage spec­i­fi­ca­tion, to be fol­lowed in order to design a web page. On top of these spec­i­fi­ca­tions, peo­ple who write browsers have done their work. Unfor­tu­nately, though, not all devel­op­ers are able to, or care to, be strict regard­ing stan­dards. That means that the browsers must have a way to cor­rectly inter­pret some code even though it’s fun­da­men­tally incor­rect. What’s the result of this? Browsers devel­op­ers have to waste time into tak­ing care of cor­rect­ing the mis­takes of web devel­op­ers. This, in turn, gives web devel­op­ers the chance to relax and write worse and worse code. And this makes browsers devel­op­ers’ life worse, and their work slower. In the end the users get noth­ing but worse and worse products.

2. Stan­dards make life eas­ier for users.

   We can take this off the Web Stan­dards exam­ples, and move to some “real life” cases. Iron­i­cally enough, the other day I was star­ing at my toi­let seat for a while, and noticed that the holes in the toi­let in which you can screw your seat in, are at a fixed dis­tance, and just slightly larger than longer, so to give a lit­tle mar­gin: i.e. if you want to buy a new toi­let seat, the dis­tance between the screws with which you attach it to the toi­let must be between X and X+1 cm. So, when I went to the shop to get a new toi­let seat, I didn’t have to worry about the size. Ven­dors of toi­lets and ven­dors of seat had just agreed on a stan­dard size. The result? No has­sle for the user (me).

3. Search engines like standards.

   Search engines don’t like find­ing errors. If they have trou­ble pars­ing your pages, they may not get to your care­fully cho­sen key­words, won’t be able to find all those tightly focused meta tags. Your site will be crip­pled on any search engine results page. This is not good. A well designed web­site cre­ates a clear chan­nel, a road map, for search engines, so they know to go exactly where you want them to go and see exactly what you want them to see.

End of the list? Yes. This is all that mat­ters, in the end, to the final user. He doesn’t care how, but in the end he gets bet­ter prod­ucts. Of course there are lots of side effects, e.g.:

• Stan­dards min­i­mize the dif­fer­ences in the way your pages appear in dif­fer­ent browsers.
• Stan­dards improve the qual­ity of your code, hence the qual­ity of your product.
• Code that adheres to stan­dards is eas­ier to maintain.
• Val­i­dat­ing your code dur­ing the devel­op­ment process eases the dis­cov­ery of flaws and mistakes.
• Stan­dards increase your value.

Before any­one could say that nobody needs a new arti­cle about web stan­dards, let me remind you that the fol­low­ing web­sites won’t validate:

• www.google.com
• www.yahoo.com
• www.microsoft.com
• www.aol.com
• www.digg.com
• I could go on for hours…

This means that the standards-aware devel­oper are just a tiny minor­ity. The rest, obvi­ously, don’t think that qual­ity is a good asset for their web­sites. Writ­ing non-validating code is a big step back­wards, on the path of perfection.

Bib­li­og­ra­phy

• http://www.modernlifeisrubbish.co.uk/article/web-standards-dont-matter-as-much-as-you-think
• http://validator.w3.org/docs/why.html
• http://next-design.com/resources/validation.htm

Using Debian Test­ing or Unsta­ble, or a fre­quently upgraded ver­sion of Ubuntu, when doing an apt-get update && apt-get upgrade often will install a slightly newer ver­sion of xserver-xorg-code, and this will break the NVIDIA pro­pri­etary dri­vers, if you, like me, pre­fer to install them using the offi­cial NVIDIA installer. When this hap­pens, at your next reboot, or next time you start X, this will crash.

Fol­low this instruc­tions and you won’t need to rein­stall the NVIDIA dri­ver from scratch each time. First of all, stop your login man­ager (gdm assumed here):

/etc/init.d/gdm stop

Then move to:

cd /usr/lib/xorg/modules/extensions

Nor­mally it should look like this:

total 956K
1 root root  19K 2007-01-09 21:13 libdbe.so
1 root root  34K 2007-01-09 21:13 libdri.so
1 root root 145K 2007-01-09 21:13 libextmod.so
1 root root   18 2007-01-15 20:42 libglx.so->libglx.so.1.0.9742
1 root root 676K 2007-01-15 20:42 libglx.so.1.0.9742
1 root root  28K 2007-01-09 21:13 librecord.so
1 root root  38K 2007-01-09 21:13 libxtrap.so

Notice the sym­bolic link from libglx.so to libglx.so.1.0.9742. In your case, instead, the instal­la­tion of a newer xserver-xorg-core over­wrote the libglx.so with the nor­mal one pro­vided by the X Server. What you have to do is sim­ply restore the pre­vi­ous sit­u­a­tion. Remove the libglx.so file:

sudo rm libglx.so

And make the sym­bolic link again:

sudo ln -s libglx.so.1.0.9746 libglx.so

Of course the ver­sion num­ber, in my case 1.0.9746 may be dif­fer­ent in your case. Now you can sim­ply start the gdm login man­ager again:

sudo /etc/init.d/gdm start

Every­thing should be work­ing again.

Thanks to http://osrevolution.wordpress.com/ for this.

Dear Mr. Jobs,

Although I’m just a spo­radic Apple user (used to have an iBook — but even­tu­ally sold it -, I have an iPod Nano), and although I’m not using any of your soft­ware (used Linux on the iBook and use Linux again on the iPod), I truly appre­ci­ate the prod­ucts of Apple Inc., soft­ware included. I like OS X very much and I’ve been very keen in fol­low­ing Apple’s events even not being a great user myself.

I heard about the iPhone, saw the pic­tures and heard the rumors. At first glance, fol­low­ing the offi­cial pre­sen­ta­tion through Engadget’s web­site, I was stunned and greatly sur­prised, in a very good way. The iPhone looked exactly like every­thing I’ve always wanted. All the ideas in there, all what that kind of gad­get rep­re­sents, have been uncon­sciously float­ing in the back­yard of my mind for some time, and sud­denly all was true.

After a few days, though, some rumors said that the user won’t be allowed to install 3rd party appli­ca­tions. That shocked me again: the first thing I thought, when I saw the iPhone, was “Oh gee, this is the ulti­mate geek tool, must have it!”. In the line of Apple’s gor­geous designs, with a great soft­ware load, and fun­da­men­tally a BSD sys­tem where I could load any­thing I wanted. I was already dream­ing of port­ing my favorite appli­ca­tions to the iPhone. Then the rumor. I’m no well known mar­keter, but some­thing has been bug­ging me. In my hum­ble opin­ion, the iPhone is (or should be) basi­cally two great things, that rep­re­sent great inno­va­tion if merged in the same device. One is the sim­plic­ity of use, which Apple is famous for. The clean and neat usabil­ity, I loved it in OS X, loved it in the iPod soft­ware. That fea­ture, as usual, hits the great­est share of the mar­ket. Mil­lions of peo­ple who want some­thing that just works, and is easy to under­stand. Apple is always been great with that. The sec­ond thing is that such a gad­get undoubt­edly attracts the power user: a sin­gle device which is a beau­ti­ful phone and has the capa­bil­i­ties of get­ting to the net through WIFI. I think I’m not the only one, out there, who wished for such device. The Nokia 770 was a good start, but it wasn’t a phone. Now, there is some­thing that we power users, or geeks, if you pre­fer (I don’t mind), like to do: that is tweak, cus­tomize. Hav­ing such a pos­si­bil­ity with the iPhone would, in my opin­ion, gain an extra share of the mar­ket, i.e. those power users that don’t like the idea of being con­strained in any way.

I surely under­stand that Apple’s design­ers and engi­neers know what they are doing, and there are very good rea­sons not to open the iPhone to exter­nal appli­ca­tions. A lot has been said, around, about the risks of releas­ing a devel­op­ment plat­form, or the threats that this would bring to the mobile oper­a­tors (like Cin­gu­lar), even though, I must admit, none of the arti­cles got tech­ni­cal enough to con­vince me. And I’ll be up to take all of this as true, of course. There is, though, some­thing which I, and a lot of other peo­ple, would really appre­ci­ate in a device like the iPhone. That is a Ter­mi­nal pro­gram with an SSH client. Imag­ine the poten­tial­i­ties: I do most of my things through an SSH con­nec­tion to my machine at the office. I work from home or from any­where else in the World, that way. I use IRC that way, I read my Usenet mes­sages that way. I read my emails that way. What’s the advan­tage of all this? I like to have a cen­tral and safe place where I can keep an orga­nized and, above all, cen­tral­ized way of man­ag­ing my resources. I don’t need to con­fig­ure email clients every­where I go. I don’t need sev­eral web­mail sys­tems to check all my email addresses. I keep my Usenet arti­cle orga­nized and syn­chro­nized on one sin­gle machine. I keep all my IRC logs on one machine, and so on. With an SSH client in the iPhone, I could do all this even from a bus, now that in my city wire­less con­nec­tions are becom­ing avail­able on some buses.

I’m sure there are lots of more uses of such a thing, and lit­er­ally tens of thou­sands, if not more, of power users like me will love it. I really hope that you will con­sider this issue, and give us power user an SSH client for the iPhone, or the pos­si­bil­ity of installing cus­tom software.

As soft­ware is one of the most impor­tant issues in our era, writ­ing good robust pro­grams is essen­tial. This arti­cle is an in-depth essay focused on Object Ori­ented soft­ware and large projects. Every­thing said here, though, scales well to good direc­tives for small projects as well.

Our time is dom­i­nated by soft­ware. There is basi­cally soft­ware every­where around us; most of the object you can see right now around you, have some­thing to do with soft­ware, prob­a­bly because they were cre­ated using some sort of machine. Given the impor­tance of soft­ware nowa­days, I just have to find bugs unac­cept­able. Of course you might argue that a small and rare bug is a minor soft­ware won’t harm any­one, and is not nearly as impor­tant as a bug that could affect the soft­ware of an air­plane, and I’m going to agree with that. But as time goes by, every­thing has to be going towards per­fec­tion, and cur­rent trends about soft­ware seem to be going nowhere: there were bugs in soft­ware 30 years ago, and there are today. There was a time, in the begin­ning, where sci­en­tists thought that it would be rel­a­tively easy to write bug free pro­grams right away, but then they real­ized pretty soon that it wasn’t quite so. After all, soft­ware is writ­ten by us human beings, and we are doomed to make mis­takes or omis­sions. The point of this arti­cle is not that soft­ware should be always bug free, but that we, coders, should always get them to the min­i­mum, and here I’m going to present some ways to deal with pro­gram­ming in general.

One huge prob­lem, as I’ve faced quite often, is that as a pro­gram grows in size and depen­den­cies, its devel­op­ers start los­ing trace of its com­po­nents, get fur­ther away from the big pic­ture, and ease the intro­duc­tion of bugs. Note, I’m not talk­ing here about bugs caused by a sin­gle human error that can be labeled as a cheap error by any­one who would look at the code. I’m talk­ing about the sort of nasty bugs that nobody can spot right away with a glance at the code. I’m talk­ing about sys­tem wide bugs, usu­ally emerg­ing as a result of hardly related sub­sys­tems of the pro­gram. Usu­ally con­nec­tions between depen­den­cies and libraries.

Any­way, the path to write bug free code, is the one you step when you write robust code. What do I mean by that? Robust code has some features:

• Well designed
• Neat and tidy
• Well named
• Well com­mented
• Well tested
• It never segfaults

As a result of some of these, robust code is also:

• Exsten­si­ble
• Reusable
• Last­ing in time

Well designed.

Hav­ing already talked about this some­where else, I’ll be brief on this sec­tion. Writ­ing a com­plex pro­gram, a pro­gram made of hun­dreds of thou­sands lines of code, is a damn com­pli­cated thing: it takes many peo­ple and a lot of time. Usu­ally, the more peo­ple you involve in the project, the less robust code you’ll get in the end. Peo­ple will use dif­fer­ent con­ven­tions and dif­fer­ent styles. For this rea­son, not only it’s cru­cial to hire the right devel­op­ers, but it’s essen­tial to have a very strict and detailed spec­i­fi­ca­tion of the project. Pro­gram­ming is a cre­ative work, no doubt, and coders need to have free­dom so they can breathe. A con­strained coder is a chained coder, hence a dead coder and a threat to the qual­ity of the end prod­uct. But, in spite of how much we care for the free­dom and open­ness of ini­tia­tive from the devel­op­ers, we have to be aware that loos­ing con­trol means low­er­ing the qual­ity. A large project must be designed thor­oughly and care­fully, in every sin­gle details. Even though pro­gram­mers love free­dom, most of them also love exhaus­tive doc­u­men­ta­tion. If you want to make a good coder happy, and get the best out of him, flood him with docs and specs. Noth­ing pisses off the good coder as the lack of doc­u­men­ta­tion: it tears his moti­va­tion apart. “Why should I start to read their minds and run by guesses” — he thinks, “when they didn’t even get the time to write good specs?”. Fur­ther­more, a project with­out good specs looks super­fi­cial, des­tined to fail­ure and with­out a future. A very good coder is hardly going to stay in a com­pany that doesn’t make good design for the projects. He will think that it’s a loser com­pany, and start look­ing around.

But what does good design mean? A good design is:

• Exhaus­tive
• Non redun­dant
• Non con­tra­dic­tory
• Easy to understand
• Related 1:1 to the implementation

We want to cover every pos­si­ble out­come in our spec­i­fi­ca­tion, let be them exhaus­tive so that noth­ing will be left to case. We don’t want to repeat the same infor­ma­tion more than once, and be redun­dant for sev­eral rea­sons, e.g. infor­ma­tion should be retriev­able in exactly one place, and it would ease up con­tra­dic­tions. Doc­u­men­ta­tion should be for the devel­op­ers, i.e. writ­ten in the most straight­for­ward way for the right audi­ence: sim­plic­ity of lan­guage and straight­for­ward­ness of tables and schemes will spare some curses from the devel­op­ers. Fur­ther­more, as a spec­i­fi­ca­tion is just a way to put a pro­gram in words before it’s writ­ten, devel­op­ers should be eas­ily able to trans­late what they see on paper to code. Think about a shop­ping list: when I get one, I just go to the shop and take care of trans­lat­ing each item on the list to a phys­i­cal item in my shop­ping cart. Direct and easy.

Neat and tidy

A good def­i­n­i­tion of neat is: in a pleas­ingly orderly and clean con­di­tion. How does that apply to soft­ware? What is neat soft­ware? One nice word that I like in that def­i­n­i­tion is “pleas­ingly”. Neat soft­ware pleases the eye and the mind. Don’t want to be cocky here, but neat soft­ware is some­thing writ­ten by a good pro­gram­mer, and will be appre­ci­ated by another good pro­gram­mer. If some­body known as a good pro­gram­mer points at some soft­ware and says “That’s neat” and you find your­self look­ing at it and reply­ing “Huh? That’s just code”, I’m sorry but chances are that you are not a good pro­gram­mer. A good pro­gram­mer appre­ci­ates the beauty of some code, both on a small scale and on a large scale. Neat­ness of soft­ware on a small scale means that you’re able to look at one func­tion and appre­ci­ate the sim­plic­ity of it. Neat pieces of code are eas­ily read­able and use good name con­ven­tions. Please read this arti­cle if you want to know more about good code on a small scale. Neat code on a larger scale, on the other hand, means neat inte­gra­tion between com­po­nents and sub­sys­tem of a project. A bad inte­gra­tion would mean, e.g., hav­ing a project-wide global vari­able that points to a cer­tain sub­sys­tem, and using it every­where in the project. Or hav­ing two sub­sys­tems that, in a messed and inter­twined way, mutu­ally call each other’s meth­ods vio­lat­ing sev­eral lay­ers of abstrac­tion. Prov­ing what neat code is, turns up to be very dif­fi­cult. It’s a bit like the oppo­site of what hap­pens with com­mon logic: if I want to prove you that, say, lions exist, I can just go to Africa, pick one and show it to you, then say “That’s a lion, ergo lions exist”. But how can I prove that uni­corns or dragon don’t exist? You prob­a­bly agree that it’s much more dif­fi­cult. It’s just the oppo­site with neat code. I can show you bad code, and you will eas­ily agree that it’s bad. But look­ing at neat code doesn’t it prove it neat right away. It takes prob­a­bly years and years of expe­ri­ence, writ­ing a lot of code and read­ing a lot.

Well named

This topic has already been dis­cussed here, but repetuta juvant. As code is man­aged by pos­si­bly dozens or more peo­ple, being under­stood is an impor­tant key to increase robust­ness of the code. Writ­ing robust code also means writ­ing code that will eas­ily stay robust when other peo­ple will mod­ify of expand it, unless they have no clue, of course. The most your code is under­stood by oth­ers, the most likely they will not break your ideas, and keep the code robust. There are sev­eral ways of mak­ing own code eas­ily under­stood, and hav­ing a good, con­sis­tent and solid nam­ing con­ven­tion is one of them. Of course, as dis­cussed later, code needs to be well doc­u­mented also.

Well com­mented

I know, I know. Every­body says that you should com­ment your code. That’s what I say and that’s what I’ve been told. Still I’m now com­ment my own code enough as I should. Before you can then tell me “Who are you, then, to tell me to com­ment my code, if you don’t do it enough with yours?” let me remind you that we learn from mis­takes. What they don’t tell you about the impor­tance of com­ment­ing code, is some sub­tle and psy­cho­log­i­cal lit­tle thing. If you are a bad pro­gram­mer, you’ll never pro­duce good code. But if you are a good pro­gram­mer, some­times being in a hurry will make you pro­duce really bad code. There are two rea­sons why this can hap­pen: 1) you are in a hurry because you’re late with your dead­lines. With this, there’s noth­ing to do. 2) you are in a hurry because you’re just cod­ing fast, on the rush of some ideas that flashed you. In this case, com­ment­ing your code a lot will improve dras­ti­cally the qual­ity of your code. Always write your com­ments before writ­ing the actual code. This will make you real­ize it, if your func­tion is not really going to do what it’s sup­posed to do. Writ­ing the com­ment will also help you think more about what you’re doing, and being more con­scious about it. It will keep your state of mind clear and pre­cise. I strongly rec­om­mend using Doxy­gen to gen­er­ate a browseable HTML ver­sion of your com­ments, espe­cially if you’re writ­ing a library. Oth­er­wise, it’s still going to keep you on a pro­fes­sional line, which is always a good thing.

Well tested

Write and use unit tests. If your code is well designed, there are good chances that each func­tion in your code, or each class, per­forms a spe­cific task in a cer­tain way, and noth­ing more. Given a cer­tain input, it will reli­ably return the same out­put. Right? You have to make sure of that, by writ­ing test cases. Test­ing the small­est units of your pro­gram doesn’t ensure that the whole is work­ing per­fectly, but helps. Pos­si­bly, append a hook to your Source Code Ver­sion­ing Sys­tem (SVN? Darcs?) so that the auto­matic test­ing suite will run auto­mat­i­cally on the server that hosts your repos­i­tory, before it accepts your patch. This is quite easy with Darcs.

It never segfaults

Of course this point applies to the lan­guages that allow seg­men­ta­tion fault, or Null­Point­erEx­cep­tion (in Java). It’s easy to get: if your code seg­faults, there are no excuses. No mat­ter how stu­pid the pro­vided input was, your pro­gram should not seg­fault. A good prac­tice, is that each and every function/method would check it’s argu­ment before doing any­thing. A solid excep­tion han­dling struc­ture is required. Again, you can object that I’m not really say­ing any­thing use­ful here: “Of course pro­grams shouldn’t seg­fault, I knew it!”, but think about it: it’s a mat­ter of atti­tude. You want to write a per­fect pro­gram, and there are some things you have to keep in mind. Be para­noid with seg­faults will implic­itly and secretly improve the gen­eral qual­ity of your code, with­out you even noticing.

Con­clu­sion

Writ­ing per­fect code is impos­si­ble. Espe­cially as the code grows in size and num­ber of pro­gram­mers. Achiev­ing the impos­si­ble, then, is beyond any good inten­tioned coder. What we can do, though, is just try to have the right atti­tude, which is about pre­ci­sion, care and, some­times, para­noia. Writ­ing com­plex pro­grams is not an easy thing, and, as such, should be han­dled with extreme care.