(Comments added for week ending Sun 20 Oct 2002) | View Other Weeks
| last updated:21 Oct 2002 16:35 UK time |
|
| JOS Statistics - Recent Comments (Comments added for week ending Sun 20 Oct 2002) | View Other Weeks |
| Terminal Services - just my two cents | Sun 20 Oct | jon Kenoyer |
| I currently work in florida for a company in Seattle (www.otsi.com plug plug). My workstation for the past two years is still in Washington and I log into it using Terminal Services just like I was in the office . I run in full screen mode at 1280 x 768 and usually can not tell the difference. You need broadband to pull this off. TS is fine on dial up for admin stuff but not for 8-10 hours a day. Also set it to cache bitmaps and be sure to run in full screen mode. If you run in a window its noticably slower (I assume since its scaling to fit the window). I also work on a wireless laptop running FreeBSD and RDesktop, a TS client, is actually better then the Microsoft client. It seems to be less laggy, doesnt lose the connection as often (about once a week or so usually.), and fully supports the keyboard commands. Alt-Tab being my windows client pet peeve. With the Windows client alt-tab actually switches between the TS window and your actual desktop. Good times all around ;) |
| Sun 20 Oct | An anonymous XP User | For what it's worth, the Windows XP terminal services client handles Alt-Tab correctly when you're in full screen mode. That is to say, it transmits the Alt-Tab to the remote machine rather than shuffleing windows on the local machine. |
| Sun 20 Oct | Albert D. Kallal | The great thing about TS is that it gives the windows world a thin client. It really is too bad that we cant extend TS to operate a single window/applicaton. That means I should be able to launch word on your PC, but have all the output sent to a window on mine. (that way, I would not need windows to be virtualized like it is with TS). This is of course how x-windows works on Unix. If some comes out with a product that splits the output window from the application, then this would allow some real cool stuff. I could for example run the accounting package down the hall without it being installed on my PC. Or the tax calc program in the cubicle next to me could be run, and I would not have to install it (why bother when I only run it once a year..). By the way, if anyone is looking for a real cool application for windows that will turn heads at Microsoft and make/force them to buy you out, then take the above suggestion of mine and run with it. All you have to do is create a product that uses the RDP protocol, and gives us a socket for each application window. Voila, instant application sharing across the web, and within a company. It would also open doors to disturbed processing. Since TS can now enable any windows program to run across the web, why would anyone even bother re-writing any software for the web when you can web enable any software with zero re-writing? Why even bother with .net now that we have TS?? My thoughts, and answer to that question can be found at: http://www.attcanada.net/~kallal.msn/Articles/ThinClientsand.net.html Albert D. Kallal Edmonton, Alberta Canada Kallal@msn.com |
| Sun 20 Oct | Joel Spolsky | Albert, isn't that what Citrix Metaframe is supposed to do? |
| Standalone XUL Application? | Sun 20 Oct | Anymouse |
| Anyone know if it is possible to create a standalone application based on XUL? Id like to use Python or Java as the programming language and XUL as the UI, but I dont want to have to require users to have Mozilla 1.0 already installed. So basically, I want to be able to create a packaged app using XUL for UI, without pre-requiring the user to have Mozilla. Possible? |
| Sun 20 Oct | Simon P. Lucy | You'd need pretty much all of Mozilla to do it. XUL is rendered so you'd need the browser component anyway, along with the NSPR, XPCOM, Javascript, the image libraries Uncle Tom Cobbley and all. The things you wouldn't need come down to functional modules like mail but I don't think anyone has actually mapped all of the interconnections and dependancies. You'd be better off having two installs, one which was just your XUL application and the other including the Mozilla build you relied upon. |
| Sun 20 Oct | Joel Spolsky | It looks like these people http://www.activestate.com/Products/Komodo/?_x=1 just ship the version of Mozilla that they know works for their app. Which probably means the smallest XUL app is around 11 meg. (Better than the 22 meg .NET CLR runtime!) |
| Sun 20 Oct | Chris Hoess | See also http://www.mozilla.org/projects/embedding/MRE.html , which is aimed at letting embedded apps 'share' suitable versions of the rendering engine. |
| Sun 20 Oct | Anymouse | It doesnt seem easy/trivial to pull the XUL components out of Mozilla and create a runtime that allows for standalone XUL apps, at least for now. I'll try to see if the people at ActiveState distribute the base 'runtime' for Komodo, but I doubt it. What about wxWindows? Anyone used it? There seem to be interfaces to it for C++ (native, duh), Perl and Python. (www.wxwindows.org). I think there are some commercial products which use it also. Any opinions about it? -M |
| RSS Stuff | Sat 19 Oct | Luke Francl |
| First of all, I imagine a big reason why NetNewsLite is more popular than Radio is that it doesnt cost any money, where as Radio costs $40 a year (granted, Radio is much more than a news aggregator). Second, regarding RSS aggregators pounding your site. Im one of those people who subscribe to your RSS feed; thanks for providing it. My aggregator (AmphetaDesk see: http://www.disobey.com/amphetadesk/ ) defaults to 180 minutes between fetches. I left it at that setting. Theres no way to specify in your RSS feed itself how often aggregators should check. Dave Winer and others have done some work on publish/subscribe systems, like weblogs.com, where the updated weblog pings the server to tell the server its been updated. If you need to reduce the bandwidth that the RSS aggregators are using, you can either do as you suggested and only give out a headline (many sites, especially news sites, do this). I would also recommend reducing the number of stories in your feed. Youve currently got 10. You could easily reduce that to 3 or 4 and satisfy most news junkies. |
| Sat 19 Oct | Joel Spolsky | Thanks Luke! I'll try reducing it to 3 items. |
| Sun 20 Oct | Jeremy Dunck | Also, you might consider setting expires headers in the HTTP response. This allows proxies to cache your content, and therefore serve requestors without placing load on your server. The downside is slightly less control over what's delivered to the requestor (since you might make a change before the cache expires), and slightly less accurate statistics in your web server logs. Anyway.. The HTTP 1.1 RFC covers this (http://www.ietf.org/rfc/rfc2068.txt?number=2068) Specifically, page 101 is the beginning of the functionality you're after. HTH. |
| Sun 20 Oct | Chi Lambda | Does anyone know of an online tutorial for making a web-based RSS aggregator using ASP? |
| Sun 20 Oct | Matt Jadud | As yet another idea re: handling the RSS issue, I wonder if RSS 2.0 is extensible enough to include a 'refreshFrequency' tag. This would allow the RSS author to embed a directive to RSS-gathering applications. That tag could either be a number (in hours?), or a semantic value ('hourly,' 'daily,' 'weekly'), but preferably only one type or the other. You are in a better position to suggest this to Brent and Dave than I am, I believe. Personally, I enjoy not having to jump from my newsreader to the WWW to read the content on your site, but what you do with your RSS feed is up to you. |
| Sun 20 Oct | Bernard Vander Beken | As explained in the paragraph 'ETag' at http://bitworking.org/2002/06/02.html , an RSS aggregator does not need to request the entire RSS file on every check. This reduces the waste of bandwith and speeds up the RSS update checks. An example of an aggregator that supports this feature is Aggie. |
| Sun 20 Oct | Phil Ringnalda | refreshFrequency: turns out that was actually one of the things Dave was thinking about when he added the ttl element, even though the spec only mentions using it for Gnutella. Cutting back: don't know how much control over the RSS you have (well, without rewriting the routine that generates it), but someone in my comments suggested full content for the first few items, and then just title or title/short description for the rest. That would better serve people who are adding your feed from somewhere other than your website, where they haven't seen the older items, than just having two or three items. Also from my comments ( http://philringnalda.com/archives/002359.php#comments ), Morbus (the author of AmphetaDesk) is curious about just which UAs are the ones giving you trouble by asking for too much too often. |
| Sun 20 Oct | Joel Spolsky | The HTTP HEAD method seems like the right way to go, in fact, it already works for me as a publisher because my site is served by a traditional web server out of static files. Looking at my logs, it's pretty clear that Amphetadesk is already doing this and saving about 1/2 a meg a day per subscriber as a result. Radio, NetNewsWire, and 'Mozilla/3.0+(compatible)' (whoever that is) are not. |
| Sun 20 Oct | Frank Leahy | You would save on bandwidth if RSS aggregators made conditional rather than unconditional GET requests. This is as simple as them adding an If-Modified-Since: header to the GET request and handling both 200 OK and 304 Not Modified responses. This means that RSS feeds will need to respond to the conditional GET properly, but it should be easy enough to do. |
| Sun 20 Oct | Charles Cook | I'm surprised (well, maybe not) that Radio aggregators are hammering your RSS file. A fix using ETag was discussed back in May was brought to the notice of at least one of their developers: http://www.pocketsoap.com/weblog/stories/2002/05/19/bdgToEtags.html I assume your logs distinguish between requests which return the file and those which return the 304 status? |
| Sun 20 Oct | Joel Spolsky | Yeah, I was looking at the total bytes |
| Translations? WTF?! | Sat 19 Oct | janto |
| I know this was already discussed previously, but I couldnt find a (serious) response from Joel. So: whats up with the translations? If its for some kind of unicode-and-parallel-versions-dogfood-tests it would make sense, but 30(?) languages?! |
| Sat 19 Oct | Bob | Joel asked for volunteers who knew other languages to translate. He posted what he got. I imagine if he gets 60 languages, you'll see 60 languages on that list. Seriously, can we find actual important things to worry about? Bob |
| Sat 19 Oct | janto | I just thought there was something profound I was missing...seeing that it takes up almost half the space on his navbar and he mentions it quite often(ish). |
| Sat 19 Oct | Joel Spolsky | I guess the profound thing you're missing is that for most people in the world, English is not their native language... Or is this a troll. Or did you have something more important to do with that screen real estate. |
| Sat 19 Oct | Stephen Jones | A cutting but rather accurate reply. Still he does have a point about the different language version links taking up space. I would consider moving the other links like the forum links, to the top at the very least. Salut i força al canut! |
| Sat 19 Oct | Troy King | I'd also like to see the 'Discuss' links moved above the language links. As it is now, I have to scroll and scan to find the things. As Steve Krug would say, that's too much thinking. |
| Sat 19 Oct | Evan | Wow! How dare Joel waste a precious inch of your screen, or cost you a second of your day! If Joel wants to do a version of JoelOnSoftware in Loglan, and finds someone to do the actual work, then he is more than welcome to. Especially if it leads to sales, and costs him nothing. There are a lot of programmers out there who do not read English. If Joel wants to provide content for them, who are you to complain? If this then leads to sales from countries that no one has even heard of, in good old American greenbacks, is Joel going to complain? I think that one of the major problems with technical people is that they do not have a clue how a business is run, or what it takes to run a successful business (or even an unsuccessful one). Oh, they think they do, but when you get down to it, their ideas basically consist of big neon starred arrows pointing at themselves, and unlimited budgets. |
| Sat 19 Oct | Alex Chernavsky | And while we're on the subject of links, I'd also recommend deciding on whether you want the citydesk-related URLs to be written in all-lowercase, or as 'CityDesk' -- and then make then consistent throughout all of Joel's pages. Otherwise, the link colors get messed-up depending on which CityDesk/citydesk URL you click on. |
| Sun 20 Oct | janto | Look, all I wanted to know is why _Joel_ thinks it is worth that much space on his site. It obviously has nothing to do with _my_ screen or time. I come here to learn stuff from Joel. I value his opinion. So if he thinks something is that important, I would really like to know why. Why would it matter to Joel that English is not everyone's main language? What's he trying to accomplish? A bigger audience? Wouldn't it be easier to get more _English_ speaking readers? That market is hardly 'saturated'. These seems like valid questions to me. No hostility intended. (btw I don't really appreciate the tone of all the responses I received. I am not a troll. And English is not my native language.) |
| Sun 20 Oct | Attending the wake | I think you've likely been misunderstood because you aren't fitting the prevailing sociolinguistic pattern (tricky to do if English is not your first language). Look at the other thread titles. Even the critical ones are generally in mature and sober language. Your 'WTF' comes over like a lip-fart at a memorial service. This tends to bring readers in with a predisposition to be hostile. Learning about the cultural impact of words and phrases is one of the reasons why I love the translations on this site. As an English-speaker who likes to study foreign languages, it's invaluable for me to see how native speakers combine the humour, slight irreverence, and serious technical discussion combination which characterises Joel's articles. If I just had the foreign language article to go on, I would never be quite sure that I was judging the tone correctly. Having said all of which, I do think that the long list of languages, when it first appeared, struck me as making the page less tidy than it was before. But that is Joel's call ... |
| Sun 20 Oct | janto | Yeah, you're right: The title is a bit strong. I wrote it that way to catch the eye. Sorry. (Might also have been due to visiting penny-arcade just before posting :-) OK, I get the feeling that this thread is starting to get touchy. So can Joel just tell me why he would want non-English speakers to be able to read his site. |
| Sun 20 Oct | John C | > So can Joel just tell me why he would want non-English speakers to be able to read his site. I can't believe anybody could ask that question without knowing the answer. It's so blindingly obvious. Surely the question should be 'why would Joel not want non-English speakers to be able to read his site?'. And the answer would be that there isn't any reason. |
| Purpose of affiliate links in the Fogbugz review? | Fri 18 Oct | Tj |
| Could someone explain the effect of the affiliate links in the review Joel linked to? http://archipelago.phrasewise.com/stories/storyReader$1285 It contains links like this: http://redirect.fogcreek.com/?id=affdaniel&url=http%3A//www.joelonsoftware.com/articles/fog0000000029.html Thanks. |
| Fri 18 Oct | Tj | Oh, I see. http://www.fogcreek.com/Affiliates.html |
| Sun 20 Oct | X. J. Scott | Many years ago, a product reviewer who received a cut of each sale for a rave review was considered a conflict of interest, unethical, a violation of journalistic ethics, and in some juristictions, illegal. Am I the only person for whom there sorts of links work the opposite way intended? It just feels slimey all over to me. |
| Sun 20 Oct | Daniel Berlinger | Simply put, I didn't write a review. I wrote a recommendation for the readers of my site. And when I posted the link to the story on my home page, I disclaimed the affiliate links. Subsequently, Joel refered to it as a review. Since there are probably many more people who won't give someone the benefit of the doubt, I added the disclaimer at the top of the story. I'd like to know if you read any developer mags, because if someone wrote the same review for a magazine that takes advertising dollars, and who pays the reviewer, while the path might be more indirect, it's there and you never see a disclaimer in magazine review. That's why Consumer Reports is so careful about this issue. No slime on me about this. |
| Sun 20 Oct | Daniel Berlinger | BTW, If I hated FogBugz and wrote a scathing review that would be acceptable? Seems it would be worse, if stupid. |
| Concurrent changes to files under SCM control | Fri 18 Oct | Glade Warner |
| Should I be wary of concurrent changes made to files under SCM control? Software Configuration Management (SCM) programs allow editing the same file by more than one developer at the same time. When the file is checked back into the archive, a merge must be done so that the both sets of changes are saved. Ive always avoided concurrent changes to a file to avoid needing to merge. Documentation on ClearCase (an SCM tool) looks to me like the concurrent changing of a file is not just tolerated, but perhaps encouraged. Should I encourage concurrent changes to files? What success or failures have you had with merging files back into the SCM archive? |
| Fri 18 Oct | Nat Ersoz | Having a source files open by multiple developers is common. The key to success is having a capable 'merge' tool. Do not fear concurrent changes and trust your tools. Personally, I don't like Clear Case because it forces you into branching and merging for every group of check outs (so you are forced into merging with every checkin). But, if that's your tool, and its what your company uses, then you'd better get used to it. |
| Fri 18 Oct | anonQAguy | Generally, better to avoid it where practical. Should not be the norm. If you find you've routinely got > 1 developer actively editing a particular piece of code at the same time, you may want to reevaluate how much code you put in a single file. Our practice here is to keep the individual files relatively small, at least in terms of functionality covered, reducing the likelihood two of our guys would be working on the same piece at once. I personally do not trust any sort of automated merging, and unless the diffs are very independent and relatively simple, even manually scanning in a diff tool and doing the merge 'by hand' is normally an unnecessary extra risk I would not see as worth it compared to just working it out among the developers who's going to edit when. I wouldn't agonize over it, if you really have to do it sometime, then do it; you should just not make it a common practice. And take what the SCM vendors say with a grain of salt -- their purpose in life it to sell you their stuff, not sit with you and resolve a merge and then through the night with your folks doing testing needed to wring out any oddball new bugs there might be. IMO, in the ideal world, nobody would ever have to branch or merge - we could all keep nice, clean, linear code lines. We can't of course, but staying as close to that as circumstances permit will normally simplify your life and reduce your risks. |
| Fri 18 Oct | anonQAguy | Oh - one thing I forgot. We do have a fairly small shop, which means merge situations don't tend to arise as often as would probably happen in larger shops. Well, they don't for us, anyway. So adjust/discard what I said earlier as appropriate to your team size also. |
| Fri 18 Oct | Robert Anderson | It depends, of course. What you want to strive for is to have developers working on well-defined orthogonal tasks, and to have code that reflects functional orthogonality in its physical layout. If both of these things are the case, you will have very few problems with merging. But closer to reality, you'll have some guys monkeying with overlapping functionality, and some guys doing things they weren't asked to do ('I just did a little clean-up in those files'), and your source code will have lots of loosely related things intertwined so that there may be significant conflicts when attempting a merge. The point is that there is no substitute for good management and a good code base. Concurrent development will be easy if you have those things, and possibly a nightmare if they are weak or non-existent. Bob |
| Fri 18 Oct | mackinac | It can be done, but it's not the best approach to SW development. I currently work in an environment where we do concurrent development using ClearCase. I don't trust the automatic merge tool for anything other than a trivial merge of a single branch. Manual merging can be a bit slow and tedious, but it's a lot faster than finding the bugs caused by a bad automatic merge. When I worked in an environment where each developer was responsible for a particular component or process the whole development process was easier and the code quality was a lot better. |
| Fri 18 Oct | Zwarm Monkey | I use Perforce and have NO problems merging concurrently changed files. If your changes overlap someone else's changes, then you must resolve the problem manually. |
| Fri 18 Oct | sgf | I always disallowed concurrent checkout on my projects assuming merging would bring nightmares. 3 years ago started current job where it was normal practice. I was shocked to discover how well it works. I don't think I've ever seen problem where the auto merger left things non-functioning. Less than 10% of the merges require manual intervention. This is with M$ VSS. I think the key is well structured software and responsible developers. Fortunately we have both. If you have code cowboys or spaghetti code I wouldn't try it. |
| Fri 18 Oct | Alberto | I do fear concurrent changes and try to organise myself to have exclusive access to anything I'm working on. It's not the tools I fear, its the human error. |
| Sat 19 Oct | Eric W. Sink | Don't knock it until you've tried it. No really. Try it. Ooops, did I use a cliche on the first line of this note? Sorry to be trite, but you actually should try it. Seriously, concurrent editing with merge provided by the SCM tool is something that works surprisingly well. Once you've actually tried doing it this way, it's amazingly hard to go back. I remember being a person who refused to trust merge tools. Now I can't imagine living without one. Still, people have very, very strong preferences about this particular issue. Reasoning has little effect on either camp. I'd be surprised if my advice above causes even one person to experiment with the edit-merge-commit paradigm, much less switch. We've designed SourceGear Vault (our upcoming SCM tool) to allow the user to choose their preferred style. This approach seems to work well in our own dogfooding, but I'll be interested to see if it seems as effective to our customers. Religious battles like this one are an obstacle to building insanely great products. There is something to be said for letting developers work the way they want to work, if it gets people off the battlefield and back to coding. :-) |
| Sun 20 Oct | Nat Ersoz | >> I remember being a person who refused to trust merge tools. Now I can't imagine living without one. Yup. It goes against everything I know to be true: 'don't send a machine out to do a man's job'. But, now merging has become a machine's job. Tough to get used to, but it works. You should see merging in the hands of our real perfoce expert - very scary, yet beautious... After being around our SCM guy for the last year, I now know the true bar to set all SCM guys by. I let the machine do the merge, and then review the results (diff's) afterward (using SlickEdit's diffzilla!). Its less error prone than me coaching the (perforce) tool or doing it by hand. |
| Sun 20 Oct | Simon P. Lucy | The problem with concurrent changes to files is not whether they'll be successfully merged or not by source control, but whether the human monkeys in the system realise its happened and why. I prefer, for my own sake of maintaining sanity, the concept of owning files and modules. This doesn't stop multiple checkouts, but checking in should be managed. The simplest way of managing them is to have the rule that you should check out, and possibly merge, before you check in, and test that result before checking in. If that process is going to take any appreciable amount of time then those files should be locked until its complete. This scratches my itch of paranoia and reduces the likelyhood of the build dying because two or more checked in syntactically valid, but practically broken code in consequence. |
| Sun 20 Oct | Tj | To me it's a social problem. When I'm in someone else's code, and I'm not working close with her, I usually just want to open up an accessor or something. Otherwise I send her a quick email describing what I intend. It's not the merge that matters, but the fact you may be introducing errors in someone else's code. |
| Sun 20 Oct | Andrew Reid | In my experience, the vast majority of problems with concurrent checkins come down to developers just plain not understanding how to manually resolve merge conflicts. Standard operating procedure at my last job was to blame the code loss on bugs in VSS :) If your checkin conflicts with that of another developer, I think it's good practice to ask them to check you haven't accidentally removed any of their changes after you've checked in. Actually, it would be nice if the version control software automatically emailed you every time this happened (ie someone else does a checkin that was merged with yours). |
| Success in science | Thu 17 Oct | Alex Chernavsky |
| I read the _National Review_ article that Joel referenced in his blog entry. Im not going to comment on the main point, but the author is wrong when he says that success in science is highly dependent on sheer intellectual firepower. Sure, you need a certain amout of brains just to get into graduate school and get your PhD. Beyond that, though, your success is far more dependent on your level of dedication and on your ability to get along well with the people around you. (Caveat: I think physics might be more dependent on brute-force brainpower than the other sciences.) I spent about five years hanging out with biologists. The most successful biologists were the ones who practically lived in the lab, and the ones who were good at networking (helps for getting grant proposals approved). The slacking brainiacs -- and the arrogant loners -- didnt do so well. |
| Thu 17 Oct | Troy King | Plus, the article furthers the 'form a hypothesis then work toward it' they teach grade-schoolers. Most discoveries are accidental, or side effects of what-ifs, or deductive analysis. Sure, mini-steps are made on the hypothesis-then-test model, but not many of the big leaps are. |
| Thu 17 Oct | 80min | You guys might like reading 'The structure of scientific revolutions' by Kuhn. Here's a good outline: http://www.emory.edu/EDUCATION/mfp/Kuhn.html |
| Thu 17 Oct | Alex Chernavsky | I've read Kuhn's book. I don't see how it's relevant to the matter at hand, though. |
| Thu 17 Oct | 80min | Then you haven't read Kuhn's book! It's all about what constitutes success in science. |
| Thu 17 Oct | TK | I didn't see this article as about science in particular. I thought one of the main points is about the very difficult job of managing talent. This is a constant topic on forums. What attracts talent, what does it take to manage talent, what kind of management does talent respect: Certainly not always the nicest guy or best politician. Another point is the risk of aiming talent in the wrong direction. Or, more topical, how easy and dangerous it can be to squander talent. In other words all the talent in the world may be on a wild goose chase. |
| Fri 18 Oct | Julian | For theoretical physics, in which I receive my Ph.D., sheer intellectual firepower is the most important factor determining success. Motivation and communication skills have secondary importance. The article has a simplistic portrayal of the scientific process, but that's irrelevant to his main point. The intelligence agencies need brilliant analysts and leaders, but cultural and organizational problems are equally important. For example, the rivalry between the FBI and CIA kept them from sharing information with each other. The traditional FBI focus on investigating crimes after they've been committed was an ineffective approach towards fighting terrorism. The FBI has a poor computer infrastructure, in part because they value agents in the field far more than desk jockeys. CIA director William Casey was a very scary person, even if was as brilliant as the article claims. Finally, after reading a National Review article about the importance of brilliant leadership, I can't help wondering whether that same reasoning applies to US Presidents. |
| Fri 18 Oct | Alberto | To me, all he was saying was 'we need superman'. Clutching at straws I think, if what he says is true then the ills of the various intelligence agencies are endemic and will take years to rectify, if ever. Nobody ever expected such a large number of people willing to die for a cause. Suicide bombers are most 'unscientific' because science tells us that survival is the paramount human instinct. Mix poverty, religion, youth, lack of education, a cause, and a willingness to die and you have a potent weapon. The best wepon of the west is to reduce poverty and educate, as well as military intervention. It needs to be a multi-pronged approach, we need some smart people to remove the causes as well as stopping the effects. We need some 'human scientists' as well so that the solution can be worked from both ends. |
| Fri 18 Oct | Just me (Sir to you) | Any intellect above the 'minimal requirement' (which IMHO is very low) is a handicap in science. People with more brains tend to be fairly critical of the so called 'advances'. This includes their own 'accomplishments'. As a result, they tend to publish less, if at all. Most successful scientists are narcissistic egoists that truly believe they have pulled the world from their anus every time their mediocre grey matter comes up to speed with a basic outline of an idea that has been rehashed to the bone 100 times before. Science died when genuine curiosity was replaced by greed and stage play. The world is shocked when they hear about the forgeries at Bell Labs. One guy is ousted, none of the others is held responsible. Renowned publications amongst which Science and Nature have the audacity to state that their review process is beyond reproach. The dirty little secret is that everybody in the scientific community knows that faking results is common and daily practice in the murkier fields, where independent verification is non-existent. |
| Fri 18 Oct | Tj | I remember reading a paper written by this total asshole director of a lab. He described a (in his opinion) brilliant young applicant who didn't want to start by coming up with his own theories, but checking the theories of others. Being a sounding board, helping expand on ideas, checking things rigorously. And he blasted the applicant for not being ambitious, that no one wants a fly on the wall scrutinizing their work. I know his perspective, some teams can't handle such a person who isn't 'producing' all the time. But to blast him shows that people don't want an Erdös, someone who could be a great collaborator and eventually learn enough to make profound theories himself. The Erdöses of the world just have to look forward to only owning a briefcase while others get the glory. So to go back to the initial point, I don't think 'science' today is ready for great minds. The infrastructure in general is not there -- it's available for the mediocre minds because they make up most of the people. Rant off. I needed that. ;) |
| Fri 18 Oct | Jim McCarty | Tj, you bring up an interesting point. It's long been acknowledged that functional teams (the basic unit of research in industry) need more than one kind of worker/personality to do their best. As a chemist-turned-multimedia developer, I can tell you that my productivity was much greater while working in a team than when working alone; unfortunately this aspect of science does not get much press. If you doubt the importance of teamwork, just review the Nobel prize winners of the last couple of decades. The value lies partly in combining team members having varied talents. But there is another, equally important function of teamwork: collaboration. This takes the form of stimulating discussions and brainstorming with peers as well as the dreaded post-mortems or drawn-out meetings with management. After all, how does one get support for new and good ideas, or figure out whether to not to trash poor ideas, without hobnobbing with your fellow wizards? The bull sessions, stimulated by present company as much as coffee or beer, turn out to be as much a part of scientific development as meeting with cohorts at international conferences. In truly functional research teams, all members are considered peers, and all opinions matter; otherwise there is not much point in working within a team. Prima donnas notwithstanding, the work *and thinking* is done by all team members, not just the head honcho. I suspect that the intelligence community needs to look at this model, instead of continuing with business-as-usual: that is, top-down management, with everyone in the organization looking to protect his/her turf while simultaneously protecting his/her ass (the model almost universally followed in our society). |
| Fri 18 Oct | trollbooth | [So to go back to the initial point, I don't think 'science' today is ready for great minds. The infrastructure in general is not there -- it's available for the mediocre minds because they make up most of the people.] If history tells us anything, its that great minds don't give a shit what the anyone is ready for. The article highlights an excuse for the intelligence mistakes, is that they didn't have enough smart people. I'm sorry but that is just a piss poor excuse. Are they actually trying to imply that if you have enough brains in the intelligence area that they can predict the future? Give me a break. His whole motive for writing that article is not to move us toward a better tomorrow, but instead to comment on political society and generate income from those comments (see the book he is seeling at the bottom). Everyone has an answer for how to change yesterday, it's tomorrow that baffles even the genius. |
| Fri 18 Oct | David Clayworth | Nice try, Justme, but those of us who have worked in the field aren't falling for it. |
| Fri 18 Oct | Ed the Millwright | Great post, Justme, those of us who have worked in the field know you speak the truth. |
| Fri 18 Oct | TK | Humans are involved in all fields. There is no harkening back to the good old days when science was pure and without ego, ambition, politics, or greed. In fact those things are primary drivers. The bright folks are no more or less altruistic than anyone else. Never have been, never will be. |
| Fri 18 Oct | David Clayworth | Of course if I consider myself a successful scientist I have to recognise that someone else's answer is as likely to be valid as mine. |
| Fri 18 Oct | Alberto | It seems to me that 'passion' is a characteristic of anybody who has solved, cured or discovered anything of significance (atom splitting, penicillin, electricity etc). Like all forms of work, the successful participants are passionate, and the rest of them are just working the cogs. Scientists are no different? |
| Sat 19 Oct | Jar jar | I don't think the comparison between the Russians in the 80s and Al Qaeda now is valid. First of all, the CIA knew the Russians were a threat back then. I'm not sure that anyone can say that the CIA knew before the attack that Albert Qaeda was a major threat to us. Second of all, Big Al Qaeda consists of about three absolutely nutty people that are scattered around the world. Russia was a huge country controlled by somewhat logical individuals that knew they would be killed in an all-out nuclear war. The Al Qaedians don't care if they die. The two situations are totally different. Russia was big, easily identified, and a known threat. Al Qaeda is small, hard to find, and was relatively unknown. Additionally, the main threat from Russia was an intercontinental nuclear missile. We had and have systems that would tell us if one of those puppies were to launch. That sniper in Virginny could be Al Qaeda. They just want to disrupt our society and kill as many of us as they can. And, they have God on their side, so if they die in thier 'cause,' it's no sweat as they'll be getting BJs from virgins for eternity. I'd much rather have been a CIA agent trying to stop a nearly broke Russia, than a CIA agent trying to stop someone who believes if they die trying to kill me they will spend eternity in heaven. |
| Sat 19 Oct | Alyosha` | I thought Meyer's article was a highly irresponsible suggestion on how to improve foreign intelligence. In a nutshell, his theory is this: come up with plausible prediction first, and spend your resources trying to find evidence to support this prediction. Does anyone have any faith in our intelligence/criminal prosecution system to think that this doesn't create a Procustean bed to which all observations will be neatly cropped to. His example of the US's view of the Soviet Union economy in the early 80s suffers exactly from his own suggestions: the CIA had a hypothesis of what they thought they should be proving, and were prejudiced towards evidences that supported this hypothesis, because they were primed to be on the lookout for it. Turns out this hypothesis was incorrect, and the CIA wasted a lot of time trying to justify it. Meyer's suggestion only works out if the hypothesis is correct from the get-go. 'Get it right the first time' is not a helpful methodology. Scientists know that ninety-nine out of every hundred hypotheses will turn out to be crap, but the last one generally turns out to be a doozy. Unfortunately, I doubt foreign intelligence can benefit from such a slow, laborious, and random process that depends so much on these rare and uncommon 'a-ha' moments. |
| Sat 19 Oct | TK | What was irresponsible was missing what, in hindsight, should have been more apparent. In fact many, if not most academic Middle Eastern scholars, whom we wrongly presumed to be scientists or at least researchers, the experts, were tragically wrong. Of course, all they risked is their reputations, which in fact seem mostly unscathed. After all, history, the social and cultural sciences don't have the burden of the hard sciences. |
| Sun 20 Oct | Tj | In other news, IBM has made gazillion-dollar screwups. And Microsoft is forecasted to be bureaucratic once Gates leaves. It is impossible to sustain the energy of an organization through generations unless the need is always great. Of course you want intelligent people, especially in an organization that calls itself 'intelligence.' What company doesn't. The trick is having intelligence up and down the ladder decade after decade. Anyway this whole thread is about the survival characteristics of intelligence. I think intelligence goes to wherever is most interesting and full of need. Intelligence is a liquid, if flows around. |
| Limitations of UML | Thu 17 Oct | Kelly Scott |
| So Rational pitches UML as the solution to all your spec problems. But specs were written well before UML was invented. What do you think are the limitations of UML? Do you feel that it has solved most of your problems? |
| Thu 17 Oct | Robert Chevallier | UML is just a notation, not a spec. It only helps because it gives us an unambiguous graphical vocabulary. However, IME, it just too complicated for use in a customer spec. It is useful only between developer and alike (sorry for my bad english) |
| Thu 17 Oct | Ian Stallings | I think that use cases can be good when doing joint development and you need to flush out exactly what the user does/needs. Although specs have been layed out before without using UML I still say it is essential to developers using OOP these days. Go pick up a patterns book and you see UML. Look in the specs for an app and usually you'll see UML. It's great for describing and API, sequences, and systems. |
| Thu 17 Oct | patrick | Personally, I really like UML although it seems to have some limitations when it comes to modelling data relationships. For database modelling EAR seems to be the way to go. We use it extensively in our CompSci course. Anyone know if UML can be used for this? |
| Thu 17 Oct | Igor K. | Specs exist in the problem space, while UML relates to the solution space. Moreover, UML represents just a snapshot of one solution. The mapping between these two spaces is a very important phase of design, and it's not mechanical. The bad thing about UML (when used as part of methodology, not just notation) is that, in practice, many architects jump ahead and start with UML class diagrams even before the proper analysis in problem space. The good thing is that UML is just a notation for diagramming, which became more or less standard. So, when you need to explain your existing system to someone else, you can use UML and don't explain what are those funny boxes and arrows. I remember the time when first Booch book came out and we started to use the old 'cloud' diagrams. It was good for internal design, but not appropriate for external presentations or articles - we had hard time explaining all the details of the notation. Now everybody seems to have at least general understanding of UML diagrams, so it's really a univeral language. But, again, UML is not a substitute for specs, design documents or source code. |
| Thu 17 Oct | Ori Berger | The graphical language might be unambiguous (sp?), but the semantics are about as ambiguous (or even more ambiguous) as a text spec. And it's semantics that matter. |
| Fri 18 Oct | Beka Pantone | UML is just a notation to comunicate by standard means. From experience I can say that crappy projects used UML to communicate crappy ideas, and good projects used UML to communicate good ideas. I have seen many good projects that never made use of UML. And I have seen UML so hideous that makes you wonder what was the point in the first place. I find UML to be useful if you work in a distributed dev team, or if you do work with a customer's dev team then UML is useful to specify system contracts. Frankly I think that you would be better off printing stickers and sticking them to the dev team monitors, something that reads 'think! then compute'... it can save you heaps of cash on CASE tool licenses. ;) Oh! one more thing... people often forgets about it, but pen & paper are a perfectly valid transport for UML. :) |
| Fri 18 Oct | Simon Lucy | This is a periodic kind of question. UML is a reasonable documentor and using activity diagrams, swimlanes and such its not a bad way to work out the wrinkles in a design. It isn't a panacea though. For data modelling I use ORM (Object Role Modelling), not only because it lets me design databases whilst modelling real world information but also because I can use it with the client and they can understand it. ORM is conceptual, its about facts. You then have the tool convert that conceptual model into a logical model (like an ER diagram) and from there you can generate your physical database. |
| Fri 18 Oct | Former UML evangelist, now back to real work | Having given quite several UML courses, being busy writing specs and as a developer, I can say that UML doesn't makes it for the customer (Indeed ORM is better for the application domain study, doesn't has the problems with attributes and can be made with the customer). UML is not very strong for GUI stuff and the behavior descriptions lead to spaghetti diagrams. So, the current state of affairs is - 'custom' UML on the whiteboard, a digital cam for taking shots for design stuff, - MS word for the specs (or DocBook with developers) and - tools like WBS Chart Pro (www.criticaltools.com) and PERT Expert for chaining tasks. A 500+ spec with only UML wouldn't say much to anyone. Plain text rules as UML diagrams are only a map to find out your way in the territory. |
| Fri 18 Oct | Former UML evangelist, now back to real work | BTW, Microsoft Visio Modeler is a free ORM tool that rocks ! |
| Sun 20 Oct | chris | Are you sure Visio is FREE???? Where is this? How come it cost us many hundreds of $$$ for our 5 licences? |
| Sun 20 Oct | Former UML evangelist, now back to real work | VISIO MODELER (ORM), not VISIO the drawing tool. |
| Sun 20 Oct | chris | Oh, I see. It is a seperate tool. |
| How do you reward dev team for software release? | Thu 17 Oct | Kevin |
| Every 6 months or so we release a somewhat major version of our software. As a team we try to do something to celebrate the release, such as have cake and ice cream, or go to a movie. My question is what do you do (if anything)? We are looking for some more ideas. |
| Thu 17 Oct | Nat Ersoz | Great question. Y'know, here is one problem with software development: it lingers forever. You need milestone events like these to wrap up the project and give people the sense of accomplishment - even though, come monday morning, they are likely to be staring at the same code base which has been a struggle for so long. If you were designing an ASIC, and the cut worked, you'd move onto the next big thing - often a very different thing. Not so true with software, the day after it 'ships' you're still working on the same old thing - especially in small companies where there are just a few horses to ride. The best thing we did with a major release was send everyone involved to the trade show for which it was targeted (SuperComm, this last June in Atlanta). It was a great team builder. You get to show your stuff off in front of the customers and competitors. Spend the evenings out with your team. Obviously expensive, so reserve it for major events. Engineers need to be sent to things like this when the time is right. They did the work, they should get some glory and fun from it. Often, a company will send the manager and a marketing guy, leaving the team at home to code. |
| Thu 17 Oct | TK | I agree with. Give a reward that actually seems like a reward to the folks who earned it. But in my case, the awards I appreciated most were those that I could enjoy with my family. Frankly, by the end of a project I'm pretty tired of the team. Indeed it's my 'home' team needs the re-building. Nat's other great point is that most software projects never seem end so you need to find a way to get folks off the treadmill from time to time. |
| Thu 17 Oct | anger within me | send their manager to Las Vega and dump more work to the dev team. That's what I would do. |
| Thu 17 Oct | Big B | How about giving the team a nice sum of money and a day to go out and buy something for the office... A corfortable couch, a floor lamp, decorative items, a fussball game, a 120Gb drive for the mp3 jukebox... |
| Thu 17 Oct | Patrik | Anger, >send their manager to Las Vega and dump more work to >the dev team. That's what I would do. Hahah... This pretty much happened to me, my then mgr. declined me a vaccation, and the following week he left to go to the US for a week. Great managers think alike eh? ;-) |
| Thu 17 Oct | d00d | I'd contract with a hooker with VD to pay him a complimentary house call... |
| Thu 17 Oct | Lauren B. | Fussball? That's so 90s. So dot-com. |
| Thu 17 Oct | Leonardo Herrera | 'That's so 90s. So dot-com. ' So true. Ah, the nostalgia. Some little bribes are needed. Things like the stuff found over ThinkGeek.com, nice lamps, bigger monitors, PDAs. I used to work for a dot com, and when we reached some deadline in advances (a couple of times) we used to do something different. Carting, paint ball, food, and stuff like that. |
| Thu 17 Oct | Ricardo Antunes da Costa | Well, I'm still waiting for the company's barbecue, that was supposed to celebrate a big sell, after months working hard to make it possible. It's been more than 6 months now... |
| Thu 17 Oct | anger within me | give them pink slips today and next day tell them you were just kidding. Not being laid off could be the most rewarding thing for them. Try that. Or as i said before, send their managers to las vegas and force them to work 12 hours a day and tell them they should be very grateful that they haven' t been laid off cause the project is finished. Be as nasty as you can. |
| Thu 17 Oct | Patrik | Anger, Try 18 while you are at it. Or 15 if you have a good day. Then sit and ponder why turnover is high. Quit wasting my time. |
| Thu 17 Oct | Sarain H. | Hey Patrik, Yeah that sucks. This is a really important issue -- employers showing respect and appreciation for employees. Developers will stick with it a long time with no appreciation but when the better offer comes in, good developers take off. Appreciating the employees is a cheap investment to reduce this from happening. A lot of these tech companies that have failed had good ideas but they did not treat the employees well and so the employees were glad to leave when a better opportunity came along and after a few rounds of that there was nobody left who even knew whene the source code was, much less what it was supposed to do. This would be followed by some brief thrashing about, desperately trying to hire people who could promise to finish the work, or even changing focus of the company to a new product, or trying to find a sucker to buy the company, not realizing the key developers had all left. Unless you are a big company, or a company with a very well established finely architected code base (which is never true for a product before its first saleable release), the loss of your key developers WILL mean the end of the company. Managers need to realize this. But instead of facing facts, we'll here more propaganda about how developers are prissy overpaid madonnas and we need to raise H1B levels because they can't hire anyone for $37,000/year who has the skills to take over a complex project in which all the developers have left. That's one of the secrets of the industry -- when you see those job listings with the page-long list of obscure knowledge and experience that is quite unlikely to find, you are looking at a list of technologies that were used in a mission critical project for which all the key developers have left after being tortuously abused. If you want to avoid living in hell for 6 months, avoid these companies like the plague. |
| Thu 17 Oct | Doug Withau | Do you have a Dave and Busters in the area (http://www.daveandbusters.com/). And do it on company time, not after hours. If you insist on going in the evening, give everone the next day off. |
| Thu 17 Oct | Must be a manager | Leonardo, things like bigger screens are stuff the company should be providing anyway. The idea that this is a reward is deceitful. Also, the idea of little toys as rewards used to be a standard thing among a certain type of manager - common in dot.com days - and represented an insulting view of the programmers. That is, the programmers are so dumb they'll be happy with a ticket to the movies ( $10.) Getting back to the topic, really productive management techniques I've found are have a cycle, even on a weekly basis. There are high pressure times, then easy times. It's nice. |
| Thu 17 Oct | Beka Pantone | Know your people (take cigarrete breaks with them and that kind of thing) and give them options. I knew two of my top engineers were very much into tennis, so with VERY careful planning on my side I sent them to Roland Garros. One of them almost cried when I told him where he was going. :) They still work with me and I wouldn't know what to do without them. |
| Thu 17 Oct | Sarain H. | manager, 'the idea of little toys as rewards ... represented an insulting view of the programmers. That is, the programmers are so dumb they'll be happy with a ticket to the movies' You are so right -- intelligent programmers would much rather have a poke in the eye vith a sharp stick. Not! I wouldn't mind tickets to the movies and two hours off in the afternoon to see a matinee. I guess that means I am just 'dumb' according to your theory of management. Or wait -- could it be that you are cleverly trying to use 'reverse psychology' to make the dummies think they don't really want movie tickets? 'Smart people don't want free movie tickets.' Yeah, that's the ticket. Wow! It's like a light's going off in my head now that I finally realize the truth of that! 'Getting back to the topic, really productive management techniques I've found are have a cycle' The cycle is so important, as is avoiding managers such as yourself who are on theirs. |
| Fri 18 Oct | vanguard | I'm surprised that nobody else seems to think like me. The only reward I want from work is money. Ice cream is stupid. I have too much work to do and I don't want to be bothered with it. Standing around with the people I work with for 15 or 30 minutes eating ice cream has never been a good reward for me. Tickets to the moveis don't do much for me either. You might as well give a $7 bonus. At least that way I can choose what I buy. However, you'll get exactly $7 of appreaciation from me. (not much) A better idea is to give real cash. How about $500 for a good release (gross it up, you pay the taxes). That will do something for me. Not a lot but at least it's something. Trinkets are for kids. Either hire children or give our real cash. |
| Fri 18 Oct | Alberto | The place I work at the moment is fantastic, basically I do whatever I want, I come to work when I want, I go home when I want, I work from home when I want, I wear what I want, I have food and drink in the fridge when I want it, we have beers on Friday (if I want), occassionaly our manager takes us out for a company financed restauraunt meal, usually on an impromptu basic, i.e no releases or milestones etc, lets just do it because we are adults and everybodies available and feels like it. My manager wears a suit, is smart, works 8am-6pm, cuts himself some slack sometimes (because he wants to). He organises meetings, checks progress, applies pressure when necassary, keeps in touch, talks to the business, sacks bad developers. Bottom line, we work hard, because we want to. We deliver. Of the 9 developers in my team, I have been there the shortest period of time (4 years). I even do some free lance stuff which, get this, if I'm not busy, I'm allowed to do on my companies time. |
| Fri 18 Oct | Alberto | ps. I am paid very well. $US72 p/hr, contract. |
| Fri 18 Oct | Robert Chevallier | Alberto, Does your company have an open position ? ;-) |
| Fri 18 Oct | programmer | Here's a great reward -- they get to keep their jobs. Why should people be given additional rewards for what they are already paid to do? It's not like they were working on the project as a favor to the company. |
| Fri 18 Oct | Tj | At my company, it's the polar opposite of Alberto's. The pay is good, but we have these sad celebrations of milestones like bowling, which is hard to enjoy because you know that going back to work nothing will change. Even in a down economy, people leave. Still, the thing to keep in mind is that after a release you want to relax and fix all those problems you had while you were engrossed. New things were developed that you didn't have time to try out, and there were problems you encountered that are worth thinking about. Maybe that proprietary IDE sucked and half the team wants to get good on emacs. Or people want Alberto to consult for a few hours so we can emulate his workplace. Maybe a few bucks for people to get something cool from Thinkgeek and a laid-back restaurant where people can say what they want from the company and how they want to work. You know in Japan drunk people can say anything they want... just pretend they're drunk. |
| Fri 18 Oct | Mr Jack | The really important thing is to avoid making the reward seem like the reason they worked. A pat on the back is good. An 'incentive' reward is bad. Personally I reckon you should arrange to take them all go-karting for an afternoon; a weekday afternoon. Or something like that. Something social, rewarding, relaxing and fun. My brother worked for a company that sent the whole team on a weeks overseas vacation when they finished the job. |
| Fri 18 Oct | mackinac | >>> Also, the idea of little toys as rewards used to be a standard thing among a certain type of manager - common in dot.com days - and represented an insulting view of the programmers. <<< I'll generally agree with this. It is not so much the little toys that are the insult. It's that I may have spent months or even a couple of years on a project where management didn't provide the kind of support that it is supposed to, then they try to make up for it with a couple of cheap trinkets. This kind of attitude shows up on 'Career' web pages where they'll tell you about their subsidized cafeteria or even gourmet chef on the staff, but they don't mention a thing about the work environment. |
| Fri 18 Oct | mackinac | The problem with any of these little rewards if finding something that everyone will like. At one place I worked one of the managers decided to give away tickets to baseball games. A few were purchased and given away by random drawing. The people who had no interest in baseball felt a bit slighted. Then they added concert tickets, which made things a bit better. After a while they gave it up. That's a problem with any freebie. If you provide free coffee, then you need to provide alternatives - good quality tea or soft drinks. Free beer on Fridays is only appreciated by beer drinkers. |
| Fri 18 Oct | Robert Blum | Can somebody please explain to me why you should /reward/ people for doing a job they are already paid to do? If you want to /celebrate/, that's fine. It's a different thing, though. Celebration encourages social interaction, rewards (usually) encourage competition. You pick and choose what you want for your team. |
| Fri 18 Oct | Bella | I say, get the team out for a social evening. This is a massive team builder, as people get comfortable and talk about things besides programming. This can take a few hours to happen, since its too easy to discuss work until people begin to interject non-work conversation..... Yes, I say plan something for after work, like dinner or drinks or bowling or whatever. Also, if at all possible, see if you can arange for an outing *on the company's time*, like leaving the office for the happy hour around 3pm. Of course, some people always use this as a chance to eat and run, and get home by 5pm. |
| Fri 18 Oct | Nat Ersoz | Being rewarded for a job well done? A couple of posters have noted that you're being paid, why should there be some reward above that? 1. Is a promotion not a reward? If you are promoted, either up a technical or managerial track for a job well done, is that not a reward? 2. Corporate profit sharing and/or stock option grants. Are those not rewards? Granted, initial option grants are part of a hiring negotiation package, but grants based on performance are in fact rewards. 3. Salary increases, bonuses - these are all rewards based on merit. The reason that rewards are often given to employees for good work is that they are a valued asset. The ability to keep them happy is a very useful tool. |
| Fri 18 Oct | Ed the Millwright | I was once on a team where the petty jealousies and backbiting were starting to affect productivity. This was noticed by management and vorious solutions were offered and debated, elaborate 'team-building' conferences and workshops were scheduled and then cancelled. The team was watching all this thrashing about disappointedly because everyone knew the politics had gotten out of control and people were getting ready to quit. I got together with another engineer who had had it too and we came up with a plan. I reserved a campsite at Cardiff State Beach and borrowed a 10-man tent. She went and bought lifesavers and bingo cards and came up with a set of party games. We invited the whole team to the beach camp on Saturday afternoon and out of 16, 12 came that weekend. Had fun trying to light a bunch of wet firewood -- one guy was able to display his boyscout prowess at doing so, played games, ate smores, told ghost stories, went swimming in the cold ocean and then for a long jog in the morning before heading home on Sunday at around 11. Completely turned the project around despite the fact that its inevitable demise was already common knowledge. Finished it ahead of schedule and under budget. management seemed pissed off about the whole thing. Got fired 3 weeks after that for among other things, going 'behind their backs' on the beach issue. Left smiling and had a better job the next week at a tidy increase in salary. |
| Fri 18 Oct | Alberto | Maybe you forgot to invite management? :-) |
| Fri 18 Oct | Must be a manager | Sarain, what I was getting at is that $10 for a movie ticket is nothing at all, and the people dishing out such 'rewards' would never accept such a trivial thing themselves. There used to be courses for HR managers on keeping programmers and other staff happy without spending much money. Any fool can give pay rises and trips and so on, but these courses taught HR managers how to do it without spending money. It's not an approach I ever used. |
| Fri 18 Oct | Sarain H. | manager, Ah OK I misunderstood you. You are coming from a situation where the only appreciation the workers get for their long hours is a movie ticket or some other such trinket. I'm with you there -- that sucks big time and the workers would not be fooled. I thought you were saying that workers that accept small gifts are stupid in general. Where I was coming from is a situation where one is competitively compensated and management happens to give out little tokens of appreciation on top of that, in which case it's the thought that counts and you know the thought is genuine because you are happy with your pay otherwise. Sorry for the misunderstanding. |
| Sat 19 Oct | meara | I have to side with the 'something cool for the office' folks. For example, a team of 10 finishes up a 6 month, $1 million project and gets a budget of $10K for an office improvement. This can be a plasma TV, a bunch of flat panel monitors, a ping-pong table, whatever -- but it has to have a tiny plaque honoring the project team (at least something like '2002 - Acme Financial Wizard'). Might also work to send everybody to an event and just put up pictures in a nice display. Think it sounds corny? Just imagine months later when you're stressed and wondering if your project will ever end. All you need to do is walk through the office to be reminded of past successes. |
| Sun 20 Oct | Bella | If you respect people's personal lives, they will work their ass off for you. |
| Joel & C++ | Mon 14 Oct | Just a Programmer |
| Although Joel writes intelligent articles, I am a little dubious about his programming, and in particular, his C++ skills. Something I noticed that really reaks of an inexperienced C++ programmer is found in Hard Assed Bug Fixing (http://www.joelonsoftware.com/articles/fog0000000014.html)
He gives the following example:
int foo( object& r )
{
r.Blah();
return 1;
}
Claiming that in user bug reports, the r reference is NULL. He says, thats completely impossible, theres no such thing as a NULL reference, C++ guarantees it. He continues on, blaming the bug on faulty hardware, or operating system software, or some other kind of aberrant glitch.
Blaming compilers, libraries, and hardware for problems is an immediate sign of an inexperience programmer. This is no exception. C++ does guarantee that there is no such thing as a NULL reference. C++ guarantees lots of things, its strange how all the nasty bugs I have had to deal with involve things that C++ guarantees can or cant happen.
As soon as the programmer does something which involves undefined behavior, however, all bets are off. C++ no longer makes any guarantees at all. Anything can happen. The program can fry your hard drive and send sexually explicit emails to your mother for all the C++ standard cares.
Of course, most implementations dont exhibit such interesting behavior: they do the most obvious thing. Simply, dereferencing a NULL pointer is undefined, and the most obvious thing to happen if you construct a reference by dereferencing a NULL pointer is to get a NULL reference.
If you call Joels function above, using the following code:
object* ptr = NULL;
foo(*ptr);
you can bet that on just about every C++ implementation there is, you will get a NULL reference. This is also perfectly standards-conforming. More simply, the complete program:
#include |
| Tue 15 Oct | Crimson | Well, I agree with his overall point which is unexpected hardware/software configurations of customer's computers can cause crashes. I mean, how many of us have installed programs that run perfectly fine *except* for when McAfee Virus Scan is activated? Sometimes the problem really is with the hardware/software configuration. I guess the specific example was slightly confusing for the reason you gave. Obviously if you don't initialize the object's state before dereferencing it, you're gonna get a fatal run-time exception. I'm assuming that in Joel's example the object *was* initialized (offscreen) and that the program ran perfectly fine on test machines. |
| Tue 15 Oct | Just a Programmer | No, he clearly said that you can't have a NULL reference. He (incorrectly) assumed that a NULL reference was impossible, because of the C++ language guarantees, and thus assumed that any occurence of one had to be a problem out of his control. If it had been a NULL pointer, he would have attempted to fix it. Problems like this, and indeed much weirder problems than this, can occur in C++. To prove that it's a problem with the underlying environment is difficult indeed - there are all sorts of subtle memory corruption bugs etc that can occur in C and C++. In this case however, it looks like it is a simple NULL pointer dereference that went unchecked... |
| Tue 15 Oct | Erik | I am not argueing you on the C++ stuff, but I am curious if you have a point besides showing Joel's ability, or lack thereof, as a C++ programmer. Does you intend to proceed to showing his other opinions are suspect based on this proof? Or that the discussions on this forum suffer because of it? I ask, because I don't think anyone here is interested in Joel's programming capabilities, unless they affect his articles. Most of the people who are interested in programming issues seem to be asking the general public of this forum, not Joel specifically. Maybe you are right about Joel's programming example(s), or maybe he chose them too carelessly. Did you ask him privately? Because you seem to make an assumption about his intentions that only he can substantiate. |
| Tue 15 Oct | tim | Any experienced C++ programmer worth his salt always checks for NULL pointers/referencing before trying to dereference the pointer/reference. From the looks of things, it seems that Joel does know C++ but has not been in the 'trenches' enough to encounter a lot of weird bugs that can crop up... |
| Tue 15 Oct | contractasaurus | int main() { char* ptr = 0; char& ref = *ptr; // BAD - SEGV now. std::cout << (int)&ref << std::endl; return 0; } Actually, you'll get a bad dereferenced pointer (SEGV signal on Posix), not a null reference. I've never encountered a null reference in C++. Forget the Joel good/bad thing. Not important. How about something else I had a discussion about yesterday... why prefer C++ exceptions over return values for errors? The only place I can find a use for C++ exceptions is when calling a constructor - because its the only way to find out if the constructor succeeded. All others should be return values with effective int of errno.h (Unix) or HRESULT (Win32) style success/error codes. What say thee? The only way to write code which gracefully handles errors, is to handle all errors... |
| Tue 15 Oct | Just a Programmer | Erik: Joel writes essays about programming. He indicates the primary languages he has experience with are C++ and Visual Basic. Even though his essays do not generally deal directly with technical issues, a lack of understanding of one of the two languages he claims to be experienced in is rather disconcerting. Yes I have sent him a private email regarding this, but he hasn't responded as of yet. He probably gets lots of emails, so this is understandable. Tim: Experienced C++ programmers don't necessarily check references for NULL before dereferencing, precisely for the reason Joel gives: there is no such thing as a NULL reference in C++. If you end up with such a thing, it means you failed to check for NULL before dereferencing a pointer. You only need to check pointers for NULL before dereferencing. However, it's clear that Joel didn't do that in the code he gives, since if he had, he wouldn't have ended up with a NULL reference. |
| Tue 15 Oct | Just a Programmer | contractasaurus: What compiler is this on? I have checked under both gcc and MSVC++6 and I get a NULL reference. But true, a compiler could give a seg fault instead, depending on how exactly it implements references (indeed a compiler can generate code that does whatever it wants since the behavior is undefined). |
| Tue 15 Oct | itstilldoesntmatter | The only place I can find a use for C++ exceptions is when calling a constructor - because its the only way to find out if the constructor succeeded. All others should be return values with effective int of errno.h (Unix) or HRESULT (Win32) style success/error codes. What say thee? The only way to write code which gracefully handles errors, is to handle all errors... contractasaurus |
| Tue 15 Oct | itdoesntmatter | Oooops, sorry, was a bit fast on |
| Tue 15 Oct | Ged Byrne | -------------------------------------------------------------------- What say thee? The only way to write code which gracefully handles errors, is to handle all errors... ----------------------------------------------- contractasaurus The benefit of exceptions is that you can handle all the errors in a different place to where you get on with the real work. This makes the code cleaner. The other thing is that if you do exceptions right, you get a contract. If a raise an exception, then it won't go away until it is handled. Main calls function a. Function a raises exception. If Main doesn't handle the exception, the default handler will so you have to fix it. There's no missing that error. Return values have no such contract. Main calls function a. Funtion a returns a value that indicates an error. Main fails to check for the value, but the system continues to work apparantly unharmed. The error is missed and you're going to have trouble finding it next year. Of course I'm new to C++. I learnt exceptions in Java and wouldn't be without them. Does something about their implementation in C++ make them less effective? |
| Tue 15 Oct | Ged Byrne | ------------------------------------------------------------------------- class object { public: void blah() { std::cout << 'I'm good.' << std::endl; } }; int foo( object& r ) { r.blah(); return 1; }; object x; int main() { std::cout << foo(x) << std::endl; char* ptr = 0; char& ref = *ptr; std::cout << (int)&ref << std::endl; std::cout << foo(ref); } --------------------------------------------------------------------- Crimson, I'm trying your code. This is as far as I get, but when I try to compile Bloodshed Dev++ (based on gcc) is giving the following error at compile time: ----------------------------------------------------------------------- In function `int main()': conversion from `char' to non-scalar type `object' requested in passing argument 1 of `foo(object &)' ----------------------------------------------------------------------- Sorry, as I say I'm new to C++. What do I need to do to get foo to except my null reference? |
| Tue 15 Oct | Just a Programmer | I don't advise trying to get the NULL reference working with the foo example Joel gives because 'object' isn't even a builtin type in C++ and so forth. Use the second example I gave. As for error handling, exception handling has huge advantages. Having to check every pointer returned from a memory allocation routine for nullity is damn annoying. It makes your code huge. Exceptions are the only real way to handle things like this. If it wasn't for exceptions, imagine how we'd have to access containers in C++. You'd have to go: bool result = myvector.push_back(5); if(result == false) { //handle vector failling to allocate } this is horrible. With exceptions you can handle it in far fewer places. Of course, the big problem in C++ is that static exception specification checking is not supported, and so programmers will typically fail to be rigorous about exceptions. Strangely, C# has the same problem. I think this alone makes C# an inferior option to Java. Statis exception specification checking is a *big* deal. There is, however, a C++ solution: PC-Lint (see www.gimpel.com) will perform static exception specification checking for you. If you use it on a project from the start, you will be almost guaranteed to have far less problems. For that matter, PC-Lint also does many other cool checks, like for possible NULL pointer dereferences. (full disclosure: other than being employed by a company that has purchased their software, I have no affiliation with Gimpel). |
| Tue 15 Oct | Erik | Just a Programmer, Most of the topics Joel writes on, are about issues that are unrelated to the act programming. In fact, his essays apply equally to any project that finds itself in the same context as he gives, whether the code is programmed in C, C++, Java, or anything else. Any of his essays that are specifically about how to do things in C++ are valid subjects for your scrutiny. If there are any, I am neither aware of them nor interested. Remember, preparing, or controlling, or monitoring a project does not require detailed understanding of language specifics. Designing a product does, to the extent that there is no point in designing something that can't be built. |
| Tue 15 Oct | Just a Programmer | Erik, Although many of the topics Joel writes about are abstracted to the degree you claim, his writing often still involves technical details. He makes various very absolute claims, for instance that having automatic memory management is the only feature a language can offer that will significantly improve programmer productivity. I would suggest that if one makes claims like that, one must be a good programmer to have the experience to back it up. If one is not a good programmer, even in a language he or she has nominated as a language which they have expertise in, then I must admit to being rather dubious about many of the claims they make that involve the details of programming. Programming skill is relevant to many of the topics Joel writes about. It is also not relevant, or at least not very relevant to many other topics he writes about. Thus far however, I have not made any implications other than that he does not appear to be a particularly experienced programmer. The rest is left to reader deduction. |
| Tue 15 Oct | Ged Byrne | Just a programmer, Thanks for the info. I didn't realise that the exceptions weren't statically tested. PCLint looks like it will solve that one for me. I'd still like to know how the foo function could be called with a null reference. I know I don't want it to happen, but I want to understand how it could happen so that I can be on guard. |
| Tue 15 Oct | Just a Programmer | Ged: the following code is a complete program which will give you a NULL reference in a function, using most compilers:
#include |
| Tue 15 Oct | Ged Byrne | Thanks, I'm beginning to understand. However, as far as I can tell Joel is still right. In the example he gives it's still impossible (at least on my machine with my compiler) to get a null into the function he gives. I modified you code so that it takes an object, and it is failing at compile time with this error: ---------------------------------------------------------------------- 15 d:\gedbs\cpp\my_src\foobar\justa.cpp no match for `_IO_ostream_withassign & << void' ---------------------------------------------------------------------- Sure, if I just send ref out to std output It shows its a null pointer, but as soon as I try to use ref as a reference the compiler complains. This reassures me. Am I missing anything? -------------------------------------------------------------------------- class object { public: void blah() { std::cout << 'I'm good.' << std::endl; } }; void function(object& ref) { std::cout << ref.blah() << std::endl; } int main() { object* p = 0; function(*p); return 0; } ------------------------------------------------------------------------- |
| Tue 15 Oct | Ged Byrne | The Herb Strutter article is very good. Thanks for that. |
| Tue 15 Oct | Just a Programmer | Ged: The reason your code isn't working is because you're trying to output the result of blah() when blah() returns void. You just want to call blah(), since it itself outputs, but doesn't return anything. This code will then compile, and on most compilers will just output 'I'm good'. This is because usually, calling a member function through a null pointer is ok, so long as you don't directly or indirectly access any member variables or virtual functions inside the function. (not that you should ever do this). e.g.
#include |
| Tue 15 Oct | Ged Byrne | Of course. Stupid me.
Now I have code that works (or rather, doesn't - Application Error). Nasy null Reference. Not so assured.
However, I understand what's going on, and the exersize has taught me a fair bit about pointers and references. I won't go running scared back to Java just yet.
It surprises me that this type of behaviour is allowed by C++. Is it because of maintaining C compatability?
---------------------------------------------------------------------
#include |
| Tue 15 Oct | Just a Programmer | Ged: This sort of thing is allowed in C++ largely because C++ has this concept of 'undefined behavior'. That is, once the programmer does something not allowed, the language will no longer make any guarantees at all. This is in the interests of speed, but can be very frustrating and make debugging difficult. It is probably the biggest single factor in making C++ more difficult than Java. (But I still prefer C++ as a language; I think it has enough advantages to compensate). |
| Tue 15 Oct | Leonardo Herrera | Hm. I believe what Joel tried to say was among the lines of 'See, you have this condition covered somewhere else, and there is no way this is gonna fault. Yet, it does, and it will.' Morale of the story: cover your ass, use a bug database, and test, test, test. I still can't see the value of this C++/Joel can('t) program thread (besides some interesting quirks about C++.) Regards, |
| Tue 15 Oct | Nat Ersoz | Just a Programmer, Well, that was an interesting conversation in a place which has seemed to have lost much of its interest in recent weeks. Nat (fromerly contractasarous, and other split personalities...) |
| Tue 15 Oct | Nat Ersoz | Oh, I meant to say also: Agreed that what make Java exceptions so much more powerful is that they are part of the class definition, and statically bound. |
| Tue 15 Oct | William C | >>>>>>>>>> The only place I can find a use for C++ exceptions is when calling a constructor - because its the only way to find out if the constructor succeeded. All others should be return values with effective int of errno.h (Unix) or HRESULT (Win32) style success/error codes. >>>>>>>>>> I'm not a C++ expert by any means. But, I did learn this from a C++ expert and i'll pass it along (maybe he was wrong): You should never call any functions in a constructor (or was it any functions that could fail/return an error code). I limit the constructor to initializing variables and that's it. That way, I never *have* to check for an error code in the constructor. If you need to call functions that return an error code, create an Init function for that class. |
| Tue 15 Oct | Zwarm Monkey | Calling functions within your constructor is OK. If there is an error, you can use exceptions to throw the error out. However, you should never throw any exceptions from your destructor. |
| Tue 15 Oct | Nat Ersoz | The problem is calling _virtual_ functions within a constructor. That is probably something you want to avoid. What you will get is a call to your class's function, not a call to what you probably want, which is the call to the inherited virtual function. |
| Tue 15 Oct | Chris Tavares | Re: 'Never call functions in a constructor' That used to be the rule. And it opened up a huge set of potential bugs: 1) Forgetting to call the Init function 2) Calling the Init function twice 3) Knowing when you have to Init and when you don't. Also, it makes it much harder to use 'Resource Acquisition is Initialization', the C++ idiom that prevents resource leaks. Exceptions were added precisely to get around these problems. Now that exceptions are in the language, you should throw them, and do your init work in the constructor where it should have been in the first place. Calling VIRTUAL functions from a constructor is still a bad idea, but that's a whole different issue. |
| Tue 15 Oct | Bill Carlson | I usually won't check for NULL function arguments in my C++ code, for a few reasons: - NULL is easy to test for, but someone could pass in a pointer/reference to any random non-zero memory address just as easily. This is common with thrashed memory. Can't really catch this easily in C++ (without an ImOK() member function). - It's difficult to recover from. Someone passed me a NULL. What do I do? Throw an exception? Maybe. If I'm getting a NULL and the caller isn't an idiot, then there's possible thrashed memory and the exception may not propogate anyhow. There's potential for errors in error handling code that 'percolates up' a chain of return values. - Dereferencing a NULL pointer is an automatic GP fault. This makes it one of the kinder C++ errors. You're never sick without knowing you're sick. Bottom line: If I'm writing void LaunchTheMissiles(target *t), I'll check t for NULL, otherwise, generally, I'll assume that this fatal error is in fact - fatal. |
| Tue 15 Oct | pb | Geez, programmers are lame. |
| Tue 15 Oct | Just a Programmer | Leonardo: I'm sorry, no, Joel was claiming that a 'NULL reference' can *never* happen, and if it does it can't possibly be the programmer's fault, and must be a problem with the hardware the program is running on. He was saying that if you run into a situation where you have a NULL reference, then don't bother trying to fix it, because it's not a bug in your code and it's not worth the time or effort to do it. He even (half-jokingly) mentioned a hardware vendor accused of causing this behavior. Bill: Yeah, usually if you get a bad or NULL pointer when you're not expecting it, your program is in big trouble anyway. The function silently returning (which is what most people do in this kind of situation) is not a good idea, as it hides the problem and could result in incorrect data, which is generally worse than no data (i.e. the program crashing). However, it really does depend on the situation. I will generally check for NULL or bad pointers (using IsBadReadPtr, and IsBadWritePtr on win32 - in fact I have the whole thing wrapped using a function template I wrote called IsBad which will automagically work out if the pointer is a pointer-to-const and if it's a smart pointer and so forth and do appropriate checking). Also, where I use pointers, NULL is usually a valid value - indicating non-existence of the object. If NULL is not a valid value, then I will use a reference where possible. Classes should never have a non-private init() function. This is plain evil. Throwing something from the constructor is *the* way to report an error. Anything else is evil. Further, I would suggest that in many or even most instances, using exception handling is a more convenient way to handle errors than using error codes. Programming with exceptions does require a disciplined programming style, but it's a programming discipline that's good anyway, even if you don't use exceptions. Writing a robust application - one that will elegantly handle, or even attempt to recover from situations like memory exhaustion - with error codes alone is tedious and difficult. Using exceptions, it's much easier. |
| Tue 15 Oct | Alberto | Has anybody ever heard of ' a storm in a teacup'? |
| Tue 15 Oct | --delphi for life!!! | all you C++ programmers need to wake up and realize DELPHI is superior, and your C++ arguement is pointless. No one would ever have these problems if everyone used delphi! |
| Tue 15 Oct | Just a Programmer | delphi for life: In my experience, one of the most useful and important features of a language is the support of typesafe generic programming. I'm afraid that Delphi doesn't support this... |
| Wed 16 Oct | Simon P. Lucy | Exceptions are fine when you have a single language runtime and a single platform. If you have mixed development and/or multiple platforms then exceptions become impossible. Which is why .NET scores in this regard, but then of course its really a single language runtime and currently a single platform. |
| Wed 16 Oct | Erik | I am sure most of the conversation has been fruitful for many, and I think many don't even recall why this thread was started in the first place. Just a Programmer, you started this by questioning someones programming ability based on an article he wrote. I am no C++ plus expert and believe whatever you say about the example Joel gave. But, I think Alberto was right when he mentioned the storm. Joel's article was not about his programming abilities, nor about the specific construct he used to make his point. And his point was, don't always fix every bug you find, but make sure it is economically sound to fix the bug. And that is always sound advise. And not so because Joel said it, but because many have already found and said it to be true in many other professions. And from the programming example Joel gave and the arguments in each of your replies, I tend to think it is not such a bad example after all. Not because it could never happen, because some of you have argued convincingly that it can. But precisely because of what some of you argued, it can only happen under very peculiar circumstances, and there is no clear path to correcting the situation. In other words, even if it goes wrong, and you can detect it, what can you do to fix it. Before this thread takes of again explaining the countless steps you can take to fix it, and that I am not aware of, not being a programmer, ask yourself this. How probable is it that you attract this disease, and how expensive is the cure? Now ask yourself that every time you run into a bug, and you will have taken Joel's advise after all. Because in the real world (the world in which your code is being used), there is a clear difference between probability and possibility. |
| Wed 16 Oct | Max Hadley | What an interesting thread! First off, my (limited) experience of C++ is limited to modifying & maintaining somebody else's code. I dislike C++ for a variety of reasons, most of which boil down to 'it's too complicated'. I came from a C background, but despite this I much prefer Delphi's Object Pascal language - I make far fewer mistakes. In OP, all objects are references: in C++, I'm always using . instead of -> or vice-versa. C++ seems to have all these strange rules - about what you can and can't do in a constructor, for instance - that I can see no rationale for and have difficulty remembering. So I always end up sticking to a very limited subset that I (think) I know works, missing much of the power of the language. Now what does that remind me of? Ah yes, a badly-designed user interface! If we look at a programming language/environment as a user interface (for programmers) to the underlying machine and OS/libraries, many of the techniques and rules learned in that field can be carried over to language design and use. Discuss! BTW, I agree that one of Delphi OP's more significant failings is the lack of a type-safe pattern/template/generic system. But C++ templates!! Look at ADA95 generics for how it should be done. |
| Wed 16 Oct | Just a Programmer | Erik: I am sorry, but Joel's example had no validity at all. It was a typical C++ crash caused by the program itself. I don't think *anyone* debates whether or not a bug like this should be fixed. Of course it should. If it was a weird crash, caused not by the program, but by dodgy hardware, like Joel suggested, then absolutely, it shouldn't be fixed. If he had showed that it was caused by hardware, I would have agreed with him wholeheartedly. Although the principal of Joel's article was still correct, he miscommunicates some important things. He makes it seem like it's easy to blame a software problem on the hardware, environment, or compiler. This is not so: it is very difficult to determine that a crash of a program is due to a bad environment; one needs a far more rigorous test then what he has given. Further, it does call Joel's credibility as a software engineer into question a little: He has admitted that he worked on a project that received reports of crashes while the product was in beta testing, misdiagnosed the cause of those crashes to be 'bad hardware' when in fact it was just sloppy programming, ending in the bugs never being fixed. And now, years later, he is writing essays on how he was right not to fix the bugs. Don't you think that calls his credibility into question just a little bit? Max: C++ isn't my 'dream language'. It has many problems, not the least of which is the fragmentation and variance of implementations. However, I do understand it, and so it is productive for me. There are nicer languages, but they are simply not used. My personal favorite is Haskell. Delphi may be simpler than C++, however its simplicity is of little advantage to me when I already know C++, and am familiar with its idioms, and can now take advantage of generic type-safe programming, which Delphi does not support. |
| Wed 16 Oct | Erik | 'He makes it seem like it's easy to blame a software problem on the hardware, environment, or compiler.' I am sure that was not his intention. And it does not bother me as much as you apparently. His main point though, as you agree, remains valid. '... misdiagnosed the cause of those crashes to be 'bad hardware' when in fact it was just sloppy programming, ending in the bugs never being fixed. And now, years later, he is writing essays on how he was right not to fix the bugs. Don't you think that calls his credibility into question just a little bit?' Misdiagnosing in itself is not that bad, it happens to the best of us. However, not learning is worse. I am just not that convinced by this very simple example in an article about something else, that he is defending he was right not to fix this particular bug. Besides, do you think people would believe anything Joel says without at least some thought? I read his articles with interest and in the context of my experience, and I am sure others do. Most of what he says is interesting and entertaining. He never not automatically right, but he usually gives good arguments to support his opinions. Still everyone is free to disagree, and I am sure he is wrong often enough to be human. I expect he will be the first to admit when he's wrong and change his ways accordingly. I am also sure you are intelligent enough to spot the inaccuracies of Joel's arguments and only take what you need. You are free to point out any suspect information, as you did, but like Joel you might misinterpreted on occasion too, and if you think you haven't on this occasion, I am sure you have though about it long enough to satisfy your own sense of justice. For me, even when you are right about this, I have no reason to become more suspicous of his musings than I am by nature, unless the topic is C++. But I would not be very interested in the topic in the first place :-) |
| Wed 16 Oct | David Clayworth | 'Exceptions are fine when you have a single language runtime and a single platform. If you have mixed development and/or multiple platforms then exceptions become impossible.' Beg to disagree, but I'm currently working on a project which is mixed C++/Perl and multiple platform (Win,Linux,various Unix). Apart from having to ensure that we don't propagate exceptions into the Perl parts (there are few enough of them that this is not a problem) exceptions are working well for us. |
| Wed 16 Oct | Just a Programmer | Erik: Misdiagnosing a bug happens to the best of us. Usually these misdiagnoses consist of us thinking it is in one segment of code, when it is in another. We stick to it, and eventually find and correct the bug. In this case however, a team Joel was working on failed to fix the bug at all, leaving it in the release version of the program. This was due largely to a huge misdiagnosis of the problem. I don't know about you, but it makes me a little dubious about his abilities when one can deduce that he worked as an engineer on projects where he, and the entire team, flat-out missed the problems completely. As I said earlier, being quick to blame problems on the tools used is generally a sign of a novice. It is disturbing to hear it from one who is so experienced. |
| Wed 16 Oct | Ed the Millwright | 'In this case however, a team Joel was working on failed to fix the bug at all, leaving it in the release version of the program.' If you read the article carefully, you will note that Joel says that in the end he went ahead fixed all the known bugs anyway. Seriously, although I happen to know this wee bit of trivia about how to create a NULL reference because I find obscure things interesting, it is really uncommon knowledge about C++ and many experts do not know about it. I seem to recall that a couple months ago when Katie (was it she?) first brought up this bit of trivia, a lot of people were really surprised to hear about it. And now here you Big Men on Campus are all swaying back and forth and waving your jawbones and grunting and declaring what marvelous programmers you are and how ignorant Joel is that he does not have the Supreme Knowlege of C++ Trivia that you all do. Feh I say! Show us *your* successful software companies selling usable reliable software! Show it to us that we may see what Heartbreaking Works of Staggering Genius thou hast created so that we may bow down and worship it! |
| Wed 16 Oct | Just a Programmer | Ed: At the end of the article, Joel says they fixed 'every known' bug in FogBugz, the software his company currently produces. Firstly, he didn't consider the earlier crash a bug. He attributed it to 'cosmic rays' (his words). Secondly, that was referring to a product he had worked on at an earlier company: Juno. I am fairly new here, and if this issue has been brought up before, I am sorry for the redundancy; I wasn't aware of it. Indeed, if it has been brought up before, one would think that Joel would at least publish an addendum to his essay acknowledging the error. |
| Wed 16 Oct | Tj | I think one can be of two minds here. On one hand, C++ is known as an inelegant monster of a language where bad trivia abounds. And Joel's articles are about software management. Presumably this is a bug that should not arise given reasonable coding? OTOH, if there's an error it should be mentioned. C++'s complexity has to be understood if you're going to program for years on it. I do notice though that in business there's a balance between being technically proficient and other things. Otherwise we'd be on really incredible machines by now. |
| Thu 17 Oct | Simon Lucy | David Clayworth: If you can't propagate the exceptions into Perl, for very good reasons, then surely my point that exceptions are impossible in multiple language runtimes is valid? The number of exceptions that happen isn't actually relevant :-) I suppose you're using the same C++ compiler and libraries across all the platforms, that enables exception handling for that runtime. Notice I'm not getting into the religious war of whether exceptions are a Good or Bad thing. |
| Thu 17 Oct | Ged Byrne | Ed, The internet, as a medium, requires people to question what they read, and let others know of those questions. Joel speaks out on a number of subjects with great authority, and it is very easy to take it all as gospel truth because of the way it's presented. JustA is doing an important service by scrutinising what Joel has said, and bringing up points he thinks are relevant. Personally, I'm grateful. I've learnt a lot. I think theres a big difference between JustA's well supported criticism and the usual 'Joel smells' type of trolling. |
| Thu 17 Oct | qwik | Ed, the issue Just brings up is not some sort of trivia only a handful of c++ trivia hounds know about. This is pointer basics. If somebody doesn't understand how these things work, they're probably getting into trouble in places they don't even realize. |
| Thu 17 Oct | Mark Hoffman | I won't weigh in on the C++ issue because while I'm comfortable with C++, I am no expert in it.
JustAProgrammer, I've read your posts but I still don't see that your point is much bigger than 'Look at me. I'm a better C++ programmer than Joel because I know |
| Thu 17 Oct | qwik | WTF? God forbid you should point out an error in one of Joel's articles - be prepared to suffer the wrath of the Joel apologists! |
| Thu 17 Oct | Robin Debreuil | Why is it that one takes sample code that includes C++ null pointer as the word of God, and then completly ignores statements like on the FogCreek home page link: 'Tips, opinions, and highly questionable rants on the software development process from Joel on Software.' And before I get accused too, I'd like to apologise for Joel -- and myself while I'm at it, for thinking I could actually get something out of reading articles on software design by a person who write's sample code that technically could be construed to be a bad example by those with high blood pressure. I must have slipped into a coma, sorry. |
| Thu 17 Oct | qwik | Robin, I don't even understand what you are trying to say, but you're excused anyway. |
| Thu 17 Oct | Ed the Millwright | There's two issues here: 1. Joel is absolutely correct when he says that there is no such thing as a NULL reference. He is right. That's one of the great things about references -- you can use it without testing for NULL, rest assured it will not be. One of the criteria for using references insead of pointers is that the value you are using can not possible be NULL -- doesn't use NULL as a 'special' value meaning 'memory not allocated' or such. * 2. You guys that think you are hot shots are not all that. You would make poor employees. But you can improve. Why do I say this? Because you have poor social skills. This is what you do: 'Joel says NULL references are impossible but I have code that makes NULl references so Joel is wrong therefore he does not know how to program because he is wrong and this is a simple basic issue of pointers that every C++ programmer learns on the first day of school. I hardly think he is qualified to be writing articles on software development with such a poor level of skills because he is wrong. Hire me instead of Joel, I am *that* good because I am not wrong like Joel because I found one thing that he is wrong at.' And you know what, it's lame. It's a dead giveaway that you are a poor developer. You might have the ARM memorized (and you don't or you wouldn't be making these claims about NULL references) but if you bring this attitude that you are better than everybody into a team, that team will never jell. Good thing you are using anonymous aliases, so there is still a chance for a recovery. Let me teach you a better way. Why not try this approach instead: 'I noticed that Joel says NULL references are impossible. That's a very common perception and I am not surprised he was bitten by this since there are several well-regarded C++ books that state that NULL references are impossible. In fact, NULL references are indeed possible and here is some example code that shows how it is done. Remember to always check your refrences if they are null before dereferencing them with a dot - Mature Programmer' And then Mature Programmer will find himself further educated by one who knows more than he does, 'Dear Mature, Thanks for the informative post bringing up this interesting issue. Many programmers wonder about when to use references as opposed to pointers. One useful criteria is when the value can not possibly be NULL. In point of fact, there is no such thing as a NULL reference in C++. Dereferencing a NULL pointer to create a reference is not permitted in C++ and once that happens the behavior of C++ becomes undefined, that is to say outside the standard. This is not desireable. It is true that most compilers now do not check for this and will happily create a 'NULL reference' for you, but that behavior is not defined under the C++ standard. The pattern to use here is that anytime there is the possibilitya pointer could be NULL you should not make a reference from it -- thus check the pointer for NULLity before creating that reference and if it is NULL, don't make the reference, whcih would then bring you into the realm of undefined behavior.' -- I have had this NULL reference debate with lots of competant C++ programmers. I never call insult their abilities if they don't know that NULL references are possible. Instead I use it as an opportunity to have a nice talk about C++ design methods -- such as criteria for using references instead of pointers, wihch is a very interesting subject. At the end of the day, they respect me even more and we both know more than we did before. If someone barges into my office or starts yammering at a meeting with a bunch of nonsense about how I am an incompetant developer because I don't check for NULL references or any other bit of trivia, I wait for the tirade to end, find out what their real issues are and address them if valid or explain to them their own error if invalid. If I like them, I might talk to them as I am to you now about being professional. If I don't like them, I just regard them as unprofessional twits and let them dig holes for themselves without interference from me. |
| Thu 17 Oct | qwik | Ed, if your people don't understand how pointers work, then you should work on your hiring skills. This is basic stuff - DON'T dereference an invalid pointer. Also, here's another bit of 'trivia' for you: DON'T divide by 0! As for social skills, you really did provide a good example by your first post. Quite professional indeed. Lastly, the issue isn't about whether or not the C++ standard allows for NULL pointers. No one claimed that it does. The OP said quite clearly that once the invalid pointer was dereferenced that the program's behavior from that point on is undefined. You need to brush up on your reading skills too. |
| Thu 17 Oct | Robin Debreuil | Hey quick, Maybe I missed the point too... What I'm hearing is 'Joel's articles are full of crap, and here's proof'. And then the proof is a debateable snippet of code (irrelevant to the point of the article anyway), from a year and a half ago. Then we can work backwards - so he isn't a good programmer - so he's a liar about his abilities - so he isn't qualified to write about software - so his articles are full of crap. Hmmm. If that is the ultimate point, why not just say that? Or challenge the actual premise of the article? Or other ones? But with logic like that, who needs null references for bugs anyway. I suspect though, that the real motivation is ego - the implication that 'knowing' this means greater skill, which leads to better opinions, which even implies that the said person could write better if they cared to. Well bravo. My applause would be loudest if I felt like clapping. If someone wants to disagree with an article certainly its all open to debate, that is why there is a forum. Or talk about null refs, sure, it is interesting. Talking about how Joel 'really reaks of an inexperienced C++ programmer', my spelling, or 'gif' vs 'jif' doesn't really lead anywhere useful though does it? It right up there with name calling. |
| Thu 17 Oct | Ed | qwik, Pointers and references are not the same thing. |
| Thu 17 Oct | qwik | Thanks for pointing that out Ed. So much clearer now. |
| Thu 17 Oct | qwik | Let me brush up my writing skills: 'Lastly, the issue isn't about whether or not the C++ standard allows for NULL _references_. ' ;) |
| Thu 17 Oct | qwik | Robin, you may be right. I didn't take the post that way though. |
| Thu 17 Oct | Just a Programmer | Robin: I'm sorry, I never said 'Joel's articles are full of crap and here's proof'. I simply pointed out that something in one of Joel's articles was clearly and unambiguously incorrect. I then left conclusions thereafter to be largely left to the reader. |
| Thu 17 Oct | Ed | Hm, no one has picked up on my comment about 'testing for a NULL reference'. So I'll just sit here and talk to myself. All you genius programmers that are better than Joel know this stuff already so you can just skip this post. The code joel gave: int foo( object& r ) { r.Blah(); return 1; } is perfectly fine. There is NOTHING in it to be fixed. And yet there was the crash... and the comment about how the bug reporting mechanism showed this failing on two or more Packard Bell computers in 'low-memory situations' (he implies this is what is going on in this particular case.) So what we see when we look back in time to Joel's monitor when he was working for Juno parsing these bug reports from the field. We see him opening his edinor to the line number and file name of the line r.Blah() where the bug report says that an address error occurred. We see him looking in puzzlement through this code that maybe he himself wrote or maybe it was someone else who designed and wrote it. We see him noting that there are two bug reports on which this line is implicated and that they both happened on a Packard Bell computer that had pretty very little memory left -- the stack and the heap pointers were about to collide, so says the comprehensive bug report. Joel's been a C++ programmer for years. He's read all the books. He can't see how this could be -- there is no such thing as NULL references in C++ -- that's one of the things that's cool about references as opposed to pointers -- you don't have to check them. In summary, the following is something you should never see in anyone's code: int foo( object& r ) { if (NULL != &r) r.Blah(); return 1; } So how did it happen anyway and what is the solution? Well, somewhere there is code that looks like this: Gizmo myGizmo = new Gizmo(a,b,c); ... foo(*myGizmo); Gizmo's constructor doesn't throw an exception if allocation failed and the code ... does not check if myGizmo is a NULL pointer after the constructor is called. None of this is the fault of function foo. And the compiler technically IS broken since it should not allow NULL references to be created by dereferencing a NULL pointer. But regardless of all this, one should deal with memory allocation failure in some way. Who knows though, Gizmo is probably a function in a $400 grid library they got off the internet and fails to throw an exception when allocation fails, choosing to return silently instead. |
| Thu 17 Oct | d00d | 60 replies on this topic. Someone is hyperventilating. |
| Thu 17 Oct | qwik | Ed, you should read that link way up there that Just already posted. Herb Sutter writes way better than you (no offense, he writes better than most of us). Here it is again in case you're lazy: http://www.gotw.ca/conv/002.htm (Note that you didn't add anything to this discussion that we haven't gone over) |
| Thu 17 Oct | William C | Hello again. >>>>>>>>>> Exceptions were added precisely to get around these problems. Now that exceptions are in the language, you should throw them, and do your init work in the constructor where it should have been in the first place. >>>>>>>>>> Hmm. Couple of problems. Or maybe not. I've been programming C++ (since graduating) for about 2 years...so, I'm still 'new'....so I definitely could be wrong. Everybody treats Exceptions like they come for free. And what I mean is, they don't think about the fact that too many exceptions might slow down the code (yes/no? am I wrong here? -- I'm thinking all the exceptions that you must catch is part of the reason that Java can be slow). Also, I develop for PDA's. Now, if you have ever developed for the Palm (pre-OS5) with C++...I think a lot is done just in C but we used C++...you would realize that there isn't a whole bunch of stack space available. Right? Isn't catching exceptions applying that much more 'pressure' to your stacks? (I really need to sit down and read the Arm (annotated ref. manual) -- I've been trying to get around to doing it). |
| Thu 17 Oct | William C | Oh. One other thing. >>>>>>>>>> Also, it makes it much harder to use 'Resource Acquisition is Initialization', the C++ idiom that prevents resource leaks. >>>>>>>>>> Can you get in depth on this? Because I don't understand how having an Init function takes away from preventing resource leaks. In other words, I still use the destructor. And in my constructor, I'm saying that I don't even 'new' anything. I just initialize variables (like ints, etc. -- primitave data types). So, I will new a variable in the 'Init' and if it failed, then I will call delte on the object that I instantiated. So, the destructor will then take care of things. Also, I'm in Palm/Win32/PocketPC land. So, these are GUI type apps. (Dialog apps, Doc/Veiw, etc). Maybe the fact that I'm stuck in the MFC layer of things....I don't see the need for using exceptions as opposed to another kind of C++ development? I dunno. I'm babbling...but interested in advice! :) |
| Thu 17 Oct | William C | Let me be more clear on one thing I said here: >>>>>>>>>> So, I will new a variable in the 'Init' and if it failed, then I will call delte on the object that I instantiated >>>>>>>>>> I don't call delte on the instantiated object inside the Init function! :) That would be when Init returns with an error. I'd delte the object then (after checking the return code from Init). |
| Thu 17 Oct | Just a Programmer | Ed: You are mostly right, except the compiler is *not* technically broken. If a programmer dereferences a NULL pointer, that is undefined behavior. 'undefined' means precisely that. The compiler may do what it damn well wants the moment you dereference a NULL pointer, including create a 'NULL reference'. And yes, Herb Sutter can articulate all this far better than most of us :) William: If you have some code that does use exceptions extensively, and it is running too slowly for your purposes, start worrying about it at that point. radix omnia malorum prematurae optimisatia est. |
| Fri 18 Oct | Jack lives over there -> | Esto es alguna mierda loca! |
| Fri 18 Oct | Danil | Gizmo myGizmo = new Gizmo(a,b,c); ... foo(*myGizmo); Should be: Gizmo myGizmo = new(nothrow) Gizmo(a,b,c); ... foo(*myGizmo); If we are trying to demonstrate undefined behavior in a conforming implementation. Also, it's worth mentioning that checking for a null reference is a rather hopeless enterprise - not only because you can't get a null reference, but also because if you have a null reference, there are no guarantees that the test will work. Example [warning - uncompiled code ahead]: int * p = 0 ; int & r = *p ; // Undefined behavior if ( 0 == &r ) { cout << 'true' ; } else { cout << 'false' ; } What does this fragment do - well, if you are lucky, it will output true. If you are unlucky, it will output true only when you are looking at it. A conforming implementation might also output 'false'. Or it could launch NetHack - why not? When true == false, recovery is impossible anyway. |
| Fri 18 Oct | William C | >>>>>>>>>> William: If you have some code that does use exceptions extensively, and it is running too slowly for your purposes, start worrying about it at that point >>>>>>>>>> Well, of course. I'm not so 'new' that I don't understand that! Obviously, I gave just one example of a drawback of using exceptions (actually two -- if you include my 'stack' spiel). By me giving one example, it was supposed to 'springboard' discussion about exceptions. Shooting down my one thought as unimportant and skipping the other thought (stack)...I don't think I or anyone reading gained anything! :) There's probably some drawbacks I'm not aware of...and when you discuss using exceptions...I think you have to discuss the drawbacks. No? Also, I brought up the point of the environment you are working in. Like, developing for PDA's. Start using a bunch of exceptions during embedded development and tell me that it is a good idea (and I bet it probably sloooows down the app considerably -- could be wrong -- like I said, I've rarel |