Any fish will be less fishy the fresher it is. But try swordfish, I'm not particularly fond of seafood and that's one of the more tolerable ones.

A not insignificant number of times. It's not always appropriate, but for certain things like traversing trees as someone mentioned, it can save you a lot of ugly code otherwise.

There's definitely something to be said for clarity. Not just from the aspect of someone else having to support or extend your code, but sometimes just coming back to your own code after a period. Something about a hammer and nail comes to mind.

Microsoft seems to be very good at that. They take something **almost** great and mediocre it up for no good reason. I don't know if it's project manager overload or what so often throws them off target, but there seems to be a pattern of promising products followed by the let-down. "What was that?" "We need total concentwation. Now, twy again."

Actually it can. Just because something is working, right here, right now does not mean that it's good code. It simply means that it was adequate in the moment. People leave, move to different positions etc... so the chances are high that someone else will have to follow along and attempt to update or add to your code. If they can't figure it out, or unknowingly spawn bugs because it's so difficult to follow the horrible mess you left then I don't think that fits what one would call good code. When there are pressing business reasons driving those changes or additions, that "good code" suddenly looks much less "good". Even changing your own code, if you don't design it well it's very easy to get caught with your pants down when unexpected requests make you realize that you need to rewrite a large part of an application. This also seems to be one of the harder concepts to communicate to business people, the need for time to structure seemingly simple things properly. Sweat more now, bleed less later and all that. Still, sometimes you just have to hack it up and get something working, but it shouldn't be the default approach.

I've actually got a kiosk type application that runs 24-7 on Firefox. IE would just crash itself periodically. Chrome had it's own issues with random pauses and laggy image rendering. I don't usually use FF as a browser, but it's been solid for this application.

Deep recursion could potentially stand to be replaced with a goto. The problem as others have mentioned is that it has been heavily abused. And since it usually would only be needed under a limited set of circumstances it's better to just make it off-limits unless someone can make a compelling case for its use.

This is why it's good to always explcitly define your intentions with the proper parenthesis. It makes it easier to detect mistakes like that and for someone else to read and deduce your intent. You can easily produce similar errors in logical grouping in C# or other languages. Even if not with that particular syntax. ;-)

If you put onerous password requirements on people, you'll just increase the incidence of people simply writing them down. Users that have trouble typing normal text aren't going to be keen to have to type in some long bit of gibberish every time they have to login.

It's not as simple as having a team or an individual. Teams can be onerous depending on the personalities, authority, type of tasks, process applied, etc... They can also be very productive if kept small and focused. And focus is the great benefit of the lone individual. We become less productive the more we're distracted from a given task. Introverts are not necessarily high maintenance, in fact I would generally say it's the other way around. If they are then they probably aren't being managed correctly. But there are social aspects of being a developer apart from working with other developers or not. One also sometimes has to interact with managers, business people, vendors, clients, users, etc... Often the developer is also required to be a business analyst, artist, technical support, and on and on. Many roles falling under the umbrella of "developer" that require good skills in asking the right questions and getting the needed information out of someone that may not even realize what the answer is themselves. So you put the right people in the right roles based on all the properties of that individual. A mistake often made is seeing developers as interchangeable cogs, and assigning them to something based solely on a list of technical aptitudes. Ultimately it's ALL individuals and viewing it otherwise will eventually lead to problems.

Perhaps, but I think there is a distinction to be made in WHY they are too big. One can minimize the size in ways that are more or less flexible. Obviously they chose one that was less rather then more.

Certainly, but there are usually a lot of other optimizations that can be made that will make much more difference. You're almost always better off trying NOT to design something that can be easily broken through usage patterns. The PITA you save may be your own.

I'm fed up with trying to use a phone for anything more than talking. I've considered getting a tablet (probably a Tab), but after fondling them and trying some out in the store I think I would be much better served overall by either a netbook or full on laptop. The tablet has it's place, but until it can read my thoughts, a keyboard and mouse will still be more useful for anything requiring more than small inputs. That's the real downfall of compact devices in general, the human interface. It's always a compromise in multiple ways. In the future, I think phones with larger, low power, flexible displays will edge out tablets in general anyway. Maybe someday.

I say you're just mostly wrong about that. Often it's as important, if not more so, to know WHY something is coded like it is as to see the code itself. Comments should tie the parts together and provide a concise lead-in to the code itself. Not to say that logical procedure and variable naming isn't a huge help, but good comments can make big difference. Of course the unfortunate thing is usually that bad code is accompanied by bad or no comments.

Yeah, no. The real bottleneck now is not the machines, but the human interface. Tablet, desktop, laptop, handheld, all variations on a common theme. Better, or completely different types of displays, flexible, rollups for instance and direct thought controlled or motion capture input will be the next big boom. Keyboard, mouse, monitor, have all been refined, but they have fallen FAR behind in relative advancement over the years.

I usually write an empty shell, and start inserting comments as placeholders for functional blocks within that. It gives me a good target to throw code at when I come back through. I've seen far too much code that was horribly written and near impossible to update and maintain. I try not to leave it like that, at least commenting on anything worthwhile I dicover while going through it.

That's a good point. I've almost gotten into an actual fight in a meeting with a business person that could contradict himself at the rate of about 3 times every 10 minutes. And swear up and down with a straight face that's not what he told you 5 minutes ago. During meetings or phone calls, take notes. Then write up an email afterward with what was agreed on and send it out to everyone involved to get "official" approval. "Here are my notes from the meeting. Could you confirm that this is what you would like us to do?" Or something to that effect. Make it explicit and complete, double check it for vague or misleading language. Even in long email strings it may be necessary toward the end to summarize into a more concise form what you've been hashing out and get a final approval on what is actually going to be done. You can be tossing around options, and it can get confusing about what you're actually going to do or not do. Especially when you have a client that waffles like IHOP. If you're billing time, it's hard for the client to argue against hours after changing their mind about what they agreed to in an email. And it can save you a lot of hassle and hair pulling down the road.

Should we assume that it wasn't done intentionally as a temporary bypass?