Bela Lugosi Night

For christmas, I got a pair of DVDs from the "classic horror movies collection". Given by none other than my very cool parents, who know how to humour my strange tastes.

Today, I was feeling sort of lousy, so after the grocery run (well, I went to the mall, but nothing really inspired me, except a miniature plunger for my bathroom sink... how exciting), I curled on the sofa and listened to a couple of movies, both starring Bela Lugosi.

For those not knowing Bela Lugosi, he's an actor who played in many 40's horror movies. But his main claim to fame in modern cinematography is probably his partial participation in one of the worse movies ever made, Plan 9 From Outer Space by director Ed Wood. Lugosi was slated to play the head vampire, but he died early in the making of the movie. Ed Wood, ever the optimist, replaced him with a much taller man who had a different face and had the replacement cover his face with a cape for the whole movie. If you haven't seen Plan 9, you should; it's quite bad, but so bad it's sort of good. Ed Wood by Tim Burton is worth seeing as well; it's a not-quite-documentary on the making of Plan 9

Anyhow, for those reasons, Bela Lugosi is known to me. But the only movie I've seen him in was Plan 9, which doesn't count.

Hence: The Devil Bat. Nutty doctor bitter about some rich man making a fortune on his discoveries (the doctor cashed out instead of getting a stake in the company) invents a way to make bats gigantic using electric current (???). He conditions the bats to hate the smell of a particular aftershave he's developing. He then distributes the aftershave freely to members of the rich man's family and sics the bat on them.

It's a harmless movie. Special effects are especially laughable, but it was made in 1949. Though they could have been more careful about some things, like the bat-flying-out-the-window shot where the window is obviously NOT the window we saw open (the bricks don't have same texture, etc). There's some priceless Lugosi acting (meaning, quite exaggerated) like replying to "goodnights" from his intended victims with "goodbye Mr. insert name here". A rather silly subplot of the hero's assistant trying to woo the rich man's daughter's French maid. And the rather unnatural switch of the female lead's affections from her murdered intended to the hero (man--it's like it's the most natural thing in the world!)

That said, it's too bad such movies don't really have a soundtrack, because some parts run a bit long and dry.

Then, I listened to The Human Monster. Unfortunately, sound quality was somewhat poor, as it's a really old movie. Lugosi exaggerates his expressions even more than in the other movie, and his face just screams "villain!" all over the place. I found that movie a bit less enjoyable, although it's definitely more serious and more care was put into it. I guess it's just too serious--old horror movies should be cheesy. But as far as it goes, it's not that bad a movie, with a pretty predictable plot, but some relatively well-scripted moments. Keep in mind I'm no movie expert. Unfortunately for me, who wanted to look at a Lugosi flick, he gets less face time here. I must admit, though, that I found the scene where he puts the female lead in a straightjacket and drowns a man in front of her quite tense and effective.

Looking at old movies like this is an interesting experience. You realize that modern movies have more technical means, but their plots stink--they're as predictable as those old things, and often play on the same themes (there are exceptions, but there were exceptions then as well). You realize that while attitudes towards women have changed on the surface, they are basically the same in modern movies; they were simply quite a bit more open at the time, and they weren't as bad as many people make it in comparison to those of modern movies. The female lead in The Human Monster is a damsel in distress, but she's also incredibly stubborn about wanting to find out who killed her father. Surprising after seeing The Devil Bat, where the female lead is a human carpet in many ways. As now, scripts vary widely.

Well, I'll probably listen to other movies from those disks in the near future and let people know what I think about them.

Dumb questions for Java heads

At work, we came across a really annoying problem upgrading some machines from Tomcat 4.1 to Tomcat 5.0

We have some servlet mapped on the servlet-mapping "/". It's supposed to handle an URL known as /en/blah. Now, due to some rather odd customer requirements, we're also required to have a physical file /en/blah/index.jsp, which, even more oddly, contains a redirect to /en/blah/natter (instead of /en/blah).

When the user browses to /en/blah/, Tomcat 4.1 calls the servlet. So does Resin 2.1.x. But Tomcat 5.0 opens up the welcome file /en/blah/index.jsp.

OK, I know it's not such a good idea to have two potential targets for a given URL that yield different results. But, I'm curious whether either behaviour is mandated by the Servlet specs? Or is it simply undefined?

My reading of the 2.4 specs says that the "/" servlet is the default servlet, and welcome files have higher priority. However, this may not have been the case in earlier specs. But looking at the changes in the back of the 2.4 specs, they don't seem to mention anything like that. Or maybe I'm missing something.

Just curious...

Star Wars Revisited

Well, not really revisited, but I can't think of a more interesting title.

Three friends and I decided we needed to watch the original Star Wars again (not the one that was "remastered"--the real deal, with nothing more than slight picture clean-ups; unfortunately pan-and-scan). Of course, having seen it many times, it's a great occasion to poke fun at it.

OK, so there's the usual corny lines, botched special effects, and so on... but it's still quite good for the time.

However, something unusual happened this time. I noticed something new. In "A New Hope", in the scene where the imperials break in the room on the death star where the droids have been hiding, watch the rightmost stormtrooper carefully. He's taller than the others, and he appears to bang his head on the door frame!

Isn't that cool? It's not? Oh, just shut up.

Weather update

In case anyone cares, or even if nobody does, it's frickin' cold today. It was also frickin' cold yesterday, the day before, and the day before the day before. I wouldn't mind so much, except that the days before that, it was a very warm -5 centigrade.

And there's no snow. Which is a moot point, I guess, because it's way too cold to cross-country ski; I'd probably be drained after a mere kilometer, all my calories going into my body's central heating system.

I take hope in the fact that January is the coldest month in Montreal, and that it can only get warmer from here. But maybe I shouldn't even think that, as nature always has some nasty surprise for us in February.

I normally wouldn't mind the cold, but I now pay the heating bills directly (they used to be part of my rent). My heaters are electric, which means it's less polluting (Montreal power mostly comes from insanely huge hydroelectric dams), but it's also more expensive per Joule presently. I think the last two months have been more expensive than the previous six months, even when taking the A/C into account. And I've been really cheap on heating, keeping ambient around 15 centigrade, five degrees below the "comfort temperature".

Bleah. And municipal taxes are going to hit me on the head soon, too. Joy.

Ah, well, that's what I get for not moving to California when I had the chance. Then again, I'm not sure I'd still be employed if I had moved down there, with the .com bubble and all. In any case, I'd have less liquid assets because property prices are insane down there. I suppose all those temperature shifts have their compensation--nobody wants to live there, so prices are still somewhat affordable.

About the A-25 bridge

OK, this post is going to be of little use to those who don't live in eastern Montreal, unless you are somehow interested to get some idea how life there is.

It is, uninterestingly enough, about a highway.

Montreal is oriented in the southwest-to-northeast orientation. However, northeast is usually called the "east" of the island, because streets run parallel to the island's axis. Same goes for the "north" of the island--it's actually northwest, perpendicular to river St-Laurent's current.

In the middle of the island, there's St-Laurent street, which cuts the island in two parts: the west and the east. The west has traditionally been Anglophone, multicultural, rich, dense, commercial and well-served by major infrastructures (roads, commuter trains, and so on). The east has traditionally been Francophone, mostly white, poor, full of strange empty spaces in the middle of nowhere, industrial and somewhat isolated by poor transport infrastructure.

In recent years, the industries of the east, mostly related to manufacturing jobs, have closed down or moved back to the States. The east of the island turned somewhat commercial with a rather large complex centered on a huge shopping mall, Les Galeries d'Anjou. Around that area, high density building were built. The east became attractive to immigrants, provided they could figure out French reasonably well (Haitians and Vietnamese are a natural fit and a common sight), because property value was much lower and yet the new constructions were reasonably well-built. The trans-canadian highway, known as A-40 in those parts, was prolonged to the end of the island, and the A-25, a north-south highway, was built, linking east of Montreal with the south shore cities of Boucherville and Longueuil.

Actually, it's probably easier to see a map (apologies to the SIA for linking to theirs). Note that the map has an area known as "Centre-Est", which I'll refer to as Hochelaga because it's the "traditional" name.

Other parts of the east became attractive as well, still because of low property costs and reasonable building quality. The formerly half-destroyed Plateau Mont-Royal became so trendy that prices there have become unaffordable, and since west of it is downtown, people are moving east to Rosemont or Hochelaga. Hochelaga is still half-destroyed, but it's slowly becoming more interesting, as young couples move in and renovate the heck out of old duplexes.

Other parts of eastern Montreal are doing OK as well. Anjou is mostly doing well, thanks to north-east Anjou being an industrial park, and thanks to a reasonably efficient town administration. St-Leonard is doing well. Rosemont is doing reasonably well. Some parts of Mercier west are doing quite well, being brought into the orbit of Rosemont. East of A-25 is not doing that great, but services aren't all that bad and property price is ridiculously low.

Overall, eastern Montreal is more affluent than it used to be when compared to western Montreal. The price of properties is still somewhat on the low side. And yet, people fail to flock there. New home-owners consider Longueuil (south shore) or (shudder!) Laval (northwest of Montreal). Why, exactly, is that the case?

I think the equation is very simple. I live in Anjou. East of St-Leonard, it's the best-served burrough in terms of public transportation and road infrastructures (I consider the road infrastructure in the immediate neighborhood to be better designed than that in St-Laurent, which is in western Montreal). I work downtown. It takes me 50 minutes to work with public transportation, roughly 45 without. In St-Laurent, where I was geographically further from downtown, commuter train would take 30 minutes, and driving would take 25 provided there was no traffic (which never happened, but never mind). Times to go downtown from Laval are roughly the same (ok, maybe 40 minutes by bus/metro, but Laval people are way farther from downtown than I am!), and Longueuil residents can make it even faster.

Why?

Answer: north Anjou does not have a metro, which it was supposed to have 15 years ago. South Anjou sort of has a metro, provided you don't live too far from A-25. No commuter train at all. Roads? A-40 does not take you downtown; it takes you north of Mt-Royal, and then you have to go down some crowded, busy streets like Parc. Or you can drive all the way to A-15, find yourself in ridiculous traffic, and double back. Or you can take A-25 down to Souligny, cross the Armed Forces base, take Dickson to Notre-Dame, dodge potholes and huge 12-wheelers to A-720, and then finally reach downtown.

Oddly enough, despite sounding way more complicated, that's the fastest way to get downtown. Seriously. Even if there's no traffic on the A-15. This, as they say, sucks.

In the case of a western resident of the island, it's much less annoyance. Take the A-15 to downtown (and you can take it from A-40, A-20 or even A-520, depending which has no traffic that morning). Sure, you get a lot of traffic, but at least there are no traffic lights, so what you lose in traffic you gain in continuously moving. Not a option on Notre-Dame. Laval people just take the A-15 further away. Longueuil residents take the bridge (which does get jammed, to be fair) directly to A-720 and zip downtown.

If you factor in public transportation, the difference is even more marked. Western Montreal has plenty of commuter trains, even if you go geographically farther from downtown than Point-Aux-Trembles is. Laval has commuter trains and is getting a Metro before eastern Montreal, even though that damn Metro station is costing three times more than was expected (and costs are still rising). Longueuil has had the Metro for a long time, and has commuter trains as well. Granted, though, east Laval and east south-shore aren't well served by trains (see this map, and weep). But they have their own east-west highway (Laval has the A-440, south shore has A-20 and A-30) which east Montreal does not have south of A-40. In fact, if you look at the commuter train map, it's painfully obvious that there is no service for the east.

OK, so some of those parts don't have that much population density. But neither did Longueuil when it got the Metro, and Laval, while dense in some parts, has a very sparse population. In any case, they are off the island, and contribute largely to urban sprawl. They are also far.

It is becoming clear to everybody involved at various levels of the government that this is somewhat unfair for denizens of the east. The A-25 already exists in Laval and north of the A-40, but the two sections are not linked. The provincial government has finally decided to build the bridge to link those two sections. Hopefully, it will allow traffic to the Anjou industrial park to possibly take the A-440, thus freeing the A-25/A-40 junction during rush hours (it should be known at this point that the Galeries d'Anjou complex is smack in the middle of the A-25/A-40 junction; it's quite interesting during rush hours, especially since the closest bridge to Laval is all the way west in St-Leonard, clogging the A-40 with huge trucks). Of course, this does not solve the problem of going west from south of the A-40, so the project also implies some rather large changes to Notre-Dame. It was originally planned as a highway, but nobody can make up their minds what to do about it.

This bridge would be a toll bridge. It would probably relieve some pressure to the A-15 and the A-40 (which is already not managing traffic well at all). Less idle engines and all that.

And of course, the first reaction of every environmental group is to decry it as an enemy of substainable development.

OK. Fine. I understand people don't like having huge highways carved into what used to be idyllic fields of grass.¹

But, I mean, come on! The frickin' A-25 is already pushing north all the way to Henri Bourassa (north of A-40), there's a huge boulevard north of that where people have a really heavy foot on the acceleration pedal, and nothing was built around it for years because it was known that there would be a highway there someday! On the Laval side, the highway is already there and pathetically waits for a bridge to show up! There's huge concrete blocks in the water already, only awaiting for funding to build a full bridge!

Critics then point out that the new A-25 bridge will require changes to Notre-Dame, cutting the south of Notre-Dame off from the rest of the island. This is utterly ridiculous. South of Notre Dame, between Dickson (close to A-25) and the A-720, is the Montreal Harbor. It's a fenced area where only 12-wheelers can get in. Because Notre-Dame is a street instead of a real highway, it's full of potholes from those 12-wheelers and I'm sure a lot of pollution is generated just by the efforts to fix it year after year. You may hate A-720 for cutting off downtown from Old Montreal, but it's not going away, and we might as well do something with it. Turning Notre-Dame into a highway would probably not make noise or pollution much worse for residents immediately north of Notre-Dame, since traffic there is already very bad and full of huge trucks. It may actually improve things, since the highway would be either in a tunnel like A-720 or walled off like A-25 in the Anjou and Mercier areas.

Critics finally point out that we should build a commuter rail to the east instead. I agree that we should build a commuter rail; it's sorely needed. Actually, we should prolong the metro (preferably with at least one station north of A-40), but with the Laval metro costing so much, the AMT has no money for that. The rail is needed anyhow, because the metro won't help Pointe-aux-Trembles or Rivière des Prairies. But the rail also won't cost that much--maybe 20 million or so--because the track is already there, all that's needed is to build train stations. So it's not as if the A-25 bridge is competing, in terms of financing, with the commuter train.

Finally, I'd like to point out that all critics of the A-25 bridge live in Outremont, the Plateau or some other central area of the island. They have no idea how ridiculously isolated eastern Montreal is. From Pointe-aux-Trembles, it takes 1 hour 20 minutes to get downtown! From east Laval, don't even think about it--not only you'll waste time and gas driving to the A-15, but then you'll be stuck there for at least an hour in traffic, and you'll then have to double back on the A-720! At this point, any development is welcome. Eastern Montrealers hope that starting to build any of these projects will probably get the others built as well.

I'd also like to point out that although the bridge will be expensive, so was renovating the Acadie circle, and so are the repairs to the A-40 brought by ridiculous amounts of traffic. But nobody yelled when those were done. Of course not--those were needed. The fact that many of those people who don't want Notre-Dame to become a real highway nor the A-25 bridge to exist at all live in Outremont is surely a coincidence.²

What really pisses me off about all this, though, is that such concerns were never raised when Laval or Longueuil was to get its infrastructures. The metro eventually followed, because the roads were too congested. But now that eastern Montreal would finally get decent infrastructures, which would probably help develop it (there's a lot of mis-used space there--much more than in dense, crowded western Montreal), all of the sudden, those concerns show up. OK, fine, some of them have some validity to them--why don't you lobby for a damn commuter train and for a damn Metro line, instead of against a bridge?

Deep within myself, I believe that nobody really cares about eastern Montreal. Nobody has cared about it for the longest time.³ I hope that will change. It's easy to yell about new infrastructure being non eco-friendly when you have your infrastructure already built. Sort of like industrialized countries going all sanctimonious on developing countries about pollution, but not being willing to share more efficient technology with them, or to sell it at a lower price. It's also really idiotic to yell like this before the whole project is known; for all we know, the government may be planning a light rail line on that bridge! I don't always agree with the Charest government, but I hope that in this case, it will not back down. We've been waiting for that bridge for 30 years. It's high time eastern Montreal and eastern Laval got the chance to show off their potential.⁴

---

¹ I'm being sarcastic here. The only fields above A-40 in the A-25 axis is full of weeds, power lines, and is crossed by a railroad. It's not idyllic at all, and if it's not contaminated by idiots dumping stuff there, it certainly is by the PCBs that were used at a time to isolate power lines.

² I'm not trying to single out people living in Outremont here. But one of the people who utterly destroyed the Notre-Dame project is the current mayor of the city, Gerald Tremblay. He lives in Outremont. He feels Notre-Dame would cut off part of the island. He's obviously never been east of Papineau; there's nothing south of Notre-Dame there, except a harbour and lots of contaminated soil. I suspect those writing editorials against the bridge live west or close to St-Laurent. They obviously don't know that a) the highway is already there, we're only talking about a bridge; b) the Anjou industrial park is not developing as well as it could because of this silly highway configuration; c) east Montreal is not going to get a metro because Laval got theirs and it was too expensive.

³ I suppose a sensible question to ask me at this point would be, "why did you move to eastern Montreal if it's so isolated?" The answer is, I'm not really that annoyed by long transit. But those living in Rivière des Prairies or Pointe-aux-Trembles are not amused. Also, I wanted to find a place I could afford. Finally, I grew up in eastern Montreal, and it's an area I really like. I realize that I wouldn't have had such a good deal if the area had full infrastructure; but now that I'm there, I'd selfishly like it to show up.

⁴ Especially since east Montreal and east Laval are being neglected in favor of much farther places like Deux-Montagnes or northwest Laval, since those have good highway access. Having cars travel 45 KM instead of 20 is certainly not an improvement in terms of pollution. I'd much rather have east Montreal settled than those places, and it's not happening because of lack of access. Perversely, I think the lack of bridge, rail and decent Notre-Dame highway encourages urban sprawl; critics say the opposite, that keeping the east of the island isolated will counter urban sprawl. Well, people don't care about theories; they just go to St-Eustache or Deux-Montagne, or they go to Longueuil and emit thousands of tons of carbon waiting on Jacques-Cartier or Champlain bridge.

Fanfiction redux

After a seemingly interminable funk, I finally feel the writer's itch again. I'm giving yet another shot at the conclusion of my FF7 trilogy.

This time, I'm not even planning out the whole plot until I've got some more material written. I'll try to write "as it goes". At worse, I'll revise later. I feel that many decisions I'd taken in the previous installment really painted me in a corner if I kept the old plot structure I had in mind, so I'm killing it.

This post is mostly to force me to actually finish the damn thing.

Actually, I may have a better chance than last times I tried. Those long public transit trips help a lot. The fact I ran out of stuff to read until I get my ass to the library helps as well. Finally, I really feel the itch. Before, I was trying to write as an obligation, that is, I hated the fact the trilogy was incomplete. This time, I was cooking last week-end and, as I was waiting for the pressure cooker to finish whatever it is pressure cookers do (ok, ok, I know they cook stuff; it's a pressure cooker, duh!), I just got the editor out and started writing on a whim.

I can't promise anything, but I feel good about this time.

It's just too bad that I have to scrap all the stuff I had already written for this. Maybe I'll recycle it some day. But I'll definitely not use it now; that stuff is poison and has "painted in corners" all over it.

Hmmm, maybe I should have a "failed fanfics corner" if I ever get over my embarassement...

Neat Eclipse SWT trick

I've been rather underwhelmed by Eclipse's performance under Linux compared to Windows. Turns out the main problem is a huge mismatch between the widget model for SWT and that of GTK+.

Thankfully, somebody ported SWT to another free widget set, the FOX toolkit. It's available here. It works quite well as far as I can tell, although my tests were extremely basic.

I'll have to try it at work and see if Eclipse is usable on my workstation there.

Another nice tool I found (although it's probably well known, but I didn't know about it until a co-worker pointed it out) is xbindkeys. Unlike many other key binding programs, it works on key combinations for those of us who don't have an "internet" or "multimedia" keyboard (I have a much beloved but somewhat low-tech Fujitsu KB 4725, which is one of the few mechanical keyboards still manufactured, and I'm not giving up mechanical keyswitches for extra "internet" keys!)

I hope they'll be as useful to you as they were to me.

Why Software Projects Go Wrong

A rather ambitious title for a humble post.

Reading (as I tend to spend much time doing) Slashdot, I found this post which leads to a formal survey. The survey in itself is interesting, but it suffers as much as any survey: it hinges on people's perceptions.

So, I thought that adding my own perception on why software projects don't work well would contribute to the body of knowledge somewhat. After all, the study does not reveal exactly why software projects go bad; it only reveals what we think goes bad.

So, here's my modest contribution:

Mismatched metaphors

This is, to me, the worse problem in software development today. It's a meta-problem, that encompasses using the wrong methodology, unrealistic time pressures, lack of customer involvement, and even design complexity. Those things can arise without the mismatched metaphor problem, but a mismatched metaphor can lead to all of them.

Good examples of this are: the idea of software as manufacturing, or of applying construction-related methods to software. Another is the insistence that you need artificial deadlines to stimulate people, that programmers are fungible resources, that resources can be exchanged freely, that software complexity scales linearly, components that are supposed to fit like lego blocks, and so on.

Software is not like manufacturing or construction. Software construction is what the compiler does: it turns a design spec (source code) for algorithms into a final product (an executable algorithm in machine code). In the days before advanced programming languages, "hand-assembling" the code, as well as the translation from pseudocode to assembly, could be seen as construction. Those are largely automated today. Time for software construction scales linearly with hardware power (well, not quite, because there's hard limits like hard disk access times and so on, and some code optimizations run only in quadratic time or worse, but much of code generation is made up of linear processes).

Writing software is mostly a design activity. Some parts are construction: writing the same string sifting algorithm for the 100th time, translating a high level algorithm into a language that's not quite abstract enough, and so on. Those tasks will eventually become easier and mostly automated with time, as better libraries and languages appear. Some may remain, for the same reason we don't write everything in pseudocode: we don't know algorithms to make every algorithm description into efficient code without human aid.

It is therefore closer to the design stage of construction or manufacturing.

An aside: construction projects are very often late, mostly due to mismatched designs or misbehaving contractors. So, it's not really as if they have a sterling record with their methodologies. Besides, from the construction point of view, software has relatively good track records, as long as you work in a shop that has decent configuration and build management. Manufacturing has a better construction record. However, the amount of investment it requires is tremendous. Try retooling your whole factory in a few weeks to produce a very different widget. This happens very often in software, though.

Mismatched metaphors are sometimes applied by project managers, but it's only deadly when it's applied from a higher level. When most of the upper management believes that software is "like" some other thing (other thing often being a process where fabrication is very expensive), be very afraid. Software is not like any of that. If it's close to something, you could pick, say, producing music on tape. Except that music is never tweaked once it's on tape! So there's really very few things that are similar.

To summarize: Software is unlike any other human creative activity. Treat it as such and respect its differences.

Unrealistic expectations

While people who don't know software shouldn't decide on methodology based on other things they know, people who know software just a little bit can be very dangerous, too. Often, they have certain expectations as to how easy or hard certain things are. They'll estimate times based on this instead of asking their staff.

To be fair, I've seen this mostly happen when past staff had the nasty habit of padding their schedules by way too much, either to goof off or to hide the fact that they have no clue what's going on. But it's not always the case, and if the staff changes, there's no reason to keep judging the new staff from the old standards.

But sometimes, they just have no idea how complex the software has become, or they were used to shipping very "quick and dirty code" (this is the case for many senior execs in startup companies who used to code) and that low level of quality is not acceptable anymore. Also, sometimes technology changes, and it's unfortunate that some new technologies in the realm of software have reduced programmer productivity rather than augment it.

Now, this is no excuse to let programmers goof off. Find one that has a history of delivering good results. Good estimating skills are nice too, but most valuable is the ability to smell "trouble areas" in requirements and designs. That person is probably a good sounding board on whether estimates are bunk. If such a person is giving you vague answers, it's likely that the problem is mis-scoped or that the code is of enough complexity that the person is unsure. In those cases, be willing to give them some slack.

Also, never underestimate the power of an existing codebase to ruin your day. Especially if those who wrote that codebase have left.

In summary: Don't expect anything. Ask your technical staff what to expect; it's more likely to be correct.

Fads

It's interesting how software is often managed with the expectation that it works like a manufacturing project, but management itself behave like youths, sniffing for the latest trends and acting like fad-crazy dolts.

For better or for worse, the IT industry is full of "fads" that keep ruining projects. They do provide a lot of fun for skilled programmers, as they provide new things to do and learn. But unless you're building a prototype or you have a lot of spare cycles to spend on exploratory products, it's not a good way to select technology.

There are, of course, new technologies, and those should be adopted. What make fads different, though, is that they always claim to be a silver bullet, but you must apply them to all your code and use them properly if you are to reap the benefits. So huge rewrites of a somewhat crufty but at least working codebase are ordered.

Note that there are reasons to rewrite large pieces of code, especially if the code is presenting serious structural problems or if it was left to the tender mercies of bit rot. But implementing a new technology by rewriting an existing application is very dangerous. First, because unless you're fanatical about documentation and process, the enumeration of everything that application does is not available. The application will have a bunch of features, behaviours and quirks that everyone is used to, but that nobody really knows completely. However, new technologies is nearly never one of them. What you need is either an adapter, or a fully new product, with a new name, so people don't expect the same thing. For more on this, see this Joel on Software article. Note that Joel was later proven wrong about Mozilla; in the long run, they did the right thing. But they aren't a commercial entity, and most software is done by commercial entities that cannot afford to wait that long because that'll only mean the code will be lost.

So, to summarize this somewhat rambling point: don't let fads rule your product roadmap. Don't accept projects that embrace a new, never used technology without prototyping first. New technologies must always be explored, and programmers should be given the chance to play with them from time to time (on company time, otherwise it won't get done; don't worry, once you've given them some company time to play with it, they'll probably put more of their own time, because it's fun). But don't let the latest trade press articles make you plunge headlong into using this new whizz-bang without due consideration and a technical exploration.

Piling up stuff

This one's simple: the temptation, when a product is already late or borderline, is always to add features "while we're at it." This makes no sense, but still happens. Don't do it. It makes things later. Ship the damn thing, whatever it takes, then schedule time to add those additional items.

Unless your customer is very tolerant of slippage, adding stuff since you're already late does not make sense. It's likely programmers will still kill themselves to get the stuff out. You end up with a pissed off customer (since the product was promised earlier) and a pissed off staff. The former can be damage-controlled; the latter cannot. A pissed off staff is a very, very bad thing, and you should take it seriously.

If you must add stuff, or fix bugs, move the deadling. If you do anything else, you're playing the ostrich. The deadline will slip. No, the slack time the PM put in cannot be used to fix extra stuff; it's already used because software is still an inexact science.

Multiple lines of power

This one is my favorite. It's also the most common.

When it comes to making decisions on a project, there should be one person with the power to move deadlines, cut features, leave bugs in, send programmers home to rest, and so on. That person is the one with the responsibility of the project succeeding or failing, usually called the project manager.

If you give responsibility to somebody without giving them those fundamental powers, you are setting that person up for failure. That person is likely to sense that and not work at the best of her abilities, to say the least!

I've been on countless projects where technical decisions were taken in advance, during the project, without advice from the developers, and over the head of the project manager. This is wrong, and a recipe for problems in the very near term.

That doesn't mean the project manager should ignore advice from others. But that person makes the final call. With responsibility, equivalent power should be available.

Well, that was my own somewhat conceited list. Most of those are management responsibility, though, and unlike some programmers, I do not believe software always dies because of management problems. Here's the list of "programmer sins" if you will:

Falling in love with your own cleverness

I think every programmer has seen either one of those:

• A program with code so compact and so obscure it's impossible to figure out what it does, but the original author claims it's "really efficient;"
• A program full of design patterns and deep inheritance hierarchies, but which doesn't use them (how to tell? Look for a lot of unused classes, or a lot of intermediate base classes that have only one derived class...)

I pity you, because you've found code written by a programmer in love with his own cleverness. The resulting software will usually work for the first version; the next version will probably slip badly, because it carries too much obscure code or too much extra baggage that makes it impossible for anyone to tell how to do the work.

Refusing to compromise

Clean design and clean code is incredibly important, but sometimes, you just have to grit your teeth and do something that you know is a bad compromise. This is never the case if the project hasn't slipped (and a project which was late before it even started does not qualify as a slipped project!) or for things that have an effect on persistent data (because you usually can't fix them later, at least not without import/export conversions and other nastiness). Also, it's not a good idea if the shop where you work never schedules time to clean up those things before even starting work on the next project. You'll know after a few releases. If that occurs in your shop, well, I pity you; I'd also tend to consciously let that particular release slip so you can do it properly, or later releases will slip much worse.

But face it, sometimes the company faces non-technical requirements that will force you to do something nasty. Don't refuse it. Make sure you document it well, though.

Overgeneralization

It takes a lot of practice to be able to write reusable toolkits and frameworks. And even then, they're likely not to be that general. Resist the temptation to do it until you've studied a lot and done a couple, complete with mistakes.

Beginners (myself included when I started out), especially bright ones, tend to write very general pieces of code. Coupled with a lack of experience at writing readable code, this can create a little piece of code that nobody can quite figure out. Plus, all that effort spent on generalizing the solution is likely to be wasted, since you'll find that:

• People end up doing custom solutions instead because the general solution is too hard to use or too obscure;
• The software ends up never needing so much generalization anyhow.

Reusable code is hard to do. It requires good taste, experience as to what level of abstraction is needed, and the ability to write extremely clear code. If you feel you lack any of this, don't write generalized code.

Copy-paste programming

This usually works well for the first release, but the second release will suffer. Bugs are duplicated by every cut-and-paste. Try to factor out common code in functions. That's what they are for.

One would think people would know that, but every piece of code I've ended up having to maintain used copy-paste in obvious ways in several places. Don't do that! Avoid it like plague! With modern refactoring tools that can extract functions from a piece of code and so on, time constraints aren't even a good excuse anymore.

Note that I've been known to do so for optimization reasons (because Java strings suck), it was always very, very well documented and I've always kept the copied code right above the pasted code. So if you really have to do it, at least make sure it's not all over the place.

Too many things at the same time

Note that this is sometimes a management pathology as well. But programmers shouldn't be too quick to point at management, as it sometimes happens because they did not communicate certain problems.

Programmers should always resist the temptation to do things in one big batch that cannot be tested in the interim. Do things in small steps. Test each of those steps to make sure every step does what you expected and has no embarrassing side effects. Fix any problems, then go to the next step.

The point of this is that by doing things one at a time, you can tell which thing you did broke what. So, try to do one thing at a time and test each one of them.

Projects sometimes fail because they run out of control. Programmers do a huge batch commit to the source tree which breaks everything at once. Huge commits are not a problem per se; however, if the whole thing was done in one shot, and if the huge commits repeat themselves, expect trouble. Things will start breaking left and right, and nobody will be able to figure out what caused it.

The last project I worked on that had that problem still exhibited severe instability until we got fed up and spent nearly a year rewriting huge parts of it. That was after nearly a year and a half of being completely b0rked, unpredictable and unable to change to accomodate features required by customers. Last I heard, there's still parts that are b0rked. As I remember, it started going unstable when people did those huge, deep-impact commits that always changed 2-3 different things at the same time.

Well, that's pretty much it. I'm not sure whether those are the "top" reasons for failure in software projects, but they're the ones I've seen the most often for projects that got in serious trouble.