(Comments added for week ending Sun 26 May 2002) | View Other Weeks
| last updated:19 Aug 2002 12:01 UK time |
|
| JOS Statistics - Recent Comments (Comments added for week ending Sun 26 May 2002) | View Other Weeks |
| GUI and OOP | Sun 26 May | Sam Wong |
| This question has been bugging me for quite a while. A GUI is usually event-driven. In a medium-sized software, there are usually tens of GUI components. Some of them are active and can fire events. Some other components state may be changed as a result. My question is: What is the best way to implement this in the OOP paradigm? How to avoid or minimize coupling? Sometimes an UI component is a member of another component, but both the child and the parent components may interact with each other. In this case the parent has to pass a pointer or reference to itself to the chile object. Is it the only way to do it? Maybe this question is too lame, no book I found discussed it. |
| Sun 26 May | Scott McKissock | Take a look at Constructing the User Interface with Statecharts by Ian Horrocks. It was a big help to me a few years back when I was maintaining/rewriting a complicated inventory management system. The forms had many GUI controls whose state would depend on the state of other controls, and the code that enforced all this was bewildering because it was spread across the event handler methods. Horrock's book shows how to think of the user interface as a state machine, with user actions triggering transitions between states. Transitions are handled in controller classes in response to simple calls from GUI event handlers. The resulting code is much clearer and easier to maintain. The technique is fairly rigorous, involving the creation of UML statecharts before writing code. I'll admit that I didn't always do that, for the usual reasons one doesn't maintain UML models. Some readers may see the book as a top-heavy way to do MVC. But it provides a usefull alternative to the haphazard, non-OO approach you see in many Delphi/VB applications. |
| Sun 26 May | belize visitor | Do you know the MVC (model-view-controller) design pattern? If not, Design Patterns carries a good explanation, or searching on MVC. http://www.object-arts.com/EducationCentre/Overviews/MVC.htm |
| Sun 26 May | The Raging /.'er | Design Patterns. Gang of Four! |
| Sun 26 May | Ori Berger | Publish/Subscribe, which sometimes takes the form of Signals & Slots, is an excellent decoupling strategy; When implemented correctly, it doesn't even hinder performance. Have a look at Qt [ http://www.trolltech.com ] for an example of how this fits in an OO paradigm. |
| Sun 26 May | Alex Russell | My favorite way of decoupling these components is through a signals and slots mechanism (the type used by the QT toolkit). Signals and slots prevent you from having to use janky callback handlers that may or may not have to be passed to the firing element. Check the Trolltech site for more information on how signals and slots can make your life that much less painful. |
| Threading/Concurrent Programming | Fri 24 May | Kenshi |
| Can anyone please recommend some good texts that teach you how to do threading properly? I know its not simple, and I would like something more than just an explanation of threading and synchronisation primitives. I really need advice on how to approach multi-threaded programming in the best manner possible. Any advice or recommendations greatly appreciated. |
| Fri 24 May | James Montebello | I can recommend two: 'Programming with Threads', Kleiman, Shah, Smaalders, Prentice-Hall, 1996 'Concurrent Programming in Java', Lea, Addison-Wesley, 1997 The first covers the POSIX standard (pthreads) and is oriented towards C/C++ in a Unix (the authors were all Sun employees) environment . The second is obviously Java specific. However, both cover general threading topics pretty well. About the only general advice I can offer is that threads are, at the core, really just a easier way to code up state machines, trading code that is difficult to write with code that is difficult to debug. :-) More seriously, threads can be a big performance win in a multiprocessor environment with a suitable OS, but in a sngle processor environment it's just a coding style. |
| Fri 24 May | Chris Tavares | >>>More seriously, threads can be a big performance win in a multiprocessor environment with a suitable OS, but in a sngle processor environment it's just a coding style.<<< In my experience, the best use of threads is actually when you have to wait for something - a network packet, mouse message, serial point, etc. In those circumstances, using a thread for each thing you're waiting for is a LOT easier than the coding you'd have to do for the alternatives. So I'd say it's more than just a style choice. -Chris |
| Fri 24 May | The Raging /.'er | Depends on the os. I like Advanced Windows by Richter. I think its called Programming Applications for Windows now. Gets the job done! |
| Sat 25 May | Nat Ersoz | Advanced Windows by Richter is an excellent book. Not just as it relates to threading but as an operating system overview - specific to Win32 of course. A very good book. Unfortunately I cannot recommend a book specific to POSIX which has the coverage and clear wording of Richter's book. Also, you'll find some advantages to programming in Win32 that you won't find in POSIX: the heap kernel object, binary semaphores, and signalled events (called conditionals in POSIX) which don't get dropped. Unfortunately, life in Windows land always involves some 'greater plan' and the beauty and elegance of the Win32 kernel gets lost. It is quite simply, at its core, elegant. Good luck. |
| Sat 25 May | Nat Ersoz | Oh, one other thing. Stevens wrote a very nice set of TCP/IP illustrated books and I was hoping that his books related to Posix programming would be equally useful. Unffortunately, I found them to be almost useless. The examples are simplistic, caveats are almost never mentioned, and he introduces very simple minded wrapper based examples which detract from the subject matter. It was a huge dissappointment to encounter this. Too bad. |
| Sat 25 May | Ori Berger | Threads do not make it easier to wait on events. They make it seem easier initially (which is why this is a common belief), but sooner or later you'll find that the amount of bookkeeping you need for robust operations makes non-threaded asynchronous code significantly more attractive. For example, if your thread is read blocking on a socket, then in some Unix variants, you have NO way to abort that block - closing the socket is not enough, and if the other side is also down (and hence no data will release the block), a 'kill -9' is the only choice. You also must not hold any lock while blocking (if you want to use the CPU to the maximum and not make the program unresponsive) -- which is a bit of a problem, because e.g., a buffer you read into during the blocking call should not be read or modified (for which a lock is the easiest solution). Threads have their place, but 99% of the uses I've seen make the program either significantly more complex or significantly less robust than a comparable asynchronous design. A rule of the thumb - the number of synchronization primitive instances (locks, semaphores, etc.) should be bounded a-priori, independent of the input data, while at the same time, lock contention should be virtually nonexistent. (And if you really know what you're doing, you can avoid all locks with a compare-exchange operation, thus ensuring no deadlock and no unresponsive program under any circumstance. But for that you REALLY have to know what you're doing). |
| Sat 25 May | Tony E | http://www.oreilly.com/catalog/multithread/ I did read another in borders which was good but can't recall the publisher now. The O'Reilly book gives some good practical descriptions as well as covering the win32 specific stuff. |
| Sat 25 May | Nat Ersoz | Threads are neither difficult nor magic. In fact, they should simplify your code. If they are not making the code simpler, then you probably did not need more than one thread (in user space, there is always at least one thread). First, if you're going to read from a file/socket/device, then you'll need to get familiar with either the select() function (and friends), or signals. Using the select() function is easier and more commonly used (I think). The most common usage is to use it as a polling function. Also, the ioctl( FIONREAD ) is very useful. It allows you do determine how much data is available for reading. This is particularly useful when reading a UDP socket, and you need to know how much data is waiting in the next datagram. Signals can be used if you want to avoid a polling loop (there is little detriment to polling, however, a purist might want to avoid any cpu cycles when data is not available). So if you either want to enter the read() function (non-blocking) without the use of select, then you can use the function pthread_kill() (which has a silly name because you have no intention for killing anything, but its what you want). If all you want to do is exit a blocking call (like select, read, write, ioctl), then you just need pthread_kill() and an associated signal handler which does almost nothing (see sigaction() for signal handling). If you want to notify one thread that another thread has done something useful, then use a semaphore. They are reliable, whereas conditionals are not (if you are not waiting on the conditional when the conditional is signalled, you'll miss it - very bad). The semaphore itself can be used as a locking mechanism if you like (typical single producer, single consumer problem). For multiple consumers or consumers that consume at a rate different than the producer, or handling badly behaved devices in the consumer, you may need to add mutex locks to your shared memory areas. This is not a big deal. One place you will have to be careful is in guaranteeing thread safe performance among multi-threaded interfaces. Suppose, I have object A and object B. Both A and B are designed to be threadsafe (they are designed to handle asynch calls from multiple threads). Often, this may be as simple as guarding entry and exit points to the interface calls with mutexes. This will ensure that internal data structure changes are only changed by one thread at a time. Now suppose A calls B for a request, and then B, needs to get information from A to satisfy that request. Well suppose that A locks all his data down when B calls, and then B locks all his data down when A calls. Now nobody goes anywhere - deadlock. It is a classic case for deadlocks and you need to be aware of the potential. One key is to lock only what needs to be locked within A and B within a specific calling context. Sometimes, getting the thread id for the call may be useful too. It is a disservice to obfuscate what should be a simple tool in every software engineer's toolkit. No wonder people dummy down to Visual Basic. >> Threads do not make it easier to wait on events. This is incorrect. Every user space wait on an event, semaphore, blocking call, or signal is done within a thread context. >> For example, if your thread is read blocking on a socket, >> then in some Unix variants, you have NO way to abort that block. I am not aware of any Unix variant which does not allow the use of SIGUSR1, SIGUSR2, SIGIO, or other signals for use as a handled signal. Additionally, all real-time signals can be used (usually there are 32 of them) for handling device driver communcation to and from user space code. Side note: realtime signals queue up as opposed to non-RT signals, which get dropped when one signal is already pending of the same number. So you can drop non-RT signals when you don't handle them fast enough. >> You also must not hold any lock while blocking This is untrue. A typical read from a file/device/socket looks like this: select(); mutex_lock(); read(); mutex_unlock(); OR, if you don't like selet(), use a signal when necesary to free the read(). >> Threads have their place, Every time the CPU program counter moves in user space code its within a thread context. Got main()? Got threads. >> but 99% of the uses I've seen make the program either significantly more complex or significantly less robust than a comparable asynchronous design. I'm not sure what Ori is driving at, but any user space event which occurs that is asynchronous comes from another running thread context. There is no other way to be asynchronous in user mode. Ah, but someone says 'what about signals?' Yes, a signal is asynchronous in its timing but the thread context of your signal handler will be within your running thread which got signalled. Also, the signal had to come from somewhere - either the kernel or another thread (if that last part about signals is confusing, forget it, I'm being pedantic). Learn to use threads and other kernel objects that are either part of the POSIX or Win32 system programming environment. To ignore a useful tool like threading is to place yourself in a very limited box. Again, the Richter book is a very good place to start, even if you're not a Win32 fan. |
| Sat 25 May | Ori Berger | << |
| Sat 25 May | Ori Berger | Back in 1988 or so, the most common GUIs on PCs were text mode, and almost none of them was asynchronous (or even event driven) in nature. A program would usually present a question like '' Please type in your age in microfortnights'', and the code behind it would look something like age = get_number('age in microfortnights'); (or more commonly, INPUT 'age in microfortnights', AGE ....) Want help (e.g., what the hell is a microfortnight)? tough luck, get_number didn't support it. Want to cancel? Tough luck again, get_number can only return numbers, not cancel. If get_number was really well written, it might return an error code ('help requested' or something to that effect) - but it required checking and handling appropriately in every place. GUIs were working, but not intuitive, not really responsive, and extremely intolerant of non-expert users (often, no 'back' or 'cancel' option was coded, or was only available at very specific points in the path). Then came event driven systems like TurboVision, and Win3.0 became popular - and suddenly, everything started to behave 'properly', even though there were no threads in sight. The reason event driven systems are so much better at handling GUIs is that humans don't like to follow any well-defined interaction path. And that is also the case for any external event, such as a network connection. Like a user pressing 'F1' at any moment, a network connection can break or stall at any moment, or start feeding trash at any moment (bug at other side, or connection hijack). Contrary to common belief and most testing scenarios, these things do happen. What I'm driving at is this: Look at your last non-Java GUI (Win32, MFC, FLTK or Visual Basic are fine examples). Did the GUI have multiple windows? Most probably yes. Did it have multiple threads? Most probably not (GUI part only, guys). Why is that? Because most mouse clicks or text entry items are handled quickly enough as atomic events. Even if you do have, e.g., one thread per 'toplevel' window, you don't have one for every control - the same thread multiplexes input from 20 input fields, and eventually (upon pressing the 'submit' button or equivalent), handles it atomically. That's the simplest way there is; there is no competition for resources requiring fragile[1] synchronization. Question: Why should socket input be different? Why should the program ever block on anything externally driven, if it doesn't do it for GUI input? There are a few constraints, e.g., gethostbyname() has no non-blocking alternative on Unixes - but this is the exception rather than the rule. Asynchronous GUIs are responsive and better adapted to deal with human input. Asynchronous network processes are more robust and better adapted to deal with network failures and stalls. Asynchonous disk processes are usually not needed because disks are at the same time significantly faster and significantly less error prone than networks - but still, if you want to maximize performance, are essential. To ignore a tool like threading is placing yourself in a smaller box than you should. But threads are highly overrated and misunderstood. Don't use threads unless you know how to achieve the same results without them (always possible) - and only once you do, evaluate which solution is simpler. Eventually, I usually find that a (conceptually) single threaded event driven structure works best, but it sometimes needs a bounded number of support threads in order to align all systems with the asynch regime. [1] By fragile syncrhonization I mean e.g. the example Nat gave, of two objects each of which is thread-safe in its own right, but which are not thread-safe if used together. The contracts in such cases must carry implementation details about lock dependency, which goes against [almost] everything OO stands for. |
| Sat 25 May | Dan Maas | Ori is right... Threads are for one thing and one thing only - running CPU-intensive code asynchronously (either via time slicing or on another CPU), and only when the code really needs to share all of its memory with other threads. However, I can excuse people who use threads for waiting on things when a good non-blocking I/O API is not available. (e.g. anonymous pipes on Win32, or disk I/O on UNIXes that do not support POSIX aio). I can also excuse the use of threads for independent parallel computations on operating systems that make it difficult to use separate processes (Win32). |
| Sat 25 May | The Raging /.'er | I don't know if Ori is right or not, when does 'Ori in a nutshell' come out? Just kidding! I always create a seperate thread for each window in my gui apps. Each window gets his own message pump. He like it that way! |
| Sun 26 May | Nat Ersoz | >> Except that you can't decide which thread gets the signal. If you had 1000 threads all blocking on input,...
Partly yes, and partly no. Partly yes, I agree:
It is unfortunate that signals are so screwed up in this way - that what the Sys V and ANSI API specifies you signal are processes not threads, yet in every sense of the word, what you are signalling is a thread and what is blocking is a thread, so how did this get so screwed up? Obviously, threads were (almost) non-existent prior to Win32 and POSIX standards: only one thread ran per process.
It is also unfortunte that ANSI C decided to even include the |
| Sun 26 May | Ori Berger | I agree with most of what you state, Nat, except possibly the following: The reason win16 crashed often was mostly that everything was _shared_. The fact that multithreading/multiprocessing was cooperative had little to do with the crashes. It did mean, however, that code not Yield()ing often enough could hang other processes. And real time threads MIGHT be reason enough to use threads in some cases, but so long as the entire O/S isn't real-time, it only reduces the probability of data loss (in the examples you gave), but does not eliminate it. You have no way to insure in user mode that kernel objects (e.g., semaphores, file objects) are paged-in. With some work you can make sure some memory is paged in, but if you want absolutely zero probability of lag, you need a different style of O/S. In a sense, expecting single threading to be sufficient is like expecting Win16 to work as well as Win32 (assuming Win16 had address space separation) - which is probably a bad idea. But there's a difference - one application on an O/S cannot control how other applications abuse the CPU or other aspects of the co-operative paradigm. Inside an application, it is usually possible to balance all things inside - except perhaps incompatibly designed external components you are forced to use (e.g., gethostbyname()). And actually, while virtual memory is sometimes a godsend, it is - much like threads - overrated and misused very often. I've had a chance to speed a program 1000-fold (yes, that's three orders of magnitude) by changing loop order from something like for (i = 0; i < LRG_NUMBER; ++i) ... for(j = 0; j < LRG_NUMBER; ++j) ...... process(data[i][j]); into: for (ex_i = 0; ex_i < LRG_NUMBER; ex_i += SML_NUMBER) .for (ex_j = 0; ex_j < LRG_NUMBER; ex_j += SML_NUMBER) ..for(in_i = 0; in_i < SML_NUMBER; ++in_i) ...for(in_j = 0; in_j < SML_NUMBER; ++in_j) .....process(data[ex_i+in_i][ex_j+in_j]); Because the original author didn't take the effects of virtual memory into account; And once this substitution is made, virrtual memory is in fact much less useful because block-structured disk files could have been just as easily and just as efficiently prefetching and caching. But I agree that in general, under the assumption that physical memory is sufficient to support the locality-in-time of memory access used by the program, virtual memory is extremely useful. Apart from that - well said. One shouldn't avoid a tool just because it is mostly misused. But one should be wary that this the common practice is bad when learning how to use the new tool. /.: Sorry, I'm too big to fit in a nut shell :). In what way does the per-window message pump affect the way your program is written or responds? |
| Sun 26 May | Dan Maas | A per-window message thread will do two things: 1) slow your program down, because of the extra thread switch to handle an event, and 2) create hard-to-find bugs when one event handler pre-empts another at an unexpected time... It reminds me of the BeOS users who believed the hype that 'BeOS was fast because every window was a separate thread.' This is wrong - BeOS was fast because the developers worked hard to reduce latency for common operations, and ran many tasks asynchronously. (note: asynchrony doesn't necessarily require multithreading...) |
| Sun 26 May | The Raging /.'er | Dan my users never have noticed the slow-down! ;) Actually, I havne't done much gui programming. I try to stay on the server side. But this is a plugin architecture where those dlls need to process messages. Each dll gets to do its own thing and the main program never knows. Just easier that way, at least for me! Would there have been a better way? |
| Sun 26 May | Nat Ersoz | >> You have no way to insure in user mode that kernel objects (e.g., semaphores, file objects) are paged-in. With some work you can make sure some memory is paged in, but if you want absolutely zero probability of lag, you need a different style of O/S. Actually, mlock(), and munlock() work very nicely in Linux (I've not tried these in other OS's - but it is a POSIX call). FWIW, My favorite on line man page place: http://www.opengroup.org/onlinepubs/007908799/xsh/mlock.html Also, in Linux, real-time threads and mlock() require super user privs - which make some sense - you don't want to allow users to promote themselves to realtime on a whim. However, I think having a group would be a better idea. More later... Gonna go see Spiderman... |
| What websites do you check regularly? | Fri 24 May | MarkTAW |
| On any given day during my down time I visit this board. I often hear the discussion of a topic on joelonsoftware.com before I even know that there was a post there. I also visit several newsgroups from home - corporate firewall prevents me from doing anything but browse the web and there are very few web-based good newsgroup readers. These newsgroups arent at all work related, so thats another reason I check them from home. I visit http://www.freshnews.org which is basically a feed from various technology related websites. Including slashdot, zdnet news and orielly networks, which are their first three, just to give you an idea of the breadth it covers. Visiting here and scanning the headlines keeps you really up to date. Occasionally Ill check the new software on http://www.webattack.com - anything to make my life a little easier is welcome, and sometimes a small freeware program fits the bill. Their categories are easier to navigate than download.com or tucows. What sites do you visit regularly during your downtime, and what value do they provie to you? |
| Fri 24 May | Joe Blandy | http://www.fark.com/ - Always good for a laugh. |
| Fri 24 May | John C | http://www.weblogs.com/ and then a random blog. |
| Fri 24 May | Dustin Alexander | In any given day I check quite a few web sites. Some have actually suggested that I use my diverse tastes and the internet as a sort of procrastination device. I give them little credit, though. Some days you just need your news. Sites that I like to check: www.times.com - Let's me know if anything that was here yesterday is gone today. I pay special attention to the economy stuff, since it affects me on a daily basis. I have registered, but I never dig in enough to use it and I've forgotten my password. Who needs in depth news, anyway? www.slashdot.org - Linux, Technology, Sci-fi. Good stuff. www.penny-arcade.com and related links - Web comics and logs are an unfortunate and growing addiction of mine. The gaming comics are edgy and have a good sense of humor. www.joel-on-software.com - I check this site a few times a day. Joel has a way of being right on target as far as where I am with the projects I am trying to manage. I don't think he's ever written an article that wasn't in some way applicable to me. www.linuxsecurity.com - I'm a Linux fan. As a result, I am chained to constant news and security updates. Linuxsecurity is an excellent resource. Other sites I check are cert.org and securityfocus.com. kernel.org gets check once a week in case anything new is out. The Filthy Critic www.bigempire.com/filthy - Another good dose of humor with my morning coffee. And once I'm done reading those, I actually do an hour of work before I go home. :) |
| Fri 24 May | Ori Berger | http://online.securityfocus.com - especially the vulnerability section (Be aware though - by the time a vulnerability makes headlines on Security Focus, an exploit is usually already circulating) http://freshmeat.net - whenever I need to find working source code for something - which is quite often. Also, announcements about interesting new software (arch version control, doxygen doc extractor, gcc, etc.) appears here. http://flipcode.com - mostly of interest to people with interest in CG and Game development, but the links and 'code of the day / tip of the day' are often relevant to everyone. http://userfriendly.org - for laughs |
| Fri 24 May | Adam | In adition to those listed above: theserverside.com --since I am a J2EE Guy theforce.net --sorry about that one ;) news.yahoo.com --fills in the ap and oddly enough news space.com |
| Fri 24 May | Adam | Webcomics: User Friendly the Comic Strip - The Daily Static www.userfriendly.org Sluggy Freelance © 2001 Peter Abrams www.sluggy.com FoxTrot http://www.ucomics.com/foxtrot/viewft.htm The rest of these are on Keenspot www.keenspot.com Sinfest General Protection Fault--The Comic Strip ? - The Slightly Demented Daily Comic Strip Alice Comics.com | Alice! Greystone Inn - Thursday, November 1, 2001 PvP - Player Versus Player - The Daily Online Comic Strip The Joy of Tech! Kevin & Kell by Bill Holbrook http://www.choppingblock.org/ Ubersoft.net: Standing on the Necks of Giants Blood Lark - the comic that will take over the fantasy genre!!! Schlock Mercenary, the online comic by Howard Tayler Clan of the Cats - Comic Only Dave Kelly's LIZARD! Sex & Violence - Do you feel the agony, Jubei? |
| Fri 24 May | programmer | Sites I look at daily: -- The Drudge Report ( http://www.drudgereport.com ): Breaking news almost always appears there first, and if your web-cruising time is limited, ten seconds checking this out keeps you updated on what's going on. -- Arts & Letters Daily ( http://www.aldaily.com ): Links to great articles on arts, literature, culture. -- Science and Technology Daily ( http://www.scitechdaily.com/ ): This is apparently run by the same folks who do Arts & Letters Daily, and has a similar format. -- Slate.com ( http://www.slate.com ): One of the most interesting web opinion journals -- very well done, although it's sometimes a bit too cute. -- Washington Post ( http://www.washingtonpost.com ) -- New York Times ( http://www.nyt.com ) |
| Sat 25 May | Emil Rasmussen | Besides joelonsoftware.com... http://php.weblogs.com -- PHP, SQL and other news /Emil |
| Sat 25 May | Matthew Lock | If you don't read http://slashdot.org everyday then you should have your CS degree revoked. |
| Sat 25 May | John Burton | I just went to slate as was suggested by someone here, and found it completely impossible to read the articles. Every few seconds an advert would appear which actually blocked the text of the site. I can't think that anyone has ever found a better way to ensure they have no readers very quickly. |
| Sat 25 May | Nick Hebb | http://www.cafeaulait.org and http://www.cafeconleche.org - Author Elliotte Rusty Harrold’s Java and XML sites. Rarely go for the Java and XML stuff – instead I like the daily quotes and the list of recommended reading links. http://www.pbs.org/cringely - Robert Cringely’s weekly The Pulpit column. He’s the one who did the PBS show ‘Triumph of the Nerds’. The best reason to read him is summarized in his quote “It's not that I am so smart, but that my friends are smart. The best and brightest in Silicon Valley talk to me all the time.” http://www.useit.com/alertbox - Jacob Nielson's bi-weekly usability column. His ideas are far-fetched at times, but he does his research. |
| Sun 26 May | JD | I just have time to check up few forums on daily basis. http://forums.devshed.com http://www.experts-exchange.com Also I go through http://www.hotscripts.com http://www.freshmeat.net http://www.phpbuilder.com and ofcourse, joelonsoftware.com JD |
| What do you use for version control? | Fri 24 May | Erik van Linstee |
| This topic may have already been discussed at length, but I cant seem to find it at the moment, so please point me in the right direction if you can. I have used RCS and CVS a long time ago (still on DOS and OS/2) and have been using CS-RCS for occasional version control of mostly Word-documents, because of its integration with word. Lately I have had to do some coding again and started of with CS-RCS for that too. But I am not completely satisfied and am curious if there are alternatives that might fit my needs even better. What do you use and why do you prefer it over other tools? Hopefully your experience leads me to a better match... Erik |
| Fri 24 May | MH | You can search for 'cvs' in the handy search feature. Are the discussions good enough there? |
| Fri 24 May | Dustin Alexander | I've been using plain old CVS from cvshome.org. Most of our developers use a mix of desktops. I personally use UNIX, so a cl system with different front ends was a good solution. Unfortunately, CVS itself is full of bugs, issues, and poor merging. I've been trying to drum up internal support to rewrite it as a web service using XML markup, but so far other projects have kept me too busy. Anybody have anything that is more flexible that runs on both UNIX and Windows? |
| Fri 24 May | Alex Moffat | I've used CVS quite a bit and I don't understand what you mean by 'CVS itself is full of bugs, issues, and poor merging'. What things cause you problems? As for 'drum up internal support to rewrite it as a web service using XML markup' I can only ask, are you serious? It's not as easy as it may look. If you want to see what an alternative looks like you could try subversion http://subversion.tigris.org/. They've been writing a cvs replacement for a year, with several full time developers and they are still not done. Of course if you have lots of money there is always ClearCase from Rational, I'd stay away from Source Safe from Microsoft, I know people who have lost updates etc. |
| Fri 24 May | Ori Berger | CVS has nearly no bugs. It doesn't always do what you want (e.g., repeat merge is 100% manual and not easy to get right; it can't store 'renames' within the repository) but these are not bugs. Personally, despite its various shortcomings, I've been very happy with CVS as it does do well within its realm, and it has useful add-ons that do most things I need (web based browsing, 'cvs annotate'). If you're looking for alternatives .... On the free software front, you have Subversion, from the same people who brought you CVS; They describe the project as an attempt to do cvs right (with the 15 years of experience they now have), rather than to innovate - see [ http://subversion.tigris.org ]. There's also 'arch' from Tom Lord - [ http://regexps.com ]; It's much more ambitious, handling distributed repositories, arbitrary branch topologies etc. It's unix centric, but there's a cross platform Perl port underway. Commercially, there are StarBase, BitKeeper, Perforce and ClearCase that I'm aware of; Of these, everyone that uses any of the first three swears by them, and some also swear by ClearCase. Of these, as far as I know only BitKeeper supports distributed branchs. StarBase has a very-well integrated issue tracking system (it's _extremely_ helpful when the bug database and version control database are always in sync), as does ClearCase. Perforce just plain works (This is what Microsoft uses internally). Disclaimer: Of the commercial alternatives, I have played with StarBase, but not enough to claim familiarity, and haven't even had this little experience with the other packages. |
| Fri 24 May | Dustin Alexander | Sorry for the unintended deception. What I meant by CVS being full of bugs is that it often acts unpredictably. This is more of a result of the multiple non-friendly front ends that are available in the open source community for dealing with CVS and is not CVS' fault in particular. I also find it difficult to manage the CVS back end file system, especially if you have little or no knowledge of the file system dynamics. In my mind, developing a purely IT solution as opposed to an OS flavored solution would be easier to manage for current industry professionals. As it is right now, I'm the only one in our company who can work with it [the server]. We consist mostly of senior level programmers who 'don't have the time' to learn 'new fangled techniques'. What I would like to see is a system that is network manageable and supports modern protocols with a modular and easily extensible base. Something that is so easy to slap a front end on that you don't have to understand any system variances to do so. CVS is good as far as it goes, but its an old technology that is in desparate need of renovation for the new age. Also, about rewriting it. Yep. I'm serious. We've got the intellectual assets to back it up internally. Its just the justification I'm looking for. That and the time. Seems like the problem of scarcity dominates every layer of our current sphere. I've been watching the subversion project for quite some time, although not closely. Anyone actually put the thing into production or test environments? |
| Fri 24 May | Dustin Alexander | Sorry about the 'problem of scarcity' comment in advance. My brain is currently an oil and water mix of philosophy and computer science and someone is shaking me. |
| Fri 24 May | James Montebello | CVS *is* being rewritten, it's now called Subversion. The authors have been hacking on CVS for years, and provided much of the useful development on it in the past few years. It's about to go Alpha, and has some wonderful features. I'd be willing to bet than in two years, there won't be any question as to the best version control system. |
| Fri 24 May | Robert Anderson | There is also 'arch' an up and coming revision control system with a lot of nice features. Although it is not particularly mature yet, it is quite useable already. www.regexps.com |
| Fri 24 May | Ori Berger | << I also find it difficult to manage the CVS back end file system, especially if you have little or no knowledge of the file system dynamics >> I don't think any statement could have been more confusing for me. Of all available version control systems (except, possibly, arch), CVS's back end file system storage is by far and large the easiest to understand and (here even arch isn't a contender) the easiest to manipulate. << In my mind, developing a purely IT solution as opposed to an OS flavored solution would be easier to manage for current industry professionals >> That's probably true, but the reason is that current industry professionals are unprofessional. Let me rephrase what you're saying: 'I prefer an opaque system I have no undertstanding of, and which I cannot manipulate, over one which uses the well tested, well understood, heavily debugged, widely supported, file system structure'. Or do you have a specific setup in mind that is based on something more ubiquitous than a file system? << We consist mostly of senior level programmers who 'don't have the time' to learn 'new fangled techniques'. >> File system? 'new fangled'? Seems like we're not working in the same industry. << What I would like to see is a system that is network manageable and supports modern protocols with a modular and easily extensible base. Something that is so easy to slap a front end on that you don't have to understand any system variances to do so. >> OK now I really, really am at loss. CVS is as network-managable as it gets - you can do 99% of the things through TCP connections (pserver), and the rest are pure file system manipulation (which are also as network-managable as it gets). What does a protocol being 'modern' have to do with anything? It's well documented (though it does have its quirks), it's working, it has several implementations, including libraries you can just plug into your software and use - even though IMHO 'cvs.exe' is the best encapsulation you can have. YOU CAN'T SLAP A FRONT END WITHOUT UNDERSTANDING THE SYSTEM. I know it's hard to grasp, but unfortunately, that's the way it is. If you don't handle the specifics in the front end, you either pass them to the user (bad), or deprive the user of real functionality (worse). You can't even use a system properly if you don't understand it. This is always true, but especially so for version control, where things like merge conflicts cannot possibly have a 'well defined' resolution. Check out the explanation of star topology merges and merging of independently advancing branches in the arch documentation, for an example - it goes to great lengths to do 'the right thing', but sooner or later you'd have to know _exactly_ what it does or you'd find it 'unpredictable' again. And while it is basically simple, the devil is in the details. << Also, about rewriting it. Yep. I'm serious. We've got the intellectual assets to back it up internally. Its just the justification I'm looking for. That and the time. Seems like the problem of scarcity dominates every layer of our current sphere. >> This assertion is not backed up by the rest of your post. CVS has got one thing basically wrong (the fact that tags, branches and revisions are distinct notions), a thing or two somewhat wrong (project wide operations like tagging take time proportional to project size), and a thing or two inconsistent, but all in all it doesn't get many things wrong - most of the implementation details within this framework are very well done. You actually haven't said what it is that you find unpredictable about CVS - being a long time CVS user I know how to use it and it's thus very predictable for me. Tom Lord wrote arch because he didn't like the way CVS (or subversion) did things, but he has very specific scenarios and targets he wanted to achieve. If you find CVS file based structure confusing, you probably have much less intellectual assets to back this up than you believe. Furthermore, it makes so little business sense to write a version control system unless you plan to sell it, that I'd guess you're working for a government or academic institution which doesn't really have to justify these kind of investments. Find out what it is that really troubles you about CVS, and solve that problem, possibly through a CVS frontend (and/or any of the other existing tools instead of CVS). This is, for example, what 'mcvs' does - it's a CVS front end that versions metadata (file names, directory names, permissions, etc). It's two hundred lines or so - much less than rewriting would take. It also shows how modular CVS effectively is. There's also a backend module for CVS called nserver that isolates authentication and authorization so that the cvs pserver doesn't have to run with broad permissions and isn't tied to the underlying operating system user list in any way. CVS and others are showing their age, both negatively (flexibility) and positively (robustness). Unless you have an idea for fundamentally different dynamics (the way BitKeeper and arch did, for example), use an existing version control system - it makes much more sense. |
| Sat 25 May | Dustin Alexander | Thanks for the post. Lots of interesting ideas to pursue. I think my major problem with CVS is that its fragile. I'm not speaking from a personal standpoint, although I do not claim to be an industry leader in version control theory. I'm speaking from the implementation standpoint that you refer to when you speak of requiring an understanding of the system in order to function. Currently the way it works is that a person who has no understanding of the system will most definitely break it, either by doing false imports or performing another brain dead error that breaks the repository. The system is not in any way robust or 'idiot proof'. You see, I don't necessarily agree with your point. I think a versioning system could well be implemented transparently, so that developers do not even know they are working with it. Requiring a deep understanding of system functions is poor UI. I'm not arguing that nobody in the project needs to understand the system, I'm saying that there has to be a way to design a system that does not require significant understanding by all participants to function. Moreover, I'm saying there may be a way to allow users to adapt a front end without having significant understanding of the back end. This is what interface logic and web services/XML are all about. I spend most of my day working with self adaptive systems that don't require a whole lot of user intuition or maintenance in order to function. Another issue that I have with CVS is that its robustness seems to depend a great deal on the robustness of the underlying file system. It is in no way capable of maintenance and self repair, something that gets on my nerves. If you've ever had to manually go through and hex edit a repository to deal with linefeeds for different systems, you'll understand what I mean. Such a process is so trivial that its automation should be a foregone conclusion. In the end, I'm not saying CVS does not work. I've been using it for a few years now and I'm happy with the results that versioning has had on our quality of work. I'm simply saying that there is still room for groundbreaking improvements in the areas of robustness, fault tolerance, and simplicity. I'm not posting this stuff as flame bait. I'm actually very interested in people defending the current system, as again I am by no means an expert on these matters. As for my organization, we do not waste time and money like inefficient groups such as goverments and we are not enitrely profit oriented. Our goals are far and away intellectual as opposed to material. It would be worth the effort to implement just about anything if I could come up with an improvement argument for the group as a whole. If I could walk in and tell them that we can make substantial improvements to a system, that in itself would be the number one reason for development. I am in the wonderful position of working in an environment where the pursuit of ideas is a primary goal. :) Thanks for the time you put into that post, by the way. I am grateful that you feel strongly enough to work with me on an understanding of your viewpoints. |
| Sat 25 May | Nat Ersoz | I can smell the steam rising from what must be the world's largest pile of horseshit... |
| Sat 25 May | Dustin Alexander | I'm quite taken with the smell, myself. ^_^ |
| Sun 26 May | Bella | Clearcase. But it may be overkill for your needs. http://www.rational.com/clearcase |
| Sun 26 May | James Ladd | StarTeam from Starbase Corporation. |
| Sun 26 May | Eric W. Sink | Responses to three details: 1. CVS is not full of bugs -- it's full of bug fixes. The CVS codebase is nearly a perfect example of Joel's assertions about the fact that mature code tends to be ugly and brittle. Its code is a nightmare, but CVS mostly does what it is supposed to do, rather well. 2. I can confirm that writing a new version control system as a system of XML web services is a pretty big undertaking. We're doing it here at SourceGear (see vault.sourcegear.com). It's a big project, and we obviously plan to sell it as a product. I can't imagine tackling something like this as an internal effort. Very few companies could absorb the development costs, but very many companies could grossly underestimate the effort involved. 3. As far as I can tell, there is no actual confirmation that Microsoft uses Perforce internally. They use a tool which is called SourceDepot. That tool is *rumored* to have been based on Perforce, but that's a very unconfirmed rumor. My personal opinion is that the rumor is not terribly credible and has very little evidence to support it. |
| MS EULA: JAVA TECHNOLOGY IS NOT FAULT TOLERANT | Wed 22 May | Matthew Lock |
| Just noticed that in my EULA for Word 2000 it says: NOTE ON JAVA SUPPORT. THE SOFTWARE PRODUCT MAY CONTAIN SUPPORT FOR PROGRAMS WRITTEN IN JAVA. JAVA TECHNOLOGY IS NOT FAULT TOLERANT AND IS NOT DESIGNED, MANUFACTURED, OR INTENDED FOR USE OR RESALE AS ON-LINE CONTROL EQUIPMENT IN HAZARDOUS ENVIRONMENTS REQUIRING FAIL-SAFE PERFORMANCE, SUCH AS IN THE OPERATION OF NUCLEAR FACILITIES, AIRCRAFT NAVIGATION OR COMMUNICATION SYSTEMS, AIR TRAFFIC CONTROL, DIRECT LIFE SUPPORT MACHINES, OR WEAPONS SYSTEMS, IN WHICH THE FAILURE OF JAVA TECHNOLOGY COULD LEAD DIRECTLY TO DEATH, PERSONAL INJURY, OR SEVERE PHYSICAL OR ENVIRONMENTAL DAMAGE. Id like to know how Java is not fault tolerant to the same degree as other languages. If that is the case? |
| Wed 22 May | Sherrif Lobo | That's got me worried now about the Nuclear Power Plant system I made using Java applets. |
| Wed 22 May | Joel Spolsky | That wording actually comes from Sun, which puts it in all their products. |
| Wed 22 May | Name withheld to protect the guilty | Funny enough, a friend of mine wrote some code in Java which is part of a particle accelerator control software. It happened to work better than the C code they were using (full of bugs BTW). Hum, since then, he refused to work on this anymore since they asked him to make the C version to work and shut up about the trouble... And the device works in hospitals... Oh my god ! |
| Wed 22 May | Charles Miller | Even sillier, there's a similar clause in the license for POV-Ray. http://www.povray.org/povlegal.html |
| Wed 22 May | Boris Yankov | The stuff about the nuclear plants and some devices may be is written because of the unpredictability of the garbage collector. Because of it Java applications are not well suited for such real-time devices/systems. Or this is just a precaution. |
| Wed 22 May | Matthew Lock | I did work experience at nuclear power plant in the UK during the early nineties. They ran the plant on a computer from the 60s which was built out of discrete transistors rather than ICs. |
| Wed 22 May | Joe AA. | The UK is much more advanced than the US when it comes to software control of nuclear power plant processes. The NRC won't allow software process control to be used in reactors... software can be use for 'process monitoring', but not control. |
| Wed 22 May | Paul Vincent Craven | No language is fault-tolerant. You have to program your entire system to be fault tolerant. This has more to do with your application program and hardware set-up. C has no code that it brings in with it by default. Java, VB, etc. has a lot. They didn't create those virtual machine environments with the idea someone's life may depend on it. Control systems for airplanes, nuclear plants, the Space Shuttle usually run on very simple computers where the OS and everything else is built by the people that put together the system. The system's don't run Solaris, Windows, etc. You might find parts of the Linux kernel lifted and used in new systems. That's about it. |
| Wed 22 May | dumbconsultant | actually, I was talking to an airline employee in a bar about a year ago (forgot which airline...based in chicago) and, some portions of the airplane are controlled by windows. I believe it is something like the refridgeration system for the food. Not mission critical, but i have been on a plane which was stalled on the ground because the refridgeration system wasn't working. The employee said that when that system acted up, the staff would just reboot it. :( |
| Thu 23 May | Nat Ersoz | Of course there is always this jewel: Windows NT cripples US Navy Cruiser http://www.info-sec.com/OSsec/OSsec_080498g_j.shtml |
| Thu 23 May | Charles Miller | Java compilers and virtual machines are given a lot of leeway in how they're allowed to re-order instructions for the sake of optimisation, and that leads to some... interesting results when you start dealing with multiple threads, such as the following example: Initially, x = y = 0. Thread 1: a = x y = 1 Thread 2: b = y x = 1 It's possible in Java for the result of these threads running concurrently to be a = b = 1. http://www.cs.umd.edu/~pugh/papers/jmm2.pdf |
| Fri 24 May | Joe AA. | Charles... we will be much more productive if we didn't have to write every bug ourselves. A real shortcut to being state of the art. |
| Sun 26 May | Albert D. Kallal | Darn, why did someone have spill the beans and expose that his EULA policy comes from sun? I was hopping we let this thread get a lot larger, and a lot more people could make fools of themselves while stating that MS has such a “evil” software policy *Then* we could mention that this originates from sun! Darn....did we miss a opportunity for some fun here or what! |
| How to protect web-based app? | Fri 24 May | Sergey |
| Hi all, We are creating web-based application using JSP and Struts. We would like to limit the number of concurrent users, and if the limit is reached, new users wont be able to log on. The trouble is, the application will be deployed on the customers computer. Is it possible to somehow protect the logic that handles the logon process and user autentification from being potentially modified by the customer? Thanks in advance for any feedback, positive or negative! |
| Fri 24 May | Brad Clarke | How about using semaphor based locking model using a database table. Make the number of users configurable in a tunable table, once max number of users have logged on, allow no more. If it is a web app, why would it be deployed on the users computer? (have not used struts, so maybe that's why I ask) |
| Fri 24 May | Rich | Definitely don't put the login logic in a JSP since pretty much anyone with write access on the machine can make changes. I have not done this, but signing and sealing the jar should help you make sure your code is running, and not someone elses. http://java.sun.com/docs/books/tutorial/jar/ |
| Fri 24 May | Sergey | Brad, Our customers will install and run the app as their 'corporative' server. It's easy to keep track of users, and to allow/disallow logon, we just don't want anyone to modify the app and disable these nice features. Rich, Thanks for the suggestion to sign/seal the jar file. We also plan to emit the most significant HTML content from custom JSP tags, and as a side effect these tags can test if the logon was real, not faked by altered JSP page. On the related note, what would be the good way to prevent customer from buying one copy and installing it in multiply places? |
| Fri 24 May | Adam | To make sure that you have no more than 10 active sessions, create an Application scope JavaBean that keeps track of the number of active sessions. Create an Event listener for session creation and session completion that increment and decrement the count on as sessions are createdand destroyed. For the deploy multiple times, make them enter the key on an admin screen when they first start the program. persist if. Give them a key tied to the machines MAC adddress. Yes, they can spoof it, but for a corporate machine, they are not too likely. Have a filter that checks for the key before any important action, or extend the Struts ACtion Servlet to do this itself. |
| Sat 25 May | x | Why not using a filter instead of mssing with all the apps ? |
| Sat 25 May | Sergey | Because the filter can be removed or replaced by the customer. |
| Sat 25 May | Alex Moffat | Not reall an answer to the question you asked but... I'm guessing that you want to prevent more logins because the customers only paid for X and should only be allowed to use X. If it's because the system won't handle more than X that's another issue:) If you distrust your customers so much that you think they'll hack your code that may be a bigger problem. One possibillity is not to disallow logins but to keep track of the maximum number of concurrent users and just ask them to buy more licenses. A lot depends on how many copies you expect to sell etc. If these are big accounts then no license, regular contact with the help desk/consultants, and the knowledge they signed a legal agreement when they purchased the stuff is what's been used elsewhere. |
| Writing skills | Fri 24 May | NathanJ |
| Hi, I work on a project of about 25+ people. In my opinion the architect on our project has terrible writing/communication skills. Here is an example from one of the documents he worked on: One other addition in our new class is the addition of the isOwner Boolean value. The details on the use of this are explained in more detail later. I think this becomes more clear as: Our new class also has an isOwner Boolean value. Details on using this are explained later. It seems like everything he writes takes about twice as many words as necessary (as well as almost always using passive voice). I realize I am not the best writer either, but I think carefully written documentation really helps out on large projects. What do other people think? Also, I am just a lowly developer on this project (5 years exp). Any ideas on tactfull approaches to get this guy to use better wording? Thanks |
| Fri 24 May | Troy King | It appears he's trying to sound 'technical' or 'official.' Too many technical explanations sound stinted like that. I suspect just talking to him about it might fix the problem. Explain the wordiness is cumbersome. |
| Fri 24 May | The Raging /.'er | Wow! I wish I had you're problems! We don't even have documents were I work. You get handed an idea for a project and you are expected to start coding. Our veep doesn't see anything wrong with it, he's always done it that way! Oh well, as long as there paying me! |
| Fri 24 May | Nat Ersoz | I find the term 'architect' to be overused these days. From what I can tell, this term almost seems to have originated with the book 'The Mythical Man Month', where Brooks notes that had he allowed the architects to do their job the OS/360 would have been a far more robust product. This is a fine context for architect. In fact, I would specifically state that an architecture group, or individual, is necessary when: 1. The technology is so large or complex or interdependent that there needs to be a specific focal point for design. 2. The technology is so new that mere mortals don't maintain the math skills necessary to keep up with the inventors. Are there any reasons I missing? With respect to item #1, I often find that many systems don't have an excuse to be so large/complex/interdependent. That they can be simplified into simpler individually managed segments. With respect to item #2, there truly is a need for enlightened, above the fray, experts. In this case you often truly do need an architect/senior scientist type person to organize design. Howver, in most cases, it is more useful to have technical experts in individual areas: a codec expert, a security expert, a networking expert, ... These people with specific expertise which the rest of the team can draw upon for sanity checks and design reviews. True experts in their fields who have deployed their work several times in the past and have already learned from some mistakes. I find the term architect more ridiculous when the architect is defining class members. |
| Fri 24 May | NathanJ | >> I find the term architect more ridiculous when the architect is defining class members. << Nat, thanks for your thoughts. I agree with your post for the most part. But the proper roles for an architect wasn't really part of my question. From my example you assumed our architect mainly defines class member - that's not really true (but I can see how you would think that). I just happened to choose one of the 2-3 paragraphs defining a member out of a 15 page document. In defense of our project I would say we need an architect because of your problem #1. We have over 20,000 classes in the source repository. My 'project' is really a subproject working to extend the existing code for a certain market. Other teams are either supporting the frameworks or working on other market areas. In agreement with you - I think the architect for my project is a control freak who doesn't trust the developers (or other teams). As Troy pointed out earlier he tries 'to sound technical or official'. I have been in numerous meetings where this architect has insulted or demeaned other peoples work. Anyway, I don't want to open a whole can of worms on this. I am just trying to work within my 'sphere of influence' and improve the little areas. I've only been at this company since last fall and I'm trying to give it a chance. Maybe in a couple weeks there will be another post from me asking how to improve the rest of my job :) |
| Fri 24 May | Ian Stallings | Although I do agree the term architect is probably overused in software, I think architects are not only necessary on large complex systems or systems where you need truly enlightened individuals. A traditional building architect can be someone who designs a simple house (or more likely simply signs off on the design) or they could be the one designing the world's largest sky scraper. One would obviously be more qualified than the other but both use the job title 'architect'. So we could apply the same logic to software. Someone who designs the software could be called the architect, regardless of complexity. But I agree that the weight of the title implies level of intelligence, experience, and skill. |
| Fri 24 May | Greg Shoom | I agree with NathanJ that clear writing is important for communication on a project. However, the ability to write clearly is a skill that takes time and effort to acquire. If you want someone to improve his writing, you'll need to convince him that there is a problem, and that it is worth his time to correct it. It is possible that he is capable of writing more clearly than he does, but that he can't afford the time needed to edit what he has written. Editing is a time-consuming task, so he might be stopping once the text says what he means, even if it could be clearer. In this case, you'd need to convince him that it is worth his time to edit his writing more. Alternatively, you could volunteer to edit his writing for him. He might be open to this, especially if it frees up more of his time to do other work. Whether or not this is worth addressing depends on the context. If he is touchy about it, and if his writing is good enough that you can figure out what he means, it might be best to just live with it. |
| Fri 24 May | Nat Ersoz | Wow, 20K classes, that is pretty awesome. I can imagine that it takes a group of people to organize that sort of size. I can surely understand maintaining a central focus for this sort of project. |
| Fri 24 May | Hugh Wells | NathanJ, my short advice to you is not to worry about it. You are fortunate to be a better writer and communicator than the architect. You won't get him or her to change, and he or she won't be able to quickly either. Writing skill requires talent and training. Pointing out the flaws will just get him or her offside. In a few years you will probably be doing better than the architect. The ability to clearly perceive and communicate issues is extremely powerful. Amuse yourself by analysing his or her mistakes, but keep it to yourself. |
| Fri 24 May | Hugh Wells | Also, try to find the things the architect does well and focus on those. No sense resenting someone over something like this. |
| Sat 25 May | Mark Brittingham | I'd like to second Hugh Wells' comments. As long as your architect's writing communicates the essential ideas (albeit in a wordy fashion) it is better to focus on how you can improve rather than on how he can improve. If you were this person's mentor or manager, then it would make sense to approach him. But as a junior member of the staff, my best advice to you is to look, listen and learn so that someday, when you are the architect, you will be criticized for something else entirely! ;-) |
| What on earth does a unit test do? | Tue 21 May | Graeme Henderson |
| Ive only recently looked at XP in any depth and I feel that I must be incredibly stupid - I simply dont understand it! I studied electronics and computer science in the late seventies, since when Ive mainly worked as a mathematician/statistician in the telecoms world. I write a lot of code (these days largely VB, VBA and the occasional bout of C) and I have a fair number of regular users but Ive never followed any particular methodology. As in, I very rarely plan anything, just get stuck into the code. Ive downloaded the test framework for VB and - well, Im buggered if I can understand what the hell is going on. I mean what exactly_is_a unit test?? Ive spent (wasted?) hours of work time reading the XP sites and trying to get my head round it. Am I simply too old? Or am I in fact just very stupid? |
| Tue 21 May | Adam | A unit test is a way to ensure that your code does what you want it to do. If you have a function that calculates insterest, you write a unit test that provides the input for the funcrtion, and checks that the interest calculated is correct for a known value. You do this informally when you setp through code or when you run your program and check that it does the right thing on the screen The advantage here is that the thing you checked for last week gets checked when you run your unit test this week. You don't have to remeber to do it. |
| Tue 21 May | Nat Ersoz | Assumption: A developer tests code against a preceived set of criteria before declaring the work to be 'done'. So, the code written around the developed code constitues the unit test. Sometimes (often) the code cannot be tested alone and may be dependent on an external environment: properly initialized hardware, a running server supporting the proper interfaces, or other software within the system being up and running. A developer will often check in code to source control which does not pass all the unit tests, especially in the early stages of a project, because other developers will be satisfied with working with a partially working interface rather than no interface at all. (Checking into source control does not constitute being 'done', but let's not get tied up with that right now). OK, so that seems pretty rational... Now make the assumption that the proper test criteria are pre-established and accurate. In other words, at some design meeting everyone agreed what the interface looked like, how it behaved (threading model, blocking calls, exceptions, etc.) and that the problem was sufficiently bounded that a unit test could be written to validate the code for all conditions. Obviously, this is not always possible, but assume for this instance it is. So, what is frustrating is when a developer says something is 'done' when it hasn't been run through a reasonable unit test. How many times have you heard the phrase 'it works over here' as though that is supposed to validate bug free code? AARGH. So what unit testing is intended to guarantee is that it will run under all circumstances in all anticipated environments. The only mystery then is anticipating all possible inputs or variations in the system (and they are legion). One more reason why minimalist code is always best. For every conditional statement you introduce a necessary test case. I could rant for days on this... |
| Tue 21 May | Marc LaFleur | Nat, I take it you've had problems with this before? ;) |
| Tue 21 May | Amir Kolsky | I would highly recommend using Unit Tests in any programming language... Languages with introspection capabilities such as Java are easier to manipulate with Unit tests but even language like C++ have them. Unit tests and unit test frameworks like JUnit (or XUnit in general) allow you to develop code 'test first'. In a nutshell the idea is to get the functionality of the code working first and then worry about how it looks. This means: 1. Write tests 2. Write the code to get the tests to work. 3. Repeat 1-2 ad nauseum. (at this point the code is, well, disguting) 4. Refactor the code - i.e. make it look nice. But wait, if you make it look nice, move pieces of code around and various other beautification processes, you are SURE to introduce bugs, right? Yes... But guess what, you already have the FULL test suite to notify you of the bugs... You wrote them first, remember? So, it's an easy job to get the test to run AGAIN... Now, you have the tests, the nice *working* code, and now all you need is to... Eh, nothing actually... Another important use for unit test, which is often overlooked is as a way of formalizaing invariants in interfaces (or pure virtual class a-la c++). When you specifiy the interface you usually only specify the methods' signatures. If you also provide a 'Test Suite' (the XUnit name for a bunch of 'Test Case's (The XUnit name for a test testing one aspect of something))... Anyway, if you also provide a test suite, you can formalize other aspects of your interface's invariants. In this case, an implementor would not only need to adhere to the interface's signature, but would also need to pass the tests... This means that he would adhere to a lot of the semantics of the interface, as captured by the test suite. The test suite also constitute a very concise form of documentation of the stuff tested. This could, for example, resolve question like 'Does 'empty' mean Null or does it mean 'containing the empty element'?' Well.... Just look at the test... One last comment, it is often the case that the test cases themselves are buggy. Moreover, during the course of devleoping a class, component or function which is tested by a suite of test cases, the test cases themselves may become obsolete, test useless things (and hence be removed) or even be refactored to be more efficient... Hence, both sides of the testing equation - the tests and what they test are subject to change as time goes on... |
| Tue 21 May | Amir Kolsky | http:\\www.junit.org |
| Wed 22 May | Nat Ersoz | Marc, I have issues. Lots of issues... |
| Wed 22 May | Ged Byrne | Graeme, From your email address I guess your from the UK, so you've probably been to IKEA. For the rest, IKEA is a furniture store. At IKEA they have demonstrations of their testing. For example, their will be a sofa, and a mechanical device that basically pushes a bottom shaped piece of wood into the sofa over and over again. They are demonstrating their quality control. The mechanical device is simulating the effect of people parking their bottoms onto the seat over and over again, day in day out. A unit test is like one of those machines. Is is basically a contrived piece of code that can very quickly test your piece of code (or unit) to make sure it is up to scratch. The test unit framework is just to help you develop the unit tests in a standard way. |
| Wed 22 May | Brent P. Newhall | FWIW, unit tests don't have to be complicated. They can be implemented informally on projects of any size. I recently begun implementing unit tests on a small development project of my own. I have a checklist of features to test. Each feature has a set of tests to perform, which looks something like this: *** Settings *** 1. Open Settings window. 2. Change a text-based setting. 3. Click 'Save & Close' to close the window. 4. Open the Settings window again. 5. Verify that the text-based setting was changed. 6. Click the 'Show console window' checkbox, making it checked. 7. Save changes and close the window. 8. Close the application. 9. Run the application again. 10. Verify that the console window is displayed. Once I feel I'm ready to release my application to the world, I run through all these tests, verifying that the basic functionality works. This could be done in any environment, even at work when you're just updating a feature. Write a quick list of steps that will verify that the feature will work, and run through them before checking in your code. |
| Wed 22 May | Mark Pilgrim | I wrote a chapter on unit testing in Python: http://diveintopython.org/roman_divein.html . Actually, very little of it is Python-specific, and the Python code involved should be easy to read. The chapter steps through the process of designing and implementing a library to convert integers to and from Roman numerals. Start by defining your requirements, then write your test cases, then write your code, then refactor your code with various optimizations and make sure all your unit tests still pass. I have found this last part (refactoring with confidence) especially useful in the real world. As others have said already, test suites can define your interface at a semantic level. Not only should a test suite test a variety of known good inputs, but it should test as many bad inputs as possible. There is no way to express negative numbers as Roman numerals; if I try to convert a negative number to the toRoman() function, what happens? Also, internal consistency: toRoman() and fromRoman() are mirrors of each other, so fromRoman(toRoman(n)) should equal n for all values of n in the acceptable range. And so forth. One last note: several 'Extreme Programming' gurus have contacted me to inform me that the chapter has a fatal XP flaw (BigDesignUpFront -- I write too many test cases before writing any code). To which I say: you can use unit testing without accepting every other rule of XP. You can write unit tests after the code is written (for instance, in response to a bug report -- the most likely scenario). You can write lots of unit tests up front. You can write unit tests in lieu of design specifications altogether. Do whatever works for you. |
| Wed 22 May | Joe AA. | Mark... if I remember my reading of XP correctly, then it encourages you to do exactly what you advocate - meaing adjust the specific portions of the methodology intellegently to meet 'your' specific situation. I take it the term 'guru' should be interpreted as someone that still has faith in the one true and proper path (e.g. there is one and only one correct answer to all questions), and NOT as someone that really has a clue! |
| Wed 22 May | Amir Kolsky | Hear hear! Marc! Adopt what you need, when you need it. Design has several 'levels'... High, Medium and Low. High level design is something that has to be made, otherwise you have chaos. Medium level design is a good thing to think of, it usually has to do with which components you select, which languages etc. Low level design should be done the XP way, i.e., done by coding. Nonetheless, I advocate writing as many tests when you can, this is because if you think of a test, you don't want to lose the thought. |
| Thu 23 May | Amir Kolsky | OK, I was too abstruse in my last comment, and got some questions regarding what the heck I mean: If you are coding a test, and you think of another test (or a bunch of 'em) just code them. You don't have to do 'em one test at a time if you can think of more than one. If you have the semantic definition of an interface and you want to code all tests at once, do so. If you really want to see the green after every test, comment out the test bodies and uncomment 'em one at a time... |
| Thu 23 May | Graeme | Thanks to all of you, especially Mark Pilgrim. When I read through Mark's tutorial it all clicked into place; its the first time I've seen a really clear explanation of the philosophy and _practice_ of XP. I'd developed a mental block somewhere along the way - I think I'd made up my mind that XP was really difficult and ended up not seeing the wood for the trees. (Although in hindsight quite a few of the things I've read make it much more complicated than it needs to be). So, I've written my first test-code-first class and it seems like a natural way to work (although it was a very simple class!). For the first time it made me think properly about the inputs and outputs of my methods rather than just diving in and concentrating on the functionality. Given that I work as an individual rather than as part of a team I don't think the full XP shebang will work for me, but nonetheless I am cautiously converted..... they're only rules, right? As a side-effect, I've never worked with Python before, but such is the excellence of Mark's tutorial I will be doing in future. Thanks again. |
| Thu 23 May | Marshall Harrison | I'm assumnig that the unit tests are actually code so how do you decide where a problem exists? Is the bug in the code or in the test? Should we write a test case to prove that our case test works? I looks like this could go on ad infinitum so where does it end? I'm not trying to be facetious. I agree with testing your code but where is the line drawn? |
| Thu 23 May | Graeme Henderson | I do agree with Marshall - one of the reasons I ended up banging my head on the desk over XP was looking at the test code that tests the test code in VBUnit. Talk about circular referencing my brain! I've gone for a simple, single test suite for the class I'm writing and that seems far enough to go for me. Its only useful as long as its useful........ |
| Thu 23 May | Ian Stallings | Marshall, you draw the line at a reasonable point where you feel you have tested as much as possible within reason. Say we have method a that returns a string containing 'hello world'. We simply test that the method returns that string, nothing more. If the test is written correctly then your code should pass when it is finished. It's very simple and it doesn't take a brain surgeon to write unit tests. I tend to write unit tests for my core classes and every method/property I can test within reason. For instance, I am writing a mail application. Now I can test that an attachment is saved properly to the hdd by testing it's size vs. what the size was when it was attached. But to write a test that made sure the base64 encoding of the attachment is working properly might be too much because I would have to write a test that decoded the attachment and tested the output, making sure it exactly matched the original in every aspect. This might be a little overboard because if a binary file is encoded improperly it simply won't open/run properly. Some things have to be left to manual testing. I say automate as much as you possibly can within reason. I write suites of tests so I can run them all in one build. I don't write tests for my tests. The idea is to eliminate the chance of a bug in an automated way. |
| Thu 23 May | Marshall Harrison | Thanks Ian, When writing the tests, are they written in the same language as the program you are testing or is there a tool with it's own testing script for testing the code? I'm all for the idea of unit testing but I'm just not sure how to do it cheaply and easily. I don't want to end up having to write a major program to test every program I write. There must be some way to simplfy things. Also any links would be appreciated. |
| Fri 24 May | Matthew Webber | The other point worth mentionng about *unit* tests is that by definition they test individual *units* ie small parts of the system; a single subroutine, function, interface or whatever. This is in distinction to testing your entire application; ie the thing you get when you glue all those units together. |
| Fri 24 May | Ian Stallings | Marshall, Yes the unit tests are usually written in the same language. For instance when I code in java I use Junit as a framework to write and run my tests. When I code in C# I use the NUnit testing framework (the two are virtually the same). The unti tests are small classes testing what will happen in both good and bad situations. IE what will happen when we pass in a param that is expected vs. what will happen when we pass in a param that is null, etc. When the test is passed it's no guarantee that you won't encounter bugs, it just lowers the chance of a bug appearing, saving you time in the long run. I cannot stress how useful it can be when you are refactoring or adding additional features. Knowing you haven't broken something gives value to these types of tests. The learning curve for unit testing is pretty low and the payoff is big. |
| Fri 24 May | Marshall Harrison | Thanks Ian. Sory to sound dense on this but I do have one last question. From the examples I've seen on the Internt I'm wondering how it is actually implmented: 1. is the test written right into the code of your program? or 2. Are the routines to be tested cut and pasted into a new code in the test unit? Either way it looks like it could cause problems - the first could make your executable bigger (for languages that cant ifdef the code out) and the second could create cut and paste issues that hide or cause other bugs. Thanks. |
| Sat 25 May | Ian Stallings | On my current project our unit tests are placed into a seperate package/namespace that is not distributed with the release build. For instance, when using C#, I create a .test namespace that I compile to a debug build. When we release a build to the public we do a seperate build without the unit tests. That's just the method I use now developing shrinkwrapped software components. I have done Java projects in the past where we also gave the client the unit tests for future developers to reference. It depends on your circumstances and target consumer of the software. |
| Sat 25 May | Marshall Harrison | Ian, Thanks for all of your help. |
| Conflicting advice - what to do? | Fri 24 May | gary |
| I have just been noodling around on the xprogramming.com website, since we will be using xp to some extent on future projects. I knew there was something that bothered me about You’re NOT gonna need it! (http://www.xprogramming.com/Practices/PracNotNeed.html) but it took a few seconds to realise what it was. [quote] Often you will be building some class and you’ll hear yourself saying We’re going to need.... Resist that impulse, every time. Always implement things when you actually need them, never when you just foresee that you need them [/quote] Compare this to http://www.parashift.com/c++-faq-lite/coding-standards.html#faq-26.9 Specifically: [quote] A class with any of {destructor, assignment operator, copy constructor} generally needs all 3 [/quote] I think many people do not follow the above rule, which fits quite nicely with the xp practice described before but can get you into big trouble. The rule exists at least partly because copy ctors can easily be called implicitly, and it is easy to miss those points where it happens, because the compiler goes behind your back and generates a copy ctor if you do not provide one. You can, of course, just declare the methods concerned without defining them (link errors if the methods are ever called), but then quite possibly someone else, who should not even care about the implementation of your class, is going to have to write those methods because you did not (after all, they were not needed at that time...). Is it in this case better to write some redundant code if you think Were going to need... a copy ctor (but we dont need it yet)? Are there other instances where this, or other, xp practices go against best practice for xyz language? Cheers, |
| Fri 24 May | Joe AA. | Personally I think your answer is in your faq link. E.G.:'Yes, there are some practices which are generally considered dangerous. However none of these are universally 'bad,' since situations arise when even the worst of these is needed' There is no one size fits all for all situations - there is no 'best practice' outside of context. XP wants to encourage the practice (to paraphrase) 'do no work before its time'. Given a choice, I would follow the XP guideline... for no other reason than the one you gave. p.s. I also don't litter my C++ with 'const' either. |
| Fri 24 May | Jutta Jordans | Gary, I really don't think that your example is one of the things Kent Beck meant when he said not to plan in things you don't need yet. If you have a destructor, you need a copy constructor and an assignement operator! It is not 'you might need it in future' It is just not save to have one without the other. This is more a language specific detail of C++ than something connected with your project design. This makes it explicitly different from problems like 'I have one document type now and maybe I want another one in the future, so should I implement a base class now?' To this the XP answer would probably be 'No', because you might well be content with your one document type for all times. And if you are not, what you thought to be a good common ground for a base class might not be any longer once a new document type turns up. Have fun, |
| Fri 24 May | Mark Bessey | I don't actually see a conflict here. XP says 'don't build it until you need it', but that is meant to be interpreted at a feature level, rather than an individual lines of code level, I think. I think the point that is being made in the C++ FAQ Lite is just that {destructor, assignment operator, copy constructor} is really a single feature, not three independent functions. -Mark |
| Fri 24 May | Jim Lyon | The advice isn't really in conflict. Treat the C++ advice as 'if you need one of {destructor, copy constructor, assignment operator} then you must *declare* all three.' It's perfectly reasonable to write private: Foo (const FOO&); without ever providing an implementation. If code outside your class attempts to (inadvertantly) use the copy constructor, it will get a compile-time error. If code inside your class attempts to use it, it will get a link-time error. After you get the compile-time error, then you can follow XP's advice and implement the routine. |
| Why managers cant allow telecommute or PT schedule | Wed 22 May | Bella |
| Is anyone here part of a regular IT staff, but telecommutes in any capacity. (No, logging in after dinner doesnt count!) Im just feel that telecommuting cant really catch on b/c if a manager grants that right to one person, he can expect the remainder of his staff asking for the same thing as soon as word got out. (Dont get me wrong, I think an empty office building is the way we should be heading anyways) What are you experiences? I suppose its different for a contract assignment, where your not part of the long term staff anyways, and have a fixed project. Im more talking about a FT, long term staff member who may want to telecommute in some capacity in a long term sense. The same argument applies to flex time. During the boom, we were getting paid several multiples over our cost of living, and PT work was always in the back of my mind. But of course, as soon as one goes PT, the rest of the staff may request a PT schedule also. I can sympathize with not setting a precdent. |
| Wed 22 May | Hugh Wells | I know of a few product development teams that work in a telecommute-type fashion. In fact, they were deliberately set up that way. They consist of high quality developers who love what they do, combined with development-experienced managers. There are some distinct requirements for the management. They need to be able to explain and parcel out work well, and to trust people. |
| Wed 22 May | Jeb | I worked in a virtual office setup for a while. The company was small (4 people) and we had one product. It wasn't a maintanance shop. We had a source repository and we had our own area of expertise. It was actually very productive. |
| Wed 22 May | pb | Our experience is that having engineering, product, qa, etc. in very close proximity is a significant competitive advantage. |
| Wed 22 May | Troy King | pb, a significant competitive advantage compared to what? Have you tried it the other way or is that just some bs managerial power-trip speak? Everyone in my office has the option to telecommute, and in fact, I have worked strictly out of my home for 18 months, and don't even have a desk at the office any more. I get more done at home than I ever did at the office, but we do have programmers that actually prefer to work at the office because their home environment doesn't let them get much done (very young children, etc.). |
| Thu 23 May | Vincent Marquez | I for one have a perfectly fine home office envoirment, but prefer to work in the office for a number of reasons. Mainly, the ability to run next store and brainstorm on something, ask a question about the big project everyone is collaborating on, or have a peer review some of your code is invaluable. Also, because i'm surrounded by collegeues, I am definatly more motivated to work faster and better. I have done some of my best coding at home, but usually its when i'm inspired late at night and/or I just want to code it right away. I feel like I can transition better when I have somewhere to 'go' everyday: when I get to work, i'm in 'work' mode, and when I leave, I leave 'work' mode. Since i'm the type of guy that has code floating around in his head 24-7, not being at the office lets me focus on other aspects of my life. |
| Thu 23 May | Sammy | I work flextime, with 'office days.' It works fine for me. My particular pathology is that I love freedom, and working on a laptop machine is quiet heaven for me. This mainly precipitated because I had a team member that wouldn't leave me alone. A wonderful, nice man, but I couldn't get anything done and he'd keep on pushing me to optimize early and other productivity-killing things. It was a great thing though, since I started coming in even odder hours until people asked me just to take flextime. Mainly one important thing is to be good about the bugs. When you write buggy code, people want you to be in the room so they can show you their pain. So high-level design is useful, with care about null values & such. Hard to know the pain of laptops before buying though. I just bought a Sony I kinda like, though it's really a consumer appliance. Nuked usb + touchpad support with sleepmode. I once had a Dell inspiron that was great. If you hire professionals with soul, you can trust them to do things for the sake of the product. And their mistakes will be caught early and dealt with. |
| Thu 23 May | Bella | Has anyone been denied telecommute or flextime due to my original 'domino effect' hypothesis ? |
| Thu 23 May | Nope | bella - i was denied telecommuting on the basis that some of the libraries that we needed to do the development could not be taken out of the building (which was a fair point, the company signed an agreement that said that so they were bound by it, but i do not think that it was an insurmountable obstacle, since the libraries only existed on the target platform anyway, and we developed mostly on pcs in a simulation environment). i did get the impression though that at the root of it was the fact that it was a sh*tty office that everyone would have preferred to be somewhere (anywhere!) else, so they would have had a bunch of managers sitting around with nobody to manage*. anyway, unable to get out of the office one way, i chose another and quit. i don't think telecommuting is an impossible situation to manage, but it does make a manager's life a bit more difficult i guess. personally i think it is worth one person having a more difficult life if their entire team can have an easier (and more productive) one. * it would then have been quite clear who was doing the work... |
| Thu 23 May | Brent P. Newhall | I've had some interesting experience with this. My first real tech job, besides an internship at a large company, was as the webmaster for a business website. I telecommuted for months there until they got a regular office (my job requirements changed and the office was close, so I worked at the office most of the time). That worked very well. I found I was more productive at home, with my own tools, than I was at the office with an unfamiliar PC. When I applied at my current company, they said that they'd provide for telecommuting. This was later denied, ostensibly because of technical reasons, but I suspect it was partly because of an 'If we allow one person, everyone will' mentality. Today, I'm contracting for the same company, and I work an average of four days a week. I asked for something like this earlier, at a reduced salary commensurate with my hours, but it was disallowed, again because of the 'If we allow one person' rule. To get back to the original question, I've found that I get more work done in one day at home than I do at work. However, I'm sure that this productivity gain is dependent on the work involved. As the single webmaster with total control over a website, or a technical writer, telecommuting has obvious advantages. There's comparatively little communication needed. Other jobs may or may not see similar productivity gains. |
| Thu 23 May | mackinac | At a past employer a few employees did telecommuting for a time. In one or two cases the arrangement was at the request of management. The employee had decided to leave the area but the project manager wanted the developer to continue on the project. The long distance telecommuters eventually gave it up. Meetings were still necessary and that meant a long trip. At past and current employers a few individuals have part time or odd hour work arrangements. In no case has there been any domino effect. The employer that allowed (or requested) telecommuting had a decent office environment. And most people seem fairly content with the standard 40 hour week. In my current position the commute and office environment are bad enough that partial telecommuting would be nice, but some lab work with specialized equipment is required, so it couldn't be full time. Current network restrictions make even parttime telecommuting impossible. |
| Thu 23 May | TonyD | My experience is a little different - my manager telecommutes. He's actually a senior developer who moved out of the area, but the company needed his expertise & kept him on-board. His time is split between working code & managing the rest of the team, so he spends lots of time on the phone, but he's at least as effective as any other manager I've had. We see him about once a month when he travels back into town. As for the rest of us, we work in the office, but I personally find it much more convenient that way. (We have one other developer who moved out of state and works remotely. It's kind of nice to think that if I have to move out of the area, I could still keep my job.) |
| Thu 23 May | Dave Warner | I've had the pleasure of telecommuting for the past 2.5 years, providing development and support for an in-house manufacturing application. My co-workers are in Maryland, and I'm in Northern Arizona (my choice). I worked for one year on site and then moved out here to a rural community. Everyone is very satisfied with the arrangement. I work as both project lead and lead developer and haven't had any problems. There have been two trips back to the office since I started telecommuting - neither of them were necessary nor very productive. One other member of the group is moving towards full time telecommuting, while others are working at home when it is convenient. One tool that has made my life easy - Terminal Services Client. I log in via a 56K dial-up over a VPN and can do coding and drag-and-drop gui design via TSC. My boss recently asked me if I wanted a high-speed connection and I said it just wasn't necessary (It would be nice, but, politically, I like to be a low-cost item on the balance sheet). The key aspect in my arrangement is trust all 'round. Having worked with the team for a year on site made it easy to keep relationships strong, even over a long distance. |
| Fri 24 May | anon | Bella, My situation is the exact reverse of the one you are proposing. We have an office of a dozen people, programmers and testers only. All the programmers work in one big room with private confrence rooms. Our manager telecommutes from his home in another state. We communicate with him by email and phone. He and some others in the company fly in every few weeks to speak with us face to face. Your proposal presupposes that everyone wants to work from home, and that a manager could not function being seperated from all his (her) workers. |
| Fri 24 May | pb | Well...a competitive advantage is an advantage over competitors. I don't manage I'm afraid to say...just reporting my observations. Our programmers don't have the home issues you suggest as they are practically 'very young children' themselves. I will say, that the one thing that may finally make telecommuting doable is instant messaging. |
| Fri 24 May | MH | I think the domino effect is in the back of everyone's mind in these cases, even if it's not given as a reason to deny telecommuting. One thing that needs to be clear for a manager is that she can rely on a programmer to take this decision in the best interests of the product. Even if the reason is something like, 'It'll boost my morale and productivity, with no ill effects on development.' Even better is if you can set everything up so it has minimal impact. Take care of the VPN; consider a webcam. It also depends on you being very good. Under the domino effect is the assumption that people must be treated the same. But in a team of individuals, fairness is not the same as sameness. If you can, through technical skill, make yourself indispensable enough to get concessions for the sake of morale and the product, bully for you. TELECOMMUTING IS NOT FOR EVERY TEAM. If offices were in a beautiful university building, with members of the preferred gender roaming around the grounds and the team composed of people who are deep with each other, telecommuting would be largely unwanted. |
| Fri 24 May | Nope | a webcam? does your manager really want to see his staff writing code in their underwear? i think not! |
| Software Metrics and Programmer Productivity | Wed 22 May | Nitin Bhide |
| My company has recently experimenting about using software metrics to measure/compare productivity of programmers and use it as performance appraisal tool. This is being implemented on experimental basis in some project groups. Currently main metric being used is no of bugs/KLOC, etc. Personally, I think its a bad idea to use the software metrics like bugs/KLOC to measure programmer performance. Most of the measures actually promote bad programming practices. For example, one good way to reduce the bugs/KLOC count is to do lot of cut/paste code. This will increase the KLOC count and hence reduce the bug/KLOC. So a good programmer who opts for code reuse (using function calls) and refactoring is actually get a lower performance rating than a bad programmer doing cut/paste code. Is your company also uses the Similar metrics to measure programmer performance ? I am interested in hearing any feedback, experiences, etc. |
| Wed 22 May | Matthew Lock | KLOC's must be the worst possible way to measure productivity ever thought of. Would you measure a chef on the volume of spagetti used per day? |
| Wed 22 May | Jarno Virtanen | If you really want to know what you're dealing with, go and buy and read the Fenton & Pfleeger book _Software metrics: a rigorous & practical approach_. This book's not all there is to productivity, but it gives a nice overview of measurement theory and measurement in practice (in software development). There is almost 60 pages of references in the annotated bibliography too. In my opinion it gives a nice and solid basis for further studies on this subject. Programmer productivity is just one of the things that are _not_ easy measure. There's definitely some relation with productivity and lines of code, but it's far from direct ... |
| Wed 22 May | Brad Wilson | As others have written far more eloquently before me, the best programmer is generally the one who takes the most code away, not the one who adds the most code. A measure of when a product is stabilizing is when it 'turns the hump' from growing to shrinking code size. |
| Wed 22 May | Bill Carlson | Brad hit the nail on the head. The best developers I know spend the bulk of their time analyzing the problem, and a small portion cranking out compact, clean code. The other problem with metrics, perhaps just as significant, is that varying projects have wildly differing levels of difficulty. If my colleague spends two weeks writing a reusable, documented thread pooling class, and I spend two weeks dropping controls on forms, he may end up with 200 lines of code, and 5 bugs, I may end up with 2000 lines of code and no bugs. Really, he's the hero and I'm average. But how will metrics explain this? I had a temp job in my teen years assembling computer cables. The best workers got assigned the complex cables with more wires. Consistently, these workers were layed off because their cables/day ratio was near the bottom percentile. I left, but heard that they revamped their system later. This was a bad example of metrics in action. Again, the best developers solve problems by mentally refactoring code until it is simple and compact, often using 3rd party tools and libraries whenever possible, decreasing LOC, but increasing productivity and reliability. Code costs money, with (often) only a small portion coming up front. Those that advocate metrics have their heart in the right place. But, just like Mark Twain can say in 10 words, what others may write volumes about, code is similar. |
| Wed 22 May | skautsch | Using metrics as a performance appraisal tool is probably the dumbest idea I've heard in years. It's *such* a bad idea that organizations that take metrics seriously frequently not only forbid the use of the metrics in appraisals, but make doing so an actionable offense. I'm at work and don't have access to my home library (and so can't give any titles), but the literature is full of books on successful metrics programs. Most of them stress not to do this. |
| Wed 22 May | James Montebello | One fact frequently overlooked is that productivity is usually measured in dollars (or euros, or whatever) per capita. If Group A has 10 people and generates $100K in quarterly profits, and Group B has 100 people and generates $100K in profits, there's a direct measure. If a quarter is too short (long term projects), then use an annual measure. Using such measures also gets the programmers more involved in the actual marketing and sales aspect of the business, which is only a good thing in my view. Engineers that refuse to understand marketing and view marketing as the enemy have no place in a commercial software operation, IMHO. And yes, marketeers who refuse to understand engineering realities are equally useless. The key here is not attempting to measure individual performance (which is simply impossible to do reliably) and not using short timescales, which don't accurately represent actual effort (everyone has non-productive days). Measures like KLOC are obviously silly, and hours worked is equally useless, since studies have shown a high variability in actual ability between programmers, which a lesser programmer may compensate for by working longer hours. If a guy can play Quake III online for seven hours a day and generate enough code in that last hour for the company to reach its revenue goals, who am I to complain? Whereas I'd be equally happy with a guy that has to sweat for 10 hours every day to do the same job (equally, as in I wouldn't pay him any more than the first guy). Measure useful output, not work. KLOC is work. Profits are useful output. Finally, if an individual programmer is less productive than their peers, it tends to be pretty obvious to everyone else in the group, and certainly should be to the manager (constant schedule slip at the same workload, or a far smaller workload to avoid schedule slip). If all the programmers in a group 'aren't productive enough', it's management's fault, not the developers, and that should be pretty obvious to management, or there's little hope for the company. |
| Wed 22 May | Joe AA. | 'If all the programmers in a group 'aren't productive enough', it's management's fault, not the developers' James... I am a little uneasy with this. Don't you think that by having an easily available scapegoat (such as management) available it will encourage 'aren't productive enough' behavior? The most productive groups I have work in, were with programmers that did not blame anyone but themselves for their own productivity. And the measure was effect on profit as you point out... not an unrelated substitute of something that couldn't correlate. |
| Wed 22 May | Philip Rieck | A good developer will know when to blame management, when to blame his peers, and when to blame himself or whatever the actual cause is.. So when he blames management, you should probably believe him. A poor developer will always blame management, or his peers. So you don't know when to believe him. However, hiring poor developers is a sign of poor management.. This means that if your development staff says that productivity is poor due to management, chances are that the managers are not allowing the staff to reach full productivity through some action (or inaction). This doesn't mean poor management, as they may be balancing many things, but the management structure in place should know of the issue, and not randomly fire developers, or randomly institute meaningless metrics. |
| Wed 22 May | X. J. Scott | > My company has recently experimenting about using software metrics to measure Excellent! > /compare productivity of programmers Uh oh. > and use it as performance appraisal tool. Oh dear. >Currently main metric being used is 'no of bugs/KLOC', etc. Oops. Bad. > Personally, I think its a bad idea to use the software metrics like bugs/KLOC to measure programmer performance. Most of the measures actually promote bad programming practices. Metrics should not be used to compare programmer performance. Metrics should be used to make an intelligent estimate off how long it will take to create a new system, given a set of baselined performers. Never use LOC first of all. Use function points at least, which are decorrelated from language choice and programming style. For a given programmer in a given language in a given problem domain, it is possible to calibrate FP and LOC. I have used the black art of metrics to predict how long it will take me to do something and I have been totally flabergasted to find I can do this pretty accurately. Before I started playing around with fp metrics, I hadn't the foggiest clue how long something would take and believed it was impossible to even hazard a remote guess because I was 'an inventor' and 'this has never been done before.' I was wrong to think that that meant an accurate estimate was not possible. Metrics are great but ithey can be easily misused if an ignorant company starts abusing them by doing stupid stuff like using them to measure programmers instead of what they are intended for and helpful at -- prediction. Metrics are fun fun fun when used responsibly! It is a *blast* to predict something and get it spot dead on. |
| Thu 23 May | Hugh Wells | One of the big consulting firms was asked to assess a big computer company's support centre. They ranked all the support staff by the time taken to respond to problems, and then sacked those who took the longest. Then disaster struck. It turned out there had been an informal culture in the support centre where the hardest calls were routed to the best engineers, who naturally took longer on their calls. When those guys went, the support centre's capability plunged. Cap in hand, the dumb company tried to hire their guys back, but their spell in the market had shown them they were worth much more than they had previously been paid, and most stayed with their new companies. As you would. |
| Thu 23 May | Adrian Gilby | Okay, I don't want to turn this into a troll, but the post above raises a point I've occasionally wondered about. Specifically, you hear plenty of stories about (the) big consulting firms completely screwing things up and costing their clients big bucks in the process. The post above is a perfect example of this -- they went in, didn't take sufficient notice of the environment, implemented changes indicative of remarkable lack of foresight, with devastating consequences. So why do the consulting companies continue to get hired? Do the consultants generally do a very good job, it's just that only the horror stories get passed around the net? Note, I'm not asking 'why do people hire consultants', I'm asking 'given the horror stories about consulting company X, why does it stay in business?' Adrian |
| Thu 23 May | Tony | I remember being part of a metrics programme in 1991, a complete and utter waste of time, quickly forgotten and never applied. Great for the consulting company that ran the programme, but of no benefit to anybody else. The wheel, obviously, still turns. |
| Thu 23 May | Jarno Virtanen | X.J. Scott wrote: 'Metrics are fun fun fun when used responsibly! It is a *blast* to predict something and get it spot dead on.' I'm kinda nit-picking here so my apologies in advance, but if you make a perfect estimation (median of the propability distribution) and base the project time target on this, there's 50% chance that the project is late. (I'd guess this could be called trivia ..) |
| Thu 23 May | Nope | >Measure useful output, not work. agree. 100%. any other measurement is useless. i think we have discussed this before. >KLOC is work. Profits are useful output. sorry but i have to disagree with the last part of that statement. in organisations where profit is not the objective (emergency services and health services are a good example in civilised countries :-) how can you measure profit (should you? how much is a life worth?)? measuring how much profit an individual contributes is also an incredibly hard thing to do - if i fsck off early every day have i contributed equally to the success of the project i am on? if i am producing my fair share then yes, by your own criteria, but how the hell are you going to know that i'm not just being lazy? if you ask my colleagues they can probably tell you, but you rely on them being truthful - if they don't like me for some reason, i can be 'marked down', and vice versa, similarly there will always be one who reckons he did everything (he did, he produced more bugs than anyone else) and nobody else should get the credit (you know the type, the ones your boss makes into team leaders). which leaves you with, as you said, 'not attempting to measure individual performance'. so you presumably have to pay everyone the same, muppets and superstars alike. this is a good way of ending up with only muppets, imo. your idea also means that regardless of the development team getting the thing out of the door you rely on it being marketable to judge whether they are successful. in one sense i can see the point (otherwise you just end up with the company going bust), but if the idea is unmarketable i can still have done my job well, regardless of whether the product is profitable or not. i am not even going to start the argument about whether profit (which is just surplus cash given to people who have probably never put anything into the company in the first place) is useful or not. sorry, but i think the measurement has to take place before 'profit' even comes into the equation (no, i don't know where or how, sorry!). |
| Thu 23 May | Ori Berger | |
| Thu 23 May | Simon Lucy | I've never understood KLOC, I try and write the minimum amount of code to achieve something. I don't see the point of writing the C++ (or god help me Perl), equivalent of War and Peace to process data. Most of my time I spend thinking and looking at other people's code wondering how I can steal it or make use of it most effectively. |
| Thu 23 May | James Montebello | '>KLOC is work. Profits are useful output. sorry but i have to disagree with the last part of that statement. in organisations where profit is not the objective (emergency services and health services are a good example in civilised countries :-) how can you measure profit (should you? how much is a life worth?)? measuring how much profit an individual contributes is also an incredibly hard thing to do -' Profit was only given as one useful measure, and since the vast majority of software houses are for-profit, it's likely the most generally applicable. I already stated that measuring an individual's effect is nearly impossible, not just difficult, and shouldn't be attempted. At the end of the day, it doesn't matter how efficiently a group of developers can crank out code if the code doesn't produce anything worthwhile. Code is a means, not an end. However, if marketing does manage to provide a specification for a completely unmarketable product, and engineering produces a product meeting the specification in the agreed upon timeframe, there's another measure of output, even applicable to non-profits. It's strictly a 'good enough' or 'not good enough' measure, but that's about the best you can do. |
| Thu 23 May | Joe AA. | Even altruistic organizations won't exist long without profit. Pretending that something called a donation ain't income would be self-deceptive. I would hope that efficient operations is important to these organizations - as opposed to justifying a waste of resources with the unanswered question of the worth of a life. Which by the way, has nothing to do with a profit measure. Of course, cranking out code is never the ultimate goal. I believe it was Weinberg that suggested our worth be measured by the productivity improvements our 'product' provides to those that use it. There seems to be a reluctance to measure individual productivity or contribution. I really don't see the 'badness' in doing something like that... however, I do understand you get what you measure, and so you better be darn sure what you measure is exactly what you want. When I have had management positions, I wanted to be sure that any 'bad apples' that decreased the overall team productivity were removed and as quickly as possible. The team definitely 'knows' without any basis in objective measurement exactly who these individuals are. But things like 'voting' or 'peer review' does have limitations. Just watch the so-called 'reality' of survivors, or a game of the weakest link, where the best get eliminated first. |
| Fri 24 May | Nope | >Profit was only given as one useful measure, then perhaps you can explain where in your post you said this, and in future write more clearly. >and since the vast majority of software houses are for-profit, it's likely the most generally applicable. we are not discussing software houses, we are discussing software development >I already stated that measuring an individual's effect is nearly impossible, not just difficult, and shouldn't be attempted. as i quote in my post: 'which leaves you with, as you said, 'not attempting to measure individual performance'. ' >At the end of the day, it doesn't matter how efficiently a group of developers can crank out code if the code doesn't produce anything worthwhile. define worthwhile. worthwhile != profit. |
| Fri 24 May | Hugh Wells | Adrian, I guess big consulting firms generally do reasonably good work, albeit with incredibly stupid work sometimes. Other factors are that they're external to the organisation and thus are supposed to give 'objective' assessments. Also, they're often used to justify decisions that have already been made by the MD or the board. But, yeh, sometimes they are really dumb. I have other stories too. |
| Fri 24 May | Joe AA. | Sometimes Hugh? How about a story when they weren't really dumb... didn't define objective as whatever promotes their own crappy products, didn't cost more than they produced, really helped the company that hired them... etc. Maybe I ask for too much. |
| Fri 24 May | Hugh Wells | Joe AA, I must admit I would be scratching my head severely if we were talking about IT consulting firms. My generous comments were actually directed to management consulting firms. |
| Aircraft falling from the sky ... | Tue 21 May | Hugh Wells |
| This is a contination of the discussion about certification that started in the thread: too critical of MS with comments by sick and Johnny Simpson. First, its news to me that software engineering is not regarded as a profession. Second, the comparisons with other professions are not valid because most professions work with well-known tasks and constrained environments, whereas software design involves the perception and resolution of complexity, which is an unbounded task. For example, civil engineers know exactly how long their bridge must be, how much weight it must bear, what load the bedrock will bear, and so on. These specifications will not change once design or building has started. Accountants add up figures and charge for it. If software engineers charged at the same expertise * time multiple, we would charge about $10,000 per hour. |
| Tue 21 May | Hugh Wells | Certification is a dumb idea for software engineers for the following reasons. The ACM formally opposes certification too. See http://www.acm.org/serving/se_policy/selep_main.html#executive_summary Reasons are: 1. Software development evolves much faster than formalised procedures for deciding minimum standards of knowledge. Look at how long uni courses lag behind industry trends, for example. If we had certification in the 1990's, we would probably still be using character mode screens and Cobol, since that would be the accepted and certified practice. See http://www.acm.org/serving/se_policy/bok_assessment.pdf 2. Doctors, lawyers and accountants are certified at least partly to protect members of the public in direct dealings. But software developers do not deal directly with the public; we operate through groupings that provide peer and market assessment. 3. The biggie is that airplanes will fall out of the sky because engineers aren't certified. Well, safety critical systems are subject to far more rigorous controls than certification of developers. In fact, any manufacturer that relied on developer certification would be criminally negligent. So developer certification is irrelevant for one of the big claimed requirements. 4. It's really managers that need to be certified: most problems in software relate to management of projects, including who gets hired and how much time and resources are provided. |
| Tue 21 May | Nick Hebb | Hugh, I gotta agree with you. First, Software Engineering is a profession and is _regarded_ as a profession. Sounds like someone’s got a self-esteem problem. Second, Civil Engineering and most other forms of engineering are piss poor comparisons. Most engineering design work is performed with a set of constraints that are known or can be determined at design time and are often bounded by the laws of physics, mathematics, etc. Many comparisons have been made between software development and architectural design. I think that comparison is valid for the software architecture stage of the development, but not for the implementation stage (coding) of the development. The best engineering analogy for the implementation stage is Manufacturing Engineering. Both are given (often roughly) the specification for the output, but the number of ways to achieve the final output can vary widely. As standard architectures and reusable components are to a Software Engineer, standard processes and equipment are to a Manufacturing Engineer. If it's cutting edge stuff that no one's done before, it's up to you to develop new processes. The number of variables introduced to a product by the processes, equipment, raw materials, and operators/assemblers is very difficult (time & money) to predict. For high-mix, low-volume production operations, it’s not uncommon to see first pass yield rates of 80% considered good. The only way to dial in your processes is if the product stays in production for awhile, allowing time to work on them. I could think of a dozen more solid analogies, but frankly I’m too lazy to type them all. So suffice it to say that software’s a lot like mix-mix, low-volume production, but most of the time it doesn’t have the opportunity to “stay in production” for awhile - operating systems and equipment are constantly changing. Maybe went we get to quantum computing things will stabilize, but until then? |
| Wed 22 May | Rodger Donaldson | Actually, the real reason to look askance at notions of certifications by professional bodies is that such bodies tend to function as cartels, and may or may not provide public assurance. It's not that long ago that people routinely practised law on a professional basis without any formal education in law; now, you simply cannot, in most Western nations, act for anyone but yourself without being a member of a Bar association, which proscribes a variety of hoops (tertiary degree, probationary period, members levies). That bad lawyers still happen can be seen (for example) in the number of cases where murder convictions in the United States have been called into question as a result of attorneys who show up drunk, never having spoken to the client, unfamiliar with the material, or a myriad of other causes. Programming has a low barrier to entry, and I see that as a good thing on the whole; plenty of people complain people without a teritary education shouldn't be allowed near professional programming gigs since they are the ones giving the profession a bad rap, but frankly, I wonder. My current client is a bank; if programmers had to belong to a professional body comparable to that for most other professions (which require degrees), the bank might as well wind up and return assets to the owners, since its most effective staff are almost entirely those who have no formal education in programming. Admittedly, I'm biased; I don't have a programming degree, either, FWIW. |
| Wed 22 May | Albert D. Kallal | There have been many attempts to make standards for developers. And, of course Universities and companies like Microsoft do spend a lot of time educating, and certifying people. The universities in general offer courses like computing science, and now most offer several commerce courses with business management and computing as a major. (these are the so called MIS courses). Microsoft has a ton of certification courses. We could very well in the future require some type of certification in order for one to legally produce and write software for the industry. However, these requirements still in general allow people practice in the industry and not be certified. It has happened to the accounting industry. In other words, anyone can startup a booking keeping service, and not be a charted accountant. In fact I have several friends that make a living doing this. However, they are not charted accountants, and thus cannot produce the final books at year end for a registered business. This is for tax purposes of course. They can file, and do taxes for a small “sole proprietorship”, but not for a registered limited company. The exactly same thing goes for Law. There are many legal type firms that will fight traffic tickets, and do general types of law (they will even represent you in court). In many cases these companies are working in the field of law, but do not have any lawyers on staff. A lawyer is only needed for certain types legal proceedings. We may need some more time, as the software industry is still very young. It is only been about 20 years that small business have used computers. Hence, we are dealing with a very young industry. Thus, just like accounting, there are many small bookkeeping companies out there, but they are not registered or certified accountants. The result of this is that they are free to do book keeping services, but for certain types of work, they have to be certified. I suspect the same could very well happen for software. However, it is quite difficult to define exactly what one needs to have to be “certified” to work on certain types of software. Anyone is free to go out a write a book. Anyone is free to go out and start a book keeping service for people. Anyone is free to start writing software. Anyone is free to start making nice coffee tables also. You can also assemble and build your own airplane legally! (you just have to place the word experimental on the side). However, a good company will hire a good experienced carpenter, or perhaps the one that graduated at the top of the local trade school carpenter course. Nothing wrong with that. I mean if you really need someone to write you a new computer language, then it makes sense to get a CS graduate with compiler construction experience. There is already tons of certification going on in the software industry. The real issue is can any regulation be brought upon the industry for certain types of work? It does not look like this is going to happen anytime soon. Without a state laws, then the issue of certification becomes self-regulation. Albert D. Kallal Edmonton, Alberta Canada kallal@msn.com |
| Wed 22 May | Katie Lucas | Simple reply: Look at all the job adverts. Certainly in the UK, all of them say 'Software engineer, knows |
| Wed 22 May | Johnny Simmson | Nice straw man hugh. |
| Wed 22 May | Hugh Wells | I think Katie makes an interesting point. Most expertise-based professions differ from software development in that they almost always exercise control of their professional activity. Thus lawyers work in law firms run by lawyers, accountants work in accounting firms run by accountants, and medicos run the relevant aspects of hospitals. Civil engineers often work in large engineering consultancies run by engineer. By comparison, any fool can be put in charge of software developers. |
| Wed 22 May | Johnny Simmson | I don't think its a self-esteem problem as much as its an elitist syndrome. It comes from being surrounded by people that 'learned vb in 24 hours' and call themselves a software engineer. Or people that wrote a db backed website & call themselves a 'solutions architect'. We need code monkeys, but I hate having to go into a new client & demonstrate the difference a 'real' programmer & a fly-by-night hack. It's been great for my salary though, so I guess I shouldn't have any complaints. |
| Wed 22 May | Hugh Wells | Surely we DON'T need 'code-monkeys?' This gets back to my favorite topic. Good developers don't hire 'code-monkeys,' but clueless managers do. Then they complain about their software. |
| Wed 22 May | Ian Stallings | I think the difference comes from the lack of history the software industry has. It originated (approximately) in the 60's. With 40 years under its belt it's hard to compare it to industries that have been around since the beginning of civilization, such as accounting and civil engineering. Over the generations people realized that if someone wants to design a building for people to live in it must be safe, because negligence in that field could lead to deaths. They have to be held liable. Doctors deal with the same type of liability. Accountants and Lawyers deal with different types of liability but just as important. As the computer pervades more aspects of human life the 'software engineer' will become more lable for his/her actions. Right now people are willing to deal with problems in a relatively new industry. What we are creating now is a profession which might be practiced 300 years from now (albeit quite differently) on a much broader scale, effecting every facet of life. I bet those developers will be held much more accountable because stricter rules will be established by governing bodies outlining what is required of each piece of software (depending on it's use) and who is to be held accountable if something goes wrong (usually determined by the courts). I predict that society will be much less willing to tolerate inperfections if they lead to catstrophic failures. |
| Wed 22 May | Joe AA. | I agree with Hugh and Katie on some of their points, well, to a certain extent.
'Software Engineering' (regardless of the title) is not a profession, and is not practiced as such, at least not in the same sense as lawyers, accountants, doctors, et al. I think part of the reason for that is the point Katie makes about the job advertisements.
In this case part of the 'enemy', besides the fools that get control of a project, management or not... is ourselves. We market ourselves... and even take pride in ourselves and refer to our endless division of responsibility sometimes called 'specialization'... based solely on the specific 'tool' we know how to use.
Certification isn't going to help make software engineering into a real profession, because certification is merely a certification based on the tools. Proper certification would be based on our ability to accomplish *something* without regard for specific tools.
For gosh sakes people... even carpenters are selected based on what needs to be accomplished... and not because they know how to use a cobol hammer, or a java hammer, or a |
| Wed 22 May | down on certs | I agree that the idea of legally requiring software developers to be government regulated is foolish. If/when this happens, what remains of the software development industry will move overseas and anything left will be prohibitively expensive and/or so 'safe' and slowly developed as to be of little use. Any engineers planning for the future need to be planning for their transition to live in a foreign country if this stuff goes down. Has anyone seen what the State of Texas has been up to. If you call yourself a Software Engineer there, you might go to jail if you are not officially recognized by the State. Take a look at their pathetic sample 'certification' exam -- dozens of questions about Texas Statutes of no bearing to quality engineering at all. Better make sure you have someone on staff with a degree from a Texas University as such a degree is nearly necessary in order to pass their silly exam. Texas computer science classes are not the be-all end all of existence to justify this nonsense. Regulate and license software development? Why not do the same for book authors and illustrators. Regulate musicians too while you are at it. All of them produce copyrighted material. Bridge and aerospace engineering are different things entirely -- their products are not copyrightable. If we are to regulate software design, we should remove its protection by copyright since it is apparently not a form of creative expressive activity that copyright law seeks to protect. |
| Wed 22 May | Freedom Fighter | down on certs, You've got a point there. Neither accountants, lawyers, nor doctors produce copyrighted material within the scope of their practice. And there is no restriction on non-doctors writing books on medicine nor on non-accountants writing math textbooks. Anything that is copyrightable is a form of speech and is protected under the US Constitution. Government regulation of speech is Facism. That',s what we are really talking about -- let's call it what it is. |
| Wed 22 May | Doug Withau | “Thus lawyers work in law firms run by lawyers, accountants work in accounting firms run by accountants, and medicos run the relevant aspects of hospitals. Civil engineers often work in large engineering consultancies run by engineer.” – Hugh, this is a broad generalization you and everyone else knows is not true. I hear stories all the time about how well HMOs are running hospitals. Lawyers do have clients, I am certain they understand the law and never demand foolish, frivolous lawsuits be filed. I am ashamed to be posting to this thread. WAA, we are not appreciated. Boo hoo I get no respect. Quit your whinin and get to work. It’s a job, not a holistic growing human experience. OK, rant is over. I feel better thanks. I do agree that computer science is very young as a science. Has anyone here read “To Engineer is Human” by Petroski The fact that I can put a piece of paper in with my software product that says “If you use my product, you have no legal rights if anything goes wrong” makes software quality a joke. The EULA is the ultimate get out of jail free card. Even if my product does something malicious to a random file, you cannot sue me. As long as corporations are not held responsible, they will make decisions based on the market and the bottom line. Lawyers can be disbarred, doctors sued for malpractice, a Practicing engineer can loose their certificate and be sued for malpractice. Worst thing that can happen to a code monkey is getting fired. That just means they put “Two years language XX experience” on the resume, and blame poor management. A certification would only be worth anything if the certified engineer gave guarantees. If you had to guarantee time estimates, people estimates, quality (a hard to measure thing), features, and no bugs could you? Would anyone accept your schedule? |
| Wed 22 May | Johnny Simmson | Steve McConnel argues this better than I can. http://www.construx.com/stevemcc/gr-badges.htm |
| Wed 22 May | Johnny Simmson | This is from Steve McConnell's After The Gold Rush: 'Professional engineers will gain other benefits. The professional engineers who put their signature and reputation on the line for their companies will have final say over methodology choices, design approaches, and other decisions that affect the quality of the software for which they might be held liable. Without professional standing, your boss can come to you and demand that you commit to unrealistic schedule, make short-sighted design compromises, or sacrifice quality in order to get the software out the door. As Fred Brooks pointed out a quarter century ago, it’s difficult to make a vigorous, job-risking defense of something that has no quantitative foundation and is certified chiefly by your hunches. A well-defined profession—consisting of education, a code of ethics, and licensing—will give you a stronger foundation than mere hunches. You will be able to say, 'The standards of my profession don’t allow me to shortchange quality in this situation. I could lose my license.' You will have a professional and legal basis for standing up to unenlightened managers, marketers, and customers—a basis that is sorely lacking today.' |
| Wed 22 May | down on certs | Yeah right - certification will do all that. All that shows is how vigorously out of touch with reality McConnell and his legions of braying, glassy-eyed, cult members are. |
| Wed 22 May | Philip Rieck | I dont particularly like that quote from Steve McConnell. (this response is only about his dreams of 'strong backing' for software people, not about certification as a whole) Over the years, I (like most developers) have worked on mostly in-house projects. I've designed and written mission critical apps that run large businesses, and I've done one-off projects. On my current project, we are understaffed and under an externally-imposed deadline. Yes, quality will suffer, but it's much more important to my client that we are able to 'limp' along by the deadline than have a rock-solid application two or three months later. They are aware that there will be bugs, and are in charge of prioritizing bugs down to 'don't fix me' if they can live with them. So what happens if I could lose my 'Software Engineering' license over that? I wouldn't do it! My client and the ~200 employees would simply be out of luck. If the licencing regulations were written loose enough to accomodate these situations, they wouldn't be worth the paper they were written on, and wouldn't give us the strong backing we would need on these arguments. Sure, in a perfect world we would never have to compromise quality. However, madating 'never compromise quality' would not meet the current needs of most of the industry. |
| Wed 22 May | Johnny Simmson | Phillip, I assume that if its more important to your client that the product be shipped on time, whether it is correct or not, that you have sign off from your client indicating so. So in that case, you wouldn't lose your license. Now if your client wanted bug free, fully functional code but your boss was jacking with your process you could say 'I'm not willing to sign off on that'. Then the boss could either accept your decision or keep firing engineers until he found one that was willing to sign off on it. Since programming isn't considered a profession by the courts, right now there isn't really anything that could happen to the engineer that signed off. But, if we were required to be licensed, the client could take action and the engineer that signed off on it would probably lose his license. He could still write code, but he wouldn't be able to sign off on it. |
| Wed 22 May | Hugh Wells | Yeh, it's a pity McConnell is pro-certification. He's a first class software engineer. We'll just have to disagree on that. Doug, this isn't a whine ( but if it makes you feel better, then OK.) It's a big industry issue and there are lots of people who are going to be making decisions that affect your and my and our lives. From what I've seen, a lot of the people making those decisions don't know the first thing about software development. Joe AA, it's not software engineers who describe roles in terms of narrow tools and platforms. Indeed, the fact that this occurs is, yet again, part of the range of problems resulting from this being a young, and fast moving profession that isn't in charge of its own activity. Older professions have stable, systematised divisions that make sense. |
| Wed 22 May | Hugh Wells | One of my big objections to certification ( state licensing ) is that I think it would actually reduce standards. It would make it much easier for 2nd and 3rd-raters to climb the career ladder. |
| Wed 22 May | Jeb | Hugh: True on certs lowering standards. I am java certified only because it is/was hot. I am not good at java and I know it but hiring managers lover it. |
| Wed 22 May | Johnny Simmson | One thing we can agree on: it would be very hard to come up with a proper license. |
| Thu 23 May | Bill Carlson | One point that seems to be missing in this discussion is that all software does not need to be developed to extremely high standards. There's a market for Yugo as well as Mercedes. A missle guidance system vs. an internal app used by 5 people. You get the idea. On the flip side, there isn't much demand for flimsy bridges, bad medical advice, drunken defense laywers, etc. Quality costs money. Would I pay 3 times as much for the software I use to have the bug count cut by 80%? Maybe, maybe not, but it's my choice. I can evaluate that, but I can't evaluate the bridge I'm about to drive over. How does one define liability with software? If my car breaks down, it's my tough luck. If I buy a house that is in some way defective, I may have recourse if the build quality is in the bottom 5 percentile. But I can't demand that all the corners be exactly 90.0000 degrees. It's my choice not to spend another 100K on a house that has perfectly square walls. Software that is too buggy to be used at all is either guilty of misrepresentation (a legally actionable offence) or is beaten up in the marketplace. Let's not fix what isn't broke. The market hasn't voted with it's pocketbook for 100% bug free software. |
| Thu 23 May | Simon Lucy | I don't think I've ever considered myself a 'professional' in the sense of follwoing a profession (though that may have something to do with being married to a lawyer that works for the ethical department of the professional body), but rather that its a trade or craft. I don't find anything demeaning in having comparable skills to a Master Builder, Plumber or Carpenter on the one hand, or a Building Surveyor, Architect on the other. My wife wouldn't consider Architecture a Profession either :-). The ethics of being asked to perform, or not comply with safety procedures in developing code are similar to a lawyer being asked to commit a breach of the rules. The compelling difference is that Katie's partner has no professional body to support him or manage the complaint. Leaving aside the performance of professional bodies in actually pursuing breaches, we are at a disadvantage in that kind of situation because we aren't a profession. Not many though would wish to pay the dues of becoming a professional. |
| Thu 23 May | Johnny Simmson | Bill, I would argue that something is broke whether the market is smart enough to realize it or not. Katie's partner should have the power to say 'no' and have a leg to stand on rather than just get fired. If you follow that link to the construx site, McConnell points out that not all software engineers would need certified and not all projects would require certified software engineers. Here's the link again: http://www.construx.com/stevemcc/gr-badges.htm . Simon, the difference is that you don't have the same status as a plumber, architect, or a master builder. Those are legally recongnized professions and those people can be held accountable for their work. The very term 'master' is usually conferred by a guild or trade union. |
| Thu 23 May | Hugh Wells | Simon, I agree with you that software engineers are no more important than plumbers and the many other hard working people in society, and are less important than school teachers and nurses on a scale of social usefulness. Discussion about profession in this context and thread doesn't carry any implications about social status at all. It's more about a role being seen by society as applying a body of expertise and skill in a responsible way. The definition of 'professional' that your wife and the UK legal fraternity might use has more to do with being a member of an exclusive little club where the rules are set by traditionalists. That's not relevant to software engineers or this discussion. |
| Thu 23 May | Bill Carlson | Simmson made the point that only a fraction of engineers would need to be certified. This makes sense. On a practical note, though, it's a difficult line to draw with regards to liability. In other professions, an arbitrary line is drawn and the bottom 10% of work is professionally unacceptable, the bottom 3% is legally actionable in a civil sense, and the bottom 0.2% is criminally neglegent. These numbers are 'pull-from-air', of course. Everyone drives over a bridge in mostly the same way. 'Difficult bridges' don't get built. People drive the long way. A certified software engineer might build the 'easy' bridges, with full accountability, but difficult software involves inherent risk and complexity. As long as there's a line drawn between 'life or death' software and run-of-the-mill apps, I can see certification as a possibility. |
| Thu 23 May | Johnny Simmson | That's a good point Bill. There is a big difference between software engineering & computer science. Very very few of us are involved in solving problems that haven't been solved before. Yeah, there is always something slightly different about this new bizapp or driver you are putting together, but there is little in the way of invention. Those people that say you can't compare software engineering to civil engineering are really missing the point. Just as a civil engineer has only so many ways to construct a bridge over a given terrain, there are only so many 'proper' ways to sort a list over a given data set. |
| Thu 23 May | Space Cadet | 'there are only so many 'proper' ways to sort a list over a given data set' What should the penalty be for using the 'wrong' algorithm (one not 'officially approved')? |
| Thu 23 May | Hugh Wells | No projects or products are as simple as Sort a List. |
| Fri 24 May | Johnny Simmson | Hugh, yes, projects usually involve more than 'sort a list'. I used that as an analogy. However, you are sadly mistaken if you think that what the vast majority of us do is really all that complex. I've done driver development, graphics programming, gui development and a few database systems. They required a learning curve up front, but really there are standard, expected ways of going about things. Such as, (analogy alert!) not using quick sort on data that is mostly sorted. |
| Fri 24 May | Johnny Simmson | Space cadet, your question is answered in the link I provided. If you are too lazy to read, please don't post. |
| Fri 24 May | The Raging /.'er | Most problems were caused by the tech boom. Lots of unqualified people were programming. Now that its over companies can be picky and things will improve. I've seen ads from companies that want an MS where a couple years ago they just wanted a BS OR experience! |
| Fri 24 May | Jutta Jordans | > I've seen ads from companies that want an MS where a couple years ago they just wanted a BS OR experience! Yeah right, I just don't think this will change things to the better. I know we had this discussion in various threads over and over again, but I do not think a MS neccessarily qualifies anyone to be a better programmer. Don't get me wrong, there are surely tasks and jobs around that are best done by people with a strong logical and mathematical background and you have a higher chance of finding them among the MS graders than with the BS or experience only guys. But there are also many things important in software development which are normally not taught at university (and maybe cannot be taught at all), as well as a lot of the so called 'soft skills'. It is good for companies to hire only people who really qualify for the job and to be a little more picky than they used to be a few years ago. But if the only way to do this is by looking for diplomas, degrees and certificates, it will not get them very far. Have fun, |
| Fri 24 May | The Raging /.'er | I agree Jutta, especially since I don't have a degree! Oh well, there loss not mine! |
| Fri 24 May | The Raging /.'er | Should say I have seen jobs asking for more experience. 1 company has changed there senior programmer from 5-10 to 10-15 years. I like that! |
| Fri 24 May | Johnny Simmson | Wait a minute, I thought the IEEE was against certification? http://www.computer.org/certification/ |
| Fri 24 May | Johnny Simmson | The ACM is in favor of certification, but not licensing. 'The ITPI steering committee believes if ACM, working cooperative with IEEE-CS and other groups, can establish a good certification program, that alone will be a major benefit to the profession.' ( http://www.acm.org/serving/se_policy/selep_main.html ) Sounds like a good step forward to me. |
| Fri 24 May | Hugh Wells | No, the IEEE is pro-certification and has a licencing program. The ACM's position was formed in response to that. |
| Fri 24 May | Johnny Simmson | Hugh, that link you provided states that the ACM is in favor of certification, but not licensure. |
| Fri 24 May | Hugh Wells | The terms are used interchangeably in general discussion. It's obvious that I'm citing the reference because of the ACM's formal opposition to licensing of software engineers. If you haven't yet, you could also read their judgement on the compiling of a body-of-knowledge (BOK) for software engineering. Johnny Simmson, why don't you move the discussion along instead of quibling? By the way, are you 'H1-B' that surfaced on the Bad Company thread? Same used of 'straw man,' same relentless undermining of software engineeing. (Code-monkeys are fine, 20 years C experience counts for nothing, ... etc) |
| Fri 24 May | Johnny Simmson | Hugh, the terms are not used interchangeably by the ACM. They are in favor of certification but not in favor of licensure. Licensure involves recognizing the profession in a legal sense, certification does not. We can't move the discussion along until we agree on the definition of the terms and what that definition implies. Now then, for your next straw man argument: No. I do not believe, nor have I ever stated, that experience counts for nothing. In fact, the method outlined by McConnell does have a provision for licensing 'experience-only' candidates. While I don't recall the 'Bad Company' thread, if more than one poster has criticized your use of straw man arguments, it may be indicative of a problem in your logic. |
| too critical of MS? | Mon 20 May | Roger |
| Why is it that people hate Microsoft so much? If everything they do is so buggy, bloated and ugly, so why buy from them? Looks like wherever I go on the Internet, people are criticizing MS for being capitalistic, greedy, succesfull or whatever. Are people jealous? Because it seems to me that the arguments against MS are pretty much similar to the arguments the terrorists made for there attack on september 11th. I just want to understand what pushes people to believe that MS is so bad? I agree, MS has its faults, but so far theyre the best IT company ever. |
| Mon 20 May | Johnny Simmson | (Score:-1, Troll) |
| Mon 20 May | Mark Bessey | I know it's a troll, but I just can't resist: Read up a little bit on the history of Microsoft, in particular, how they've managed to abuse their monopoly position in the Operating System market to take over other markets (applications, development tools, browsers, etc). Ask anybody who has ever done a business deal with Microsoft as anything other than an end-user customer. Microsoft has a history of screwing over 'partners' when the relationship is no longer convenient. The mere existence of Microsoft Outlook, and its feature set that seems custom-designed for email worm propagation, automatically disqualifies Microsoft from the 'best IT company ever' award, IMO. -Mark |
| Mon 20 May | Michael | It's because of their size, it makes them an easy target. They have millions and millions of customers and therefore even a small percentage of antagonists amounts to a large number of people - but compared to their user base, its probably on par for other companies. Also, they are very successful at what they do - this means that a) the people who they crush in the marketplace tend to cry because Microsoft pounded them so hard and b) because they have lots of money which no one likes (proletariat vs. aristocracy ref. see 'history'). In addition they have been harshly competitive and sometimes overtly tricky maybe even illegal. They are the Goliath and so no one wants to root for them, even when they do a good job. They don't need praise, they already got billions in the bank. Don't sweat most of the hype. Its good to keep an eye on them since they have so much accumulated power, but they aren't going away for a long time. |
| Mon 20 May | Greg Neumann | Stand back from the troll, because he is defining the question. A smart person would ask this of Slashdot. Because here, most people are probably ambivalent. Microsoft lies like the devil. But they keep hardware manufacturers in check. |
| Mon 20 May | pb | People have always disliked success and leadership. |
| Mon 20 May | Ian Stallings | >Why is it that people hate Microsoft so much? Because we love to hate. We hate stars, we hate politicians, we hate our neighbors, etc. Every broad generalization deserves another. >Because it seems to me that the arguments against MS are pretty much similar to the arguments the terrorists made for there attack on september 11th. A 'Non sequitur' attempt that is surreptitiously attempting to form an association in the reader's mind between MS and the 9/11 terrorist by juxtaposing them above. Criticizing a company is far removed from killing people for a cause. |
| Mon 20 May | Hugh Wells | There are five reasons. First, there's a natural tendency to question and condemn the market leader, especially among younger folks. This is natural and healthy. For example, 12 years ago IBM copped the type of scorn nowadays directed at Microsoft. Secondly, a significant part of the criticism derives from orchestrated attacks by big business competitors, and is just as bad as what it purports to condemn. Actions at the legislative level are fuelled by these interests. Thirdly, the dominant usage of Microsoft products exposes those products to the highest risk for viruses and other attacks, and that predominance is then gleefully misinterpreted by Microsoft enemies as arising from sub-standard software development. Fourth, there's a substantial degree of expertise required for Windows development. Developers from other areas sometimes become frustrated when they try to develop for Windows, and they then condemn the platform and environment. Fifth, and following from the above point, applications developed by inexperienced developers often suck big time, and this is then sheeted home to Windows rather than to the amateurishness of the developers. This is one of the factors in criticism of Visual Basic as a development tool, for example. |
| Mon 20 May | Hugh Wells | Ten years ago both Microsoft and IBM wanted my company to write things for their respective platforms, being Windows and OS/2. And this anecdote points to the reason Microsoft won the desktop and IBM lost. Microsoft sent us free compilers and books. When we had queries, we would get phone calls back, with answers, from very senior people. IBM, in comparison, sent us invoices for $1,400 sets of books. Not only that, the IBM books were dreadful. |
| Mon 20 May | Albert D. Kallal | I think the comparisons of MS today, and that of IBM which used to be the daily whipping boy are good one. IBM had anti-trust court battles for what...at least 10 years? MS has done IBM the favor of the century, in now that IBM can move on, and just go to work! It is funny how so many companies focus some “evil” deed by ms. There are a good many misconceptions being spread about MS that do disservice to all. While people are quick to point out the browser war, it is a incredibility stupid and poor lawsuit. I can think a good many more areas where MS DOES NEED to be hauled into court. But the browser? What a crock, and waste of taxpayer time. This is simply a great political cause with which to bash MS. The reality is that Netscape threw this market away...it had little to do with MS. Great, now the idea here is to support stupid mistakes by poorly run companies. What leap forward in our economic policies. MS beat crap out of Netscape, Word Perfect, Lotus 123 with better IE, with better Word, and with better Lotus. Read some good articles at what went on here. Heck, read the following: Things your should never do: http://www.joelonsoftware.com/articles/fog0000000069.html Also read: http://www.joelonsoftware.com/articles/fog0000000074.html Heck, if you had put me in charge of Corel/WordPerfect 3, or 4 years ago, and just read the above two articles, the world would be a different place. That company was so poorly run, and they also missed the whole Linux boom altogether. Now MS actually had to bail out that company, and has killed any product direction that will hurt ms. In fact, it really means that Corel/WordPerfect sold us all out. They really need me at the helm. Even today, we hear grumbling about the fact that MS bundles the Media player with windows. Do any of you remember what the first computers were like? Do you actually remember when the Sound Blaster Card was a complete add in, and not even supported by Microsoft? The Sound Blaster Card finally started becoming a wide spread standard when windows 3.1 came out. Microsoft decided to start supporting sound cards, so YOU THE CONSUMER did not have to run around and start configuring every single card that you purchased. When they adopted the card as a standard, then the flood gates opened to competition, as anyone now could build, and install sound cards (if you were creative labs, then I am sure you were not happy). By the way, when you have a chance, fire up windows 3.1, and check it out. You will find the windows media player installed. In other words, the only reason why you hear that bundling the media play is a evil today, is because the competitors are telling you so. Then the crowd cheers...ya right!..the media player is a evil thing, since ms includes it with windows. Someone forget that this has been the case since windows 3.0! I mean if you want to talk about a closed system for sound cards, why are we not talking about Apple computer? They are the ones with a closed system. It is truly laughable to hear complaints about MS including the Media Player with windows. It is if someone woke up, and was told this was bad thing. The crowed cheers again..yea...I am ignorant, but this must be a bad thing. Get real, the media player has been there for 10+ years. The existence of the Media player in windows 3.1 all the way to day, NEVER EVER stopped Real Audio in any way. Why did Real Audio not complain about the media player in windows 3.1? Fact is, that streaming sound over the web is a cheap and low cost feature. It is also something that the newer media player does well. Streaming media has becomes like any other commodity on the web, and the value of the player is not that much (the consumer does not care if it is Real Audio, or windows media...they just want to click on it ...and play it). These ignorant people make me sick. If we had to pay to use the mp3 format, then I think all us consumers would have quickly found something else. This is so simple. I mean, really, if you go to the stereo manufactures and ask them should GM, Ford, Honda etc should include stereos in the cars, what the hell do you think their combined response is going to be? Of course they are going to say that the auto industry SHOULD NOT include stereos in their cars. They want to you to go out and purchase stereos from them. I mean, go ask Real Audio if windows should have the media player? What possible kind of answer are you going to get? Of course they are gong to tell you it is a evil? In the case of Real Audio, or in my example of the stereo industry with the auto industry, what do you expect? The problem with most complaints directed towards MS, is that people with their own self interest are being asked to comment. Their self interests are no different then the self interests that MS has! Why not forget all of these industries, and ask what the public wants? Do you think that the sound card manufactures want Apple to open up their computers to allow sound cards....you bet they do! Then there is the example about the $10 tax on PC manufactures. This story has recently gained a lot of press coverage. This info is completely miss-leading. All MS said, that if you become a exclusive suppler to windows, we will cut the price of windows by $10 per copy sold. To come and tell me that is amounts to a $10 increase or “tax” for each pc sold is simply ridicules. People who twist words like this, I have no patience for. From Visa/Master card striking deals at the Olympics, to the tire manufactures who offer sweet deals to the auto industry, this type of deal is standard fair in business today. If the company wants to sell non windows OS, then they lose that discount, but it certainly is not a tax on the other pc’s, as widely reported in the news. Talk about misleading the public. The company simply has to decide to lose the discount, or simply charge $10 more for those pc’s with windows installed. I see no problem with this at all. It was not a tax on pc’s. I mean, if you don’t purchase Windows, then you not paying for it. Some manufactures said that they could not afford to lose this discount. That is too bad. If don’t want to sell windows...then don’t? Regardless, this should not have been worded as a tax by the press, but simply the loss of a discount . I can come up with some real complaints and areas where MS does need to be hauled into court, but the above widely reported issues are certainly not ones that need attention. What a joke. What we really need is some integrity in the MS bashing. In other words when we DO decide to complain about MS, lets use our brains to do so. The software and IT industry is an important industry to all of us. Many of those people who do complain are complaining out a good heart, and of true good concern for all. The problem here is so many are miss-guided. We need people to speak out, but one must use responsibility when doing so. Gee, I hope my response on being responsible is responsible! The browser and the Media player have got to be two worst issues to pick a fight on! Albert D. Kallal Edmonton, Alberta Canada Kallal@msn.com |
| Tue 21 May | Justin Johnson | Did the OP seriously compare critics of Microsoft to Taliban and Al-Qaeda terrorists? Really? Pointing out flaws in your perfect company puts me in the same ethical barge as people who flew planes into the World Trade Center, killing more than 3,000 people? Bitching about macro viruses makes me the same as a suicide bomber? Dude, your moral compass is spinning out of control. |
| Tue 21 May | pb | Albert and Hugh, nicely said. There are so many opportunities out there it's nauseating to here about how Microsoft is supposedly putting everyone out of business and creates lousy products. At some point, and hopefully soon, people and companies are going to have to take some responsibility and put their futures into their own hands. |
| Tue 21 May | Justin Johnson | Since others have taken the question seriously, and turned a troll into a discussion, I'll add my own thoughts. For one thing, Microsoft has rarely made the best product first. Many user's superficial sense of justice is offended by 'embrace, extend, extinguish'. While this has made good business sense for Microsoft, it's not a great PR move--Microsoft seems almost to consciously have chosen to be a corporate bully. That's great for stockholders, but it's not the sort of thing to endear it to anyone who has complaint about Microsoft. For another thing, a lot of Microsoft's success is attributable to their business skills, to the apparent detriment of their products. Again, while that's good for the stockholders, it's not the sort of thing to make purists fall in love with it. |
| Tue 21 May | Hugh Wells | Albert raises some excellent points, to which I would add Dial up Networking. Does anyone remember what users had to go through to connect to the internet before Windows 95? |
| Tue 21 May | James Ladd | Ian, >>A 'Non sequitur' attempt that is surreptitiously attempting to form an association in the reader's mind between MS and the 9/11 terrorist by juxtaposing them above. Criticizing a company is far removed from killing people for a cause. << OMG, what a great sentance !! |
| Tue 21 May | Tanya | I think that the software market would be too fragmented without a 'Microsoft'. Software would still not be regarded as a viable business proposition and still be regarded as a high risk (much higher than now) activity due to lack of standards without a unifying presence such as a Microsoft. So for better or worse, I think the IT industry is better of with Microsoft (or someone like them) than without. |
| Tue 21 May | bill gates. | I am amazed how much the general public lack information about Microsoft. I am tired of reading the ignorance of people. Microsoft is hurting the software industry, it's monopoly is beyond control. Every company that worked with microsoft has learned that the ugly and hard way, their marketing and excess money that they 'stole' from the end user was used to promote a different microsoft that never existed. |
| Tue 21 May | Eric Debois | If I has a buck for every time ive partisipated in discusions like this one, id be richer than bill gates. :D Seriously. Hate is a strong word. I find MS to be an annoying presence. I mostly choose to use other OS's for any given task. My humble hope is that with MacOSX's base in the BSD a common open, cross platform API for desktop apps could be established. Then MS would have a real competitor as the options would be limited to, 'Write for Mac, Linux, BSD and what ever' OR 'Write for Win32'. Suddenly the propriety API would not look so good anymore. Such a thing would have to be initiated by apple though, and I dont think it will happen any time soon. |
| Tue 21 May | Ian Stallings | James, I thought someone would like that one ;-) Sometimes you gotta use the 'baffle them with bullsh!+' technique. But this threads argument is flawed and based on assumptions so I figured I'd chime in. Not every open source advocate should be labeled as a zealot just as not every MS developer should be labled as a lemming. |
| Tue 21 May | Paul Brinkley | Most of the Microsoft bashing comes from developers, not end users. There's a big reason for this. Software is a rich field of opportunity. It's like a North America circa 1800, but without any native people to displace. It's alarmingly easy for a developer to come up with a nifty program that no one else has done, and make some money from it. Or a developer can just give it away if desired. Software can also be duplicated losslessly, and since it's such a rich field, that developer will very likely come up with other nifty programs. This creates a golden age, where developers freely share some programs, and maybe sell others. Developers open the cyber-equivalent of mom-and-pop stores. They're their own bosses. Idea stealing is uncommon because of the vast amount of room available for everyone, and when it does happen, it's considered an accident, and everyone's quite happy to attribute some idea to someone else if there's any doubt. Meanwhile, all that freely shared software means that if you want to get a computer and do neat things with it, you have literally thousands of free programs you can use. You could spend your entire lifetime downloading and trying out code written by others and given away, just because it's a hobby to someone. Then along comes Microsoft. Now, MS is certainly not responsible for every horror story. But it does have one great big huge well-known example of one, and probably the most egregious. That would be the Netscape/IE debacle. Back in the day, Marc Andreessen was the poster child for software developer done good. He (with some help) made a decent web browser, Mosaic. Then he made a much better one, Netscape. If you were a business, you had to buy Netscape, but if you were a struggling college student, and knew where to go (it wasn't hard), you could get it for free, and see how much better it was than Mosaic. And it was -so- much better that you didn't mind forking over the $50 or whatever. You were happy to do it, in fact, because Marc did a bang-up job, and in the developer world, you send people like that $50 because you know they'll turn around and make another nifty program that you can get for free. Microsoft's response was to give away IE for free with Windows. Business-wise, this is brilliant. They worked hard on Windows. They worked hard on IE. It's perfectly fine for you to give away something you made yourself. (That's a point I've been praising all this time, after all.) The trouble is this. It rapidly became clear that they didn't give it away for free because it was a hobby, and they liked sharing their software. It was obviously done to kill Netscape. While it had some niftiness that Netscape didn't have, it wasn't the improvement over Netscape that Netscape was over Mosaic, so it didn't get raves from the developer community. In fact, it duplicated a lot of features Netscape had. And while I'm sure MS duplicated them in a legal manner, they weren't giving props to the Netscape crew for their ideas. MS was a BigCo, and BigCos, we learn, never give this sort of respect to a competitor, because it's a sign of weakness. The thing was, developers knew exactly where MS was riding Netscape's coattails, and so MS's refusal to give credit where credit was due smacked of revisionism. Let me tell you: deception -really- sticks in a developer's craw. Oh, and did I mention that while Netscape worked on Unix, IE did not? [I'm fairly sure of this, at least.] Netscape was OS-agnostic, IE was not. Now that in itself is fine; developers often shared software that would only run under one OS. But that was okay, because it was a bit of work to port it, and if you were wiped from writing the one-OS version, that's understandable. Very often, a developer would give away the source code, or at the very least a spec of how the software worked, if it wasn't already obvious from watching the program run. Another developer would invariably port the program to VMS or Windows or Macintosh or Xenix or whatever. More people could now use that program, and the porter would get his/her name in the credits list, and actually make friends with the original developer. What could be better than that? So why not port IE to VMS, Mac, Xenix, etc.? Because if you did, MS would sue you. Which is all fine and legal. Any developer had the right to do this, but I know of no individual developer who did. Only BigCos did that. Another crawsticker. Anyway, Windows by then already had a big market share. What's more, they had all sorts of office software that came with it, including Word, Excel, PowerPoint, etc. Everyone was sharing documents created with these programs, and if you wanted to do corporate stuff, you had to use the same tools as this block of users. These programs only worked on - you guessed it - Windows. You can't write programs that'll output documents in the form MS uses, because MS won't publish the specs for those formats, and it'll change them anyway with the next version. So you have to buy Windows. And since you're also getting IE for free, why buy Netscape (if you're a business)? So to make an epic story merely long, Netscape went belly-up. As future MS-bashers saw it, Netscape lost because they played the game like developers, and MS played it like a BigCo. In developers' minds, Netscape's strategy would let everyone win, and Netscape would win a lot. MS's strategy let everyone -think- they win, and MS wins BIG. MS took advantage of the impromptu economy model. While Netscape took advantage of it by making a Mosaic-killer, MS did it by previously being the biggest kid on the block. Another crawsticker. What's more, MS ended up sending a message. If MS sees a program that works, MS will duplicate its function, make a version that works best on Windows, and advertise the hell out of it as their own invention. It does this because it has enough liquid assets to do so, and because it's legal. So any bright idea I may come up with for a program can be allowed to grow only until MS notices me, and then cuts off my air supply. I can't possibly get enough liquid assets to defend against this, unless I'm insanely lucky. The only way up is to piggyback on a big kid from another block, like Nintendo or Sony or Oracle or Sun or Dell, in a related industry I didn't choose. MS refuses to compete on terms of product quality and innovation, but rather by being deliberately stubborn and by bullying vendors, while advertising that they 'innovate'. More revisionism. Another crawsticker. Take note. I have no problem with a company parlaying past success into more success. That's a natural thing. What I take offense to is MS leveraging an economic model that we developers chose to honor, and made itself richer at our expense. I can spend ten tons of effort creating an original program, and then MS can spend ten pounds on minor improvements, twenty tons on marketing a Windows-only version, and reap 200 tons of benefit. 'All perfectly legal.' I'll be lucky to get my ten tons back. |
| Tue 21 May | Paul Brinkley | Upon re-reading, I realize my post may sound like a Netscape lamentation screed, which Albert Kallal addressed nicely earlier. I should reiterate that Netscape's downfall isn't my major point. My main point is to convey the utter frustration and helplessness felt by any developer who can't compete with MS in terms of innovation, because MS instead competes in terms of business maneuvering, coupled with the rage we feel whenever MS then claims to the world that it does, in fact, compete in terms of innovation. So we take it out on developer forums like this one. :-) Seriously though, these feelings are real and justified, and appear to me to be the primary drive behind MS-bashing. |
| Tue 21 May | Sick of sloppy work | I dislike Microsoft because they charge a lot of money for substandard and defective products. hey -- why pay for something that is susceptible to so many viruses and is buggy? I think it is a rude joke that the software industry in general is not liable for the quality of their code and then charge money for it. Everyone else has to stand behind their work. What if your auto mechanic said your brake job was offered to you on an 'as is' basis? Suppose your pharamacist filled the wrong perscription and that he or she told you they would post an 'upgrade'. What if your accountant filed the tax returns for your business incorrectly and then told you he or she would send in a 'patch' to the IRS? I bet that would go over real big. Suppose Civil engineers were not liable for their structural analyses? Nobody would live in a high rise flat. As far as I am concerned the EULA that Microsoft (and other commercial companies) use is an an excuse to do sloppy work and charge for it. The other professions (engineers, lwayers, doctors) have to stand behind their work. Somehow there is a special dispensation that extends to commercial software vendors that makes them liable for nothing. Well that is just an incentive to slop code together. Human nature being what it is, that is exactly what happens. |
| Tue 21 May | Johnny Simmson | Sick, Since most programmers (at least the vocal ones) are opposed to any sort of education or certification (and no, I don't mean vendor certs), it will take a really bad accident or something else equally as drastic before we can ever hope for any sort of professional standards in this field. Until then software engineering will not be seen as a true profession and will continue to be looked down upon as a geek hobby. Wow. That's been building up for a while. |
| Tue 21 May | Bill Carlson | I tend to come down on the 'pro-Microsoft' side. The reason? Pervasivness is usually more important than innovation. Sounds like blastphemy, but the 'dumbing down' of the 'commodity PC' has been a good thing, IMO. I think our perspective is skewed, being as most of us (those not being employed by MS) see bundling as a threat to our livelyhood. Fair enough, but only in the short run. As computing connesuiers, we also look at an 'off the shelf' PC configuration with the same distain that a goumet chef looks at a Happy Meal. In the end, though, it creates opportunity for all. How much more E-Commerce is there, given that any Joe can order a $599 PC and run AOL? Would Joe even have bought a PC if he had to buy a browser separately? How about a file system? How about separate hardware components (another example of how bundling has benefited the industry)? How much greater is the opportunity to sell enterprise software now that any 10 person firm can afford to buy and maintain a network? Granted, this eats into the ability to sell extremely high cost systems, but it widens the playing field. MS might compete with my company some day, but without MS, we wouldn't be here to begin with. |
| Tue 21 May | Mikayla | Earlier, Greg says: But they [Microsoft] keep hardware manufacturers in check. Interesting. Not that I'd thought about it before - you don't have to these days - but true. This form of Microsoft standardization is a helpful service to us developers, not having to choose what hardware we're going to code for. In much the same way, keeping us developers under control can be seen as a service to the consumer, like Bill just said. The difference here is that upstart hardware vendors also appreciate the Microsoft standard - so long as they can plug and play, they can compete with anyone based on quality alone. Microsoft at this point is a marginal at best player in the hardware world. Upstart software vendors, on the other hand, tend to live in their little niches and hope MS hasn't noticed them yet. I would love the Microsoft standard too, but for us employees of small software companies, Microsoft as the competitor/acquisitor is the axe over our heads. It may not happen anytime soon, but when it does happen... having invested in the MS route means we're sitting ducks. It's the twinge of uncertainty which keeps me from being completely in favor of the Microsoft solution, even when I do ultimately choose it. You hitchhike on the Microsoft bandwagon, you have to plan for getting thrown off. I'm not saying don't do it, I'm saying 'Be prepared.' |
| Tue 21 May | Bella | Until then software engineering will not be seen as a true profession and will continue to be looked down upon as a geek hobby. Considering there are ZERO credential and certification requirements, it's simply BAFFLING to me how incredibly well paid we are. Are you kidding? How many 'geek hobbies' allow you to pay off your mortgage before the age of 30? And how many give you BMW leases, dogs at work, etc, (however fleeting it was)? |
| Tue 21 May | Johnny Simmson | Bella, what does pay have to do with my statement? FYI, The bubble has burst and salaries have stagnated. |
| Tue 21 May | Sick of sloppy work | Hello Bella: I don't begrudge developers because they make huge salaries. What I am sick of is defective buggy crap. I work as a chemical analyst at the FDA and I am here to tell you these Microsoft NT equipped instruments have really sloppy software. How come Excel cannot round numbers correctly when a $10.00 Casio calculator can do it? Instead I have to go through my spreadsheets and insert =ROUND(foo, 4) everywhere. Also Microsoft Word behaves very badly with embedded spreadsheets. As for the closed source proprietary software, it's pathetic stuff. The 1100 chemstation software for my HPLC is just trash. One night I had to do a UV/Vis analysis of a pharmaceutical and after finishing the test I was horrified that the 1100 software saved *none* of the results. I wrote Agilent and a week later they called. 'Oh yes' they said 'that is a bug logged in under KPR-74' (kpr = Known Problem Report). It's that kind of glib disregard for fixing mistakes that makes me distrust the closed source developers. They knew the stuff was defective when they sold the instrument to us. A similar problem happened with the software for a Perkin-Elmer FTIR. In contrast the Open Source Octave works very well and the developer, Mr. John Eaton is quick to correct mistakes. Also the free software (open source) Scilab (From INRIA) is developed by a research facility in France. It correctlyrounds numbers and is a very good programme. Just to dispel any caricture that OS developers are unemployed and undisciplined people, this facility employs 550 PhD's. They also have a division of Mathematicians to help with software development. Most important -- they do quality work. |
| Tue 21 May | Bella | My point was to address your 'geek hobby that is looked down upon' comment. I disagree. We get paid great. If thats 'being looked down upon', then WALK ALL OVER ME, BABY! As in many OTHER fields, it sure beats getting the LIP SERVICE of being lookup UP to, but getting paid crap. That's simply insulting to one's intelligence. Usually, people in those situations are not very intelligent. Appropos, I suppose. |
| Tue 21 May | pb | Paul, that's the dumbest thing I've read in awhile. It makes perfect sense that an HTML viewer be included with an OS. I don't remember knowing a single person who paid for Netscape. Anyone with any hope of browser marketshare needs to give a basic client away and make money in other ways. Duh. Netscape has noone to blame but itself for its demise. It made fatal mistake after fatal mistake with the biggest being the attempt to develop a suite of inferior products instead of a good browser. |
| Tue 21 May | Bella | Perhaps, you need to learn to properly select what software meets your needs. If you don't like how certain software behaves, or if it doesn't meet your needs, then ask for a refund, and go use something else. This applies to ANY consumer good, including software. |
| Tue 21 May | Johnny Simmson | Bella, what you are paid has little bearing on the value accorded your profession. For example, to be an engineer in most states you have to: 1. Possess a bachelor's degree in the discipline. 2. Undergo 4 years of internship with a licensed engineer. 3. Pass an 8 hour exam in your specialty. That is why most of the engineers I know give me a hard time about being a 'Software Engineer'. To them its the same as being a 'Sanitation Engineer'. Maybe I'm shallow and/or elitist for wanting programming to be considered a 'true' profession, but you can't argue with their results. And no, it has nothing to do with money. First off, all of the engineers that I know that were driven by money quickly wound up in sales. Secondly, supply & demand has already started to drive our salaries down (coupled with offshore development of course). |
| Tue 21 May | Bella | First, I'm not taking into account future salaries. I was talking about events up to and including today, which is the same time period you said that programming was looked down upon. But, let's agree to disagree. Real engineers can laugh all they want at us, we made triple their salaries during the boom. |
| Tue 21 May | Hugh Wells | Sick, two points. Excel and Word must be useful to you in some way or you wouldn't use them. If they're not, use something else. It's your choice. Regarding the chemical analysis products you mention, it seems to me your problems are with the specific products and the specific developers of those products. See points 4 and 5 in my post. |
| Wed 22 May | Ryan | Hi Sick, Doctors kill people all the time. Amputate incorrect extremeties, give incorrect prescriptions. Lawyers give incorrect or illegal advice and wind up in jail. Accountants practice fraud (see Enron). 'Unbreakable' bridges collapse from minor earthquakes. No one thought that the twin towers could collapse. Brakes sometimes fail. The Concorde burst into flames in takeoff. What is your point? |
| Wed 22 May | Johnny Simmson | Ryan, the fact is that doctors, lawyers, accountants, & engineers deliver products & services with far less a failure & defect rate than we do. That is sick's point. Part of it has to do with the fact that people in all of these other professions can be held liable for shoddy work. We can't. |
| Wed 22 May | Hugh Wells | Systems in aviation and medicine ARE extremely reliable. Systems for word processing COULD be extremely reliable if people wanted to pay a lot more and wait longer. Users of non-critical software vote, by way of the market, vote for having low cost software. |
| Wed 22 May | Sick of sloppy work | Johnny Simmson makes a good point. Please note that I am not here to paint all Software developers, and the companies they work for, with the same brush. The original topic was 'too critical of MS'. My contention is that a company, any ompany, that has a dominant market share and issues this kind of aggreemnt: NO WARRANTIES. Microsoft expressly disclaims any warranty for the SOFTWARE PRODUCT. THE SOFTWARE PRODUCT AND ANY RELATED DOCUMENTATION IS PROVIDED 'AS IS' WITHOUT WARRANTY OR CONDITION OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OR CONDITIONS OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, Has no incentive to make quality products. They are immune from customer complaints and they have no competition, so there is no incentive to make a quality product. Look at the above agreement. It says you buy this software license but if the product does not work, you are on your own. |
| Wed 22 May | Joe AA. | AND... version of this with the same intent are issued by anyone that puts out software for multiple use - check all of the freeware, shareware, paidware, vaporware license agreements. They are all the same, saying in effect, that 'we are not at fault for anything concerning our product'. I hate it, sure... but it is not just microsoft, and it did not start with microsoft. It starts with what we like to call our 'society'. As long as we, as a society, support the notion that people with a clue are directly responsible for the acts of people without a clue, this is what will result. I remind you (one of many, too many similar stories) of the lady that sued McDonalds and won a healthy settlement after spilling hot coffee on herself trying to drive with it between her knees. She won because McDonalds didn't have a 'warning - this is hot' or similar label on a cup of coffee. The fact that she was too STUPID to figure out that coffee is supposed to be hot was judged not to be her fault. |
| Wed 22 May | John X | I remind you (one of many, too many similar stories) of the lady that sued McDonalds and won a healthy settlement after spilling hot coffee on herself trying to drive with it between her knees. She won because McDonalds didn't have a 'warning - this is hot' or similar label on a cup of coffee. This is OT, but here's some useful info on this case: http://groups.google.ca/groups?selm=3ACDF8BC.90FE3201%40hwa.net&output=gplain Most people don't know the details of the case. |
| Thu 23 May | dumbconsultant | the anti microsoft people posting here are pretty weird. Yes microsoft produces buggy code, but it isn't like YOU don't, smart guy. Microsoft did a few things that were GENIUS and ultimately helped the small developer: 1. they took something that isn't really meant to be sold as a 'product' and managed to turn it into something that can be sold like tables and chairs. 2. They lowered the bar for reliability 3. they popularized the 'no guarantee that this will even work at all' license If you are an independent developer, you should appreciate 1. because pretty much all a programmer can get paid for is hourly labor. after a while, even people that love programming get tired of doing it all the time, and it is real nice to have another method of obtaining money for your work. productized software is an amazing way of making more money. the costs of reproduction (and nowadays, distribution) are essentially nothing. so do something right a few times, work out the kinks, then just start selling the thing. you should appreciate the other two, because it makes it easier for you to make money and not be sued for when your software doesnt work. also, now if your software doesn't have tons of bugs, people will think you are head and shoulders above the rest... |
| Thu 23 May | pb | I love hearing people rant about the bugginess of Microsoft products when by virtually any metric (bugs per developer, bugs per line of code, bugs per customer, bugs per hour used, bugs for QAer, etc.) Microsoft would destroy every shop except for possibly NASA. |
| Fri 24 May | Nat Ersoz | Yeah, right. Speak for yourself bubba. Of all the unverifialbe statements ever made, this one ranks up there at the top. Let's personalize it a little, shall we: Your pathetic software shop sucks more than MSFT. Is that what you meant to say? Just wanted to make sure. |
| Fri 24 May | mike wilson | As part of a company currently realizing that a relationship with MS isn't quite the proposition they lead you to believe in the courting phase, lemme tell you it's a standard ploy - they wave business in your face, praise your work, then they come at your hardball. It's totally bi-polar, aggressive and more than slightly opaque. Yes they are successful, but whoopy-shit. Our experience with their Project Managers and other illuminati is that they do not seem terribly concerned with being a co-operative partner with their vendors or facilitating project success, and their organization is somewhat suspect in providing basic information such as completed specs on time and source materials, yet they have their hands out constantly. It has been an interesting trip with MS. I look forward to never repeating it. |
| The Importance of Editors... | Mon 20 May | Crimson |
| Ive been reading The Pragmatic Programmer by Hunt and Thomas and they make some interesting comments about something Ive never really thought about, but I sense is important and true nonetheless -- use of editors. Specifically, they believe you should master one editor and literally use it for everything. As a result, they say that productivity will jump up to 2-3 times its current level. They also believe that many students and early programmers are hindered early in their development by their reliance on IDEs. What are your opinions on this topic? Is it realistic to master and use only one editor at your job? For example, youre primarily a MS C++ house and thus use Visual Studio for a lot of development, but you often find that Visual Studio isnt a great editor for Perl or Python programs you find yourself often writing. In such a situation, is it better to dump the IDE and switch to a Windows port of a neutral editor like emacs or vi, or is it better to keep mixing and matching editors? Are you at a job where your forced to use a specific IDE, though youre mastered another type of editor? Do you think over reliance on IDEs stiffle productivity? Or do you think that editor usage is no big deal? Im interested in all opinions. |
| Mon 20 May | Joe AA. | In my opinion... I must admit I like using the Borland editor/IDE. Once I learned those wordstar keyboard commands... (ctrl-b, ctrl-k to highlight a block, ctrl-i to indent, ctrl-u to un-indent... etc), when I'm using another editor (especially MS) I realize how dependent on the BCB editor I have become... and yes, I have to stop and think... or search for a way to do the same thing... and if I can't find it in a short enough time, I resort to more manual means (delete, delete, cursor-down as an un-indent example). As for IDE's... I guess it would depend on the specifics. IDE's that really automate the mechanics of programming are a benefit to me. When I have to go into some other application (such as a command line compile) it really breaks the flow. Why would IDE's be 'bad' for a beginner? The only thing I can come up with would be the focus on the 'code' (which may not be so bad in a teaching situation). I have known coders that can code in a particular language, but have no concept whatsoever about compiles and linking. Not very well rounded in my opinion. |
| Mon 20 May | Adam | As someone who routinely switches between emacs, vi, and IDEA (as well as the editor built into mozilla for these web logs) I think you can be trained to switch fairly easily. Plus, when one goes away, for what ever reason, you can switch to another. But as a manager, yes, set up your team so they can work in what ever makes them most productive.... |
| Mon 20 May | Alex Moffat | Personally I try to use Emacs for all my editing. There are three reasons for this. Firstly I know the keybindings are so I find it very easy to make the editor do what I want. I could certainly retrain myself though, so I don't regard that as a big problem. Secondly, the large number of add ons and packages for emacs means that, for editing, there is generally always some package available that tries to help, and some bizare key combination that invokes a function that does just what I want. Thirdly, I like the extensibility of emacs. I've written some emacs major and minor modes and the ability to customize my editor is very useful to me. However, I do miss the 'I' portion of the IDE. The way in which the best IDEs package everything together and offer more advanced code navigation tools, GUI design tools etc. Personally I'd love an IDE that let you choose emacs for the editior portion. That sort of integration is difficult though. I tend to agree with previous comments that using an IDE could be detrimental to your early development as a programmer. At some point I think you have to have a conceptual model of, for example, the build/deploy process, that matches what is actually going on or else you can find it hard to debug any problems. |
| Mon 20 May | Crimson | Replies to Joe AA, Adam, and Alex Moffat. Joe AA: When they said that IDEs were 'bad', I think they meant that beginners got so used to developing within the confines some language specific IDE, that when they had to develop in a language or on a platform not supported by that IDE, their productivity took a big hit. The authors also mentioned that editors should be extensible so that you can plug in modules to handle various languages and this is something I can agree with. They made some other good points, but I can't remember or reference them since I don't have the book with me at the moment. -------------------------------------------------------- Adam: I switch between many editors too, but I haven't become an ultimate guru in any of them and don't feel my productivity is being maximized because of it. Also, I often have to stop and think things like 'OK, I'm in emacs now, not vi. So Ctrl-d is not gonna do what I thought it would'. However, I do think having at least passing familiarity with several editors is very valuable too. ---------------------------------------------- Alex Moffat: I know exactly what you mean about missing the 'I' in IDE (BTW, I'm also partial to emacs...well, Xemacs specifically) and that's why I wonder how other people handle this situation. As you said, emacs has lots of very useful modules that wildly increase the functionality of the basic emacs editor, but no one will ever mistake it for Microsoft Visual Studio, say. I also agree that being able to choose your editor would absolutely rule. |
| Mon 20 May | B | 'As a result, they say that productivity will jump up to 2-3 times its current level' That's just silly. Ever heard of Amdahl's law? If you spend 10% of your total coding time typing (high I expect) then even if your editor makes your infinitely faster at it, your productivity will only go up by 11% |
| Mon 20 May | Hugh Wells | This strikes me as one of those Rules that has no reason, and I suspect it comes from a narrow base. Sometimes there's value in preserving an IDE across different tasks; sometimes there's value in switching to a dedicated IDE or editor. On the second point, that use of IDE's can hinder the development of expertise, I think that's true. Developers certainly need to master their subjects as well as know how to use the IDE. I was bemused recently to see resumes claiming people straight out of uni were experts in ATL. It turned out they knew how to use the ATL wizard in VC++ and considered that made them experts. |
| Mon 20 May | B | Well, wizards anyhow! :) |
| Mon 20 May | Jeb | I use Visual SlickEdit for everything now. It's like emacs but simpler and doesn't seem as clunking. As for wizards, they give you something to start with and you usually remove everything. |
| Mon 20 May | Matthew Lock | I've noticed that when developing ASP applications I am much more productive in Textpad than Visual Studio. I find that Visual Studio babies you too much and keeps you from getting your hands dirty with the code. |
| Tue 21 May | Jack lives over there --> | Back in 93 when I was studying Pascal, C, and C++ I used Borland IDEs (I loved their help system). No such thing as Intellisense then, so everything you did required you to know the code. Given a project and a piece of paper I could have written the majority of the app (sure, there would have been a few issues but hey, I'm not a machine) . Now that I use VB regularly, having taken it up for different projects, I realise that my code muscle isn't what it used to be. You could say I've become lazy, I use that damn Intellisense for everything, hmmm, what were the params for debug.print? Down with fancy IDEs and WYSIWYG for newbies, to learn to code, you need to use the code. Jack. |
| Tue 21 May | Jan Derk | b wrote: 'If you spend 10% of your total coding time typing (high I expect) then even if your editor makes your infinitely faster at it, your productivity will only go up by 11%' You are right about the fact that programmers only spend a small piece of time typing code. However, a significant part of the developers time is spend not typing, but studying the code in the IDE. Any decent IDE: - has advanced debugging tools - will allow you to click a method to automatically open it in your editor - will allow you to click a variable and will bring you to the declaration - allows you to hit the help button to show context sensitive help. - etc, etc. It's features like this that greatly improve the programmer's productivity. However, I still take a good programmer using Notepad over a bad one using the latest MS/Borland IDE anytime. [which makes you think off course why a good programmer would use notepad in the first place] |
| Tue 21 May | Matthew Lock | I take issue with programmers using notepad. It's like programmers who use the mouse over keystrokes. I did some consulting for a bank once where none of the inhouse developers used anything except Notepad. Their jaws dropped when I showed them the power of search and replace using regular expressions in a decent text editor. They were doing changes through the files over and over again by hand. Doing tedious repetitive jobs by hand violates the three great virtues of a programmer: Laziness, Impatience and Hubris http://www.netropolis.org/hash/perl/virtue.html |
| Tue 21 May | Matt Woodworth | When I first attempted to learn java I went out and bought Visual Cafe. In just a few minutes I had a notepad-like app built with cut/paste and pull down help menus, etc. The trouble was, I didn't understand any of it. I ditched the editor and moved on to vi. That really helped me learn to code. Now I've come full circle. I prefer to code in IDEA (www.intellij.com) because it auto-complete my code, highlights syntax, debugs, etc. Also, it does it without robbing me of the learning oppritunities. A good IDE will make you more productive. However, some IDEs will rob junior programmers of learning experiences. |
| Tue 21 May | Alex Moffat | In reply to: Matthew Lock 'using the mouse over keystrokes' Research indicates that though using the mouse seems slower than using keystrokes it is actually generally faster, at least for some tasks. (and no I can't find a reference :) I find this true, even in Emacs, for tasks like selecting text. |
| Tue 21 May | Brent P. Newhall | In my opinion: Practically, of course, it's rare to live in a situation where you can use only one editor for everything. Where I work, we have to jump between Windows, Solaris, and Linux machines for a variety of work, and some of the code we run on Windows has to be run through Cygwin (a Unix shell that runs under Windows). Theoretically, though, it makes sense to use one editor as much as possible. If one can get used to all the features available in one editor, you'll be able to develop code much more quickly, because you'll spend that much less time figuring out how exactly search-and-replace works in *this* editor. So, in my opinion, pick an editor, get used to it, and try to use it as much as possible. You may not be able to use it everywhere, but the more consistently you can use it, the higher your productivity will be. Personally, I like to use vi in text-only environments, and the local simple GUI text editor in GUI environments (Notepad in Windows, StyledEdit in BeOS, etc.). |
| Tue 21 May | Joe AA. | I don't know about emacs Alex.... and maybe it is just a result of my own impatience, but it really bugs me to no end to watch someone (like when I am assisting them) fumble to reach for the mouse to select text. Like... they are in the middle of a line and need to delete to the end. So after 'very carefully' selecting the text to the end of the line, which might require several attempts, they then go up to the edit menu to select cut with the mouse. Shift-End and Delete for me. Sure, I point it out as easier, but they never remember (probably too global a statement). I shake when someone programs like they are playing a video game! |
| Tue 21 May | Nat Ersoz | Editors... My favorite editor of all time was 'brief', and to this day I use an editor which can emulate my somewhat re-done brief keyboard. It is essential that an editor support tagging for large projects. Otherwise there is no figuring out other authors' code. Emacs supports everything under the sun (and more), but I find it difficult to use. For $300 I bought a copy of SlickEdit. And for aother $100 you can buy a copy for whatever other environment you like (sorry for the plug). Excellent language context capabilities, and excellent beautifier, nice differencing tool, excellent tagging and xrefereneing. Again, sorry for the plug, but I've not found an editor which can do all this right out of the box (max 1 hour set up time). FYI, I do not work for SlikEdit, just a user. Also, a good editor, command prompt and the DDD/GDB debugger. Forget the heavy weight IDE. |
| Tue 21 May | ! | In my younger days, I started using editors like CodeWright and have found that I really don't like using most others, especially those in an IDE. Everything has been configured to match the way that I program, and it has been configured to support the languages that I want it to. While I could hook it in to the other tools in my environment, I find it easier to and more efficient to run the tools on their own. This way, you can always select the tool you really want to use instead of getting stuck with what the IDE supports. That said, I think the important thing to remember is to get the setup that works for you. If you want to do everything in vi, fine, but please don't inflict it on me. |
| Tue 21 May | Adam | Best Part of an IDE: Integrated Debugger. Step through your code. Runners up: Click from an error message or stack trace to the place in your code that casued it. Click from a varible instance to the type definition Revision COntrol |
| Tue 21 May | Alex Moffat | Joe AA. I agree. Using the mouse to select to the end of the line and then selecting cut from the menu is not good. In emacs Ctrl-K is just what you want. I was thinking more of the 'select from the start of the word in the middle of this line to just after the close paren near the end of some line 10 lines further down'. Keyboard navigation is just two slow for that to work well for me. In emacs it would be quite a few keystrokes, which could be reduced of course if you spent time working out in your head the optimal sequence, as opposed to left mouse button at the beginning, right mouse button at the end. Anyway, horses for courses I think. |
| Tue 21 May | Amir Kolsky | I think the productivity problem as it relates to IDEs is NOT the editors, but rather the insistance of IDE writers to 'Eat their own &younameit;'; i.e., build the IDE with the IDE. I would have loved to see someone (preferably NOT Microsoft) build a good General Purpose MVC IDE. I KNOW everyone says that that's how THEIR IDE is built (see JBuilder as an example), but the fact is that no real good IDE framework is actually used. A good IDE framework would be built SPECIFICALLY for the target OS (Bye bye Java. And I *am* a Java maven, but you know... Suitability to task et al). A good IDE framework would have an editor (plug your own). a debugger (for any language -- it's an MVC, right?) including exception handling version control interface (e.g., see JBuilder) coding assitance (e.g., function completion) scripting, loggin, document generation, UNIT TESTING, make (ant), as well as 12,231 other great features. The point is that the language differences, be the language Java, C++, C#, SQL, Rexx, Python or Spanish, will be delegated to the Model. The rest of the stuff is pure IDE and will be common across all models. You will be able to use this IDE for other things, as the model does not necesserily REQUIRE debugging, so you can use it for, say, word processing or spread sheets, or maintaining recipes. So, hey, we suddently get our unified single editor as a by-product of our IDE Framework... |
| Wed 22 May | Andrew Simmons | In reply to Alex Moffat, you can find some pointers to research on the mouse vs keyboard at: plan9.bell-labs.com/wiki/plan9/Mouse_vs._keyboard/index.html I'm not really sure they are that relevant to the use of the keyboard in editing programs, though - more to do with the pros and cons of function keys in word-processors. Personally, I really like the command language in Rob Pike's Sam editor, but can't get along with the mouse interface - plus Sam tends to get understandably angry when you run it under Windows 2000. Can anyone recommend an editor with a decent command language and regular expression interpreter, and a standard Windows look and feel? I've tried UltraEdit, but the menu layout drives me crazy, and I really want a single command window where I can type arbitrary commands if I need to, not a separate dialog box for each function. |
| Wed 22 May | Matthew Lock | Textpad doesn't have the ability to enter commands directly, but it has good regex support and the standard windows look and feel. One thing it's lacking though is a macro editor. You can record macros but not edit them. http://www.textpad.com |
| Wed 22 May | Nat Ersoz | Both SlickEdit (I know I sound like a commercial) and Codewright have powerfule extensibility features. SE uses a C style macro language while CW uses DLL's to exend the editor (I haven't used CW in 4 years now, so this may have changed). SE also has versions of their editor which run on Linux, Win32, Solaris, AIX, and others (this is quite useful, IMO). |
| Wed 22 May | X. J. Scott | Responding to the original questions: > The Pragmatic Programmer A well designed book but do not believe everything they say. >they believe you should master one editor and literally use it for everything. That section in particular I thought was foolish. > As a result, they say that productivity will jump up to 2-3 times its current level. This is certainly not true. >They also believe that many students and early programmers are hindered early in their development by their reliance on IDEs. I seriously doubt this is generally true. >Is it realistic to master and use only one editor at your job? Places where I have worked I have had complete freedom to choose my own editor, as has everyone else. After all, we're editing plain text files. On the PC, I use CodeWright almost exclusively as it does everything I want. On Unix, I use emacs exclusively as it does everything I want. On Mac I use several different ones as there is not one that does everything I want. Fortunately all of the Mac ones are similar enough for this to be pretty transparent. Switching from emacs to the Mac though requires a complete context shift. I might have several editors open on the mac at any one time to create the illusion of one complete editor. >Are you at a job where your forced to use a specific IDE, though you're mastered another type of editor? Wow! Wouldn't that be really dumb for a manager to demand such a thing? Is anyone plagued by such a circumstance? Frankly, it seems almost unbelievable that any manager would think forcing plain text editor choices would be a good way to spend his or her time. > Do you think over reliance on IDEs stiffle productivity? Not at all; the opposite is true. I can create giant make files using esoteric features and am quite glad that IDEs take that chore away from me. I am thrilled when I type 'sttaic' and immediately see the typo because it is in the wrong color. I am excited no end when I double-click on a function name and the file with that function in it opens up and scrolls down to where it starts. All these things save a lot of time and don't make me stupid. Does trying to remember where every function in every file is make me more productive than having the IDE keep track of that for me? Of course not. > Or do you think that editor usage is no big deal? Pretty much. |
| Fri 24 May | Frank Mair | All the software that I write is for unix/c++ systems, but I have not come across an editor that is superior to the one built into VS.NET.. it blows away anything else I have ever tried (including VS6, Source Navigator, Sniff, Xemacs, etc) and the clinching factors are the integrated object browsing, jumping to definitions/declarations, collapsing blocks of code, auto hiding windows, intellisense, the list goes on. The productivity gains from all the included features is unmistakable. The colleagues I work with still use vi or xemacs, with the more daring ones using nedit, and I have to laugh when they try to find definitions or move around their code. They usually end up asking me where something is, or what a method is called..... |
| Fri 24 May | Chris Winters | Frank Mair said:
< |
| What would you choose ? Big Company or Startup ??! | Sat 18 May | JD |
| Hello Everyone, Its 2nd time I am posting a topic here. and this time I am hoping that I would get replies which will help me in making some decision. Its crucial and its about my job. No no.......................its not like I dont have job. ;) Situation is I have TWO offers and I am finding myself in tough situation of not being able to decide which one to choose. I am a *kinda* fresher ( its been 7 months I have finished my grad in Electronics Engineering). In my final year of college I got selected in Infosys ( http://www.infy.com, TOP IT company in India). But by the time I finish my grad, it was recession in IT and Infy postponed my joining indefinately. So I was forced to search for another job. It didnt took me long and I found myself working as systems engineer in One broadband company. Its a part of one MNC which operates in 23 countries !! [ I am not revealing company name due to some concerns ] Its a great setup that they have done here in Surat (my home town) and I find myself lucky enough to get chance in MNC such as this !! The only hitch was my salary which was way too low. Only 6k. But now after my 6 months, I am going to get 100% hike !! Its been confirmed by GM of Finance/Operations. I am doing good and out of nowhere Infy has called us up !! I am suppose to join on 10th June. 1 month from now. I am suppose to join in Hyderabad ( Hi -tech city of India) . Now my confusion is to whether join Infy or stay in Current company. Now you may say go to Infy ,big company , big things , big projects, right ? But there are few things. I am getting really good exposure in my current job and has made myself a place in the company. CEO of company just came to talk to me on last Sunday we even went for lunch..and he offered me salary equivalent to Infy. That is 3 times my current salary !! Also I am getting chance to work on Metasolv, Infranet Portal ( Which I love MOST and I am administrator of it in my company ), TIBCO. All Enterprise level products. I have GREAT boss and I mean it. I am given chance to design solution from scratch. They tell me a problem. Then I decide which technology to use, how to implement and deployment scheduel. Till date I have worked on 6 projects , latest one being Video mail. [ I have implemented it from start to end.] I wonder if I would get chance to do same thing in company as big as Infy. There I would be a *small* part of BIG project and I wont even know head and tail of it. Kinda black box , isnt it ?? Here projects are not that BIG but certainly they are good enough and I really enjoy giving SOLUTIONS to PROBLEMS. I have 100% job satisfaction here. Now Infy has name, they would give me training, they would send me for off shore projects. But then..then what ? WIll I be another coder amongst those *thousands* out there ? How long it would take for me to again make same position in Infy ? Is it even possible ? There are numerous advantages too. They would be first giving me extensive training on varioius technologies, I would have offshore projects to work on, would be going to US/UK and all.. [ One of my dream is to go abroad ]. but what would be my profile ? What if they put me in testing team ? [ Me being more of developer , I wonder what I do in testing team. ] Now what do I do ? Shall I join BIG company or stick here in a startup ?? I am LOST. Please help. JD P.S. : I wonder if joel can spare some time and suggest something. |
| Mon 20 May | RK | JD my little advice. I joined a small company as a fresher @4 yrs ago after being rejected by BIG companies including Infy. Now I'm a Project Leader with 2 shrinkwrap commercial products to my credit and churning out new once every 6 months. I have now hands on experience on every aspect of Software development. In some I'm total expert (sorry for the boast but I am). I don't think I would be this far if I was at infy or BIG cos. Its not that I didnt get offers. But I had a goal, target and ambition in life. Its how you look at your carreer and what you want to be in say next 5-10 yrs. So if infy fits your needs go. If your present company suffices stay. The decision should be on this basis and not on BIG NAMES. |
| Mon 20 May | Johnny Simmson | 'In some I'm total expert ' Just curious, but what are you an expert in after only 4 years of experience? |
| Mon 20 May | RK | I'm an expert in text processing. Still curious. take a look at the 2 products which are released, here's the URL www.recosoft.com and click on VINC and VEM. |
| Mon 20 May | tangram | JD- What job do you want to have after this one? Which one will get you there? |
| Mon 20 May | Doug Withau | Think about how your resume will look after six more months. Where you are now: Completed start to finish project X, Y, Z. Became team leader. References from head of IT and CEO. Even if the start up fails, that says smart and gets things done. Compare to: Three months training and then on project team for project A. Who would you hire? 'There is not much danger that real talent or goodness will be overlooked long' Louisa May Alcott. From my Celestial Seasonings tea bag. |
| Mon 20 May | Brad Clarke | I've been working for a large company for the last 10 years, and I absolutely HATE IT!!!! Prior to that I worked in the IT shop of a small financial institution and loved it. The difference is that in the financial company, I had my hands in all aspects of the job. With the big company, I am given a tiny piece of a larger piece of work. It's not enjoyable. I am in the process of looking for employment in a smaller company that allows me to get back to what I had before. Stay where you are, and forget about INFY. |
| Tue 21 May | Nope | here is my advice, for what it is worth. do wtf /you/ want to do, and don't take too much notice of those who are saying 'go to the big company, small co's suck'/'go to the small company, big co's suck'. all companies suck, but some suck less than others; i don't think we have enough information to say one way or the other which one is better or worse. furthermore, the things that make companies good or bad can mean more or less to different people. |
| Tue 21 May | Matt Woodworth | I've worked in large and small companies in the US. (I'm American) Large companies can offer large problems. I've worked on systems that truly require more complex solutions because we have scalibility concerns that my smaller companies couldn't offer. However, smaller companies offer a broader challenge. When I need something done with the OS (I'm a programmer) I open a case for the sys admin. When I need something done with the database, I open a case with the dba. In my smaller companies, I was the sys admin, dba, web master, and developer. Sometimes I miss the exposure to all those systems. Anyway, I wouldn't worry about the brand name of the company you work for. I would look at the money, job security, benefits, and the work. |
| Tue 21 May | Brent P. Newhall | To counter Matt Woodworth (no offense Matt): Big companies offer big problems. Small companies offer big problems because *every* problem is a big problem to a small company. :-) Seriously, I've worked in a big company, a small company, then another big company, then another small company. They each offer unique advantages. Big company advantages: Larger companies are stable. You know exactly what you're working on. You can bet you'll be working on that for quite awhile. There are a lot of opportunities within the company if you want to significantly change your job (there's almost always a job opening for practically any kind of work somewhere in the company). There's comparatively little employee turnover, so you get to know your coworkers very well. If you're working in a good group, you can make a lot of lasting friends. You'll get big-company benefits: very good insurance and savings plans, a cafeteria, snack machines, etc. Big companies tend to be low-stress. Big company disadvantages: They're resistant to change, which affects almost everything. Bad co-workers aren't fired easily, inefficiencies aren't addressed quickly, and so on. The problems with big companies are pretty well documented, so I won't belabor them here. One thing: Raises tends to comparatively small. Small company advantages: You can learn a huge array of new things in a breathtakingly small time. Small companies have an energy to them which can excite and inspire. Change can occur very rapidly; if something isn't working, you can fix it easily. Small companies tend to pay well. Small company disadvantages: It can be surprisingly difficult to move into a role that the company doesn't see a need for (if you're a programmer but want to become a DBA, there may be just no way to do it). A small company's more vulnerable to economic slumps and/or customer dissatisfaction, so there's a much greater risk of being let go. Small companies are high-stress environments. Personally, I highly value the stability that a big company offers, but I also love the energy of a small company. Which is better? Neither is better; they're just different. |
| Tue 21 May | Jutta Jordans | JD, without getting into the big company/small company discussion: You sound pretty content and even happy with the job you have at the moment. If you do not have to fear that your current company will close down in a few months time, I would stick to it. Have fun, |
| Tue 21 May | DC | These decisions are always impossible. There seem to be 3 decision methodologies that work, which one you use is a character thing: 1. Follow the money 2. Follow your heart 3. Stay where you are on the 'better the devil you know' principle |
| Fri 24 May | JD | Thanks a lot for all the feedback. I got inputs from other forum at Devshed [ where I hang around more ] and there were some *family* factors affecting......so ultimately I will be joining Infosys. Thanks again, JD |
| eXtreme, life-altering pair programming | Fri 10 May | Sammy |
| I thought it would be interesting to point this Passage out. This spontaneous pair programming session occurred between Richard Stallman and Guy Steele. We sat down one morning, recalls Steele. I was at the keyboard, and he was at my elbow, says Steele. He was perfectly willing to let me type, but he was also telling me what to type. At the end of: [ http://www.oreilly.com/openbook/freedom/ch06.html ] |
| Mon 20 May | Richard | Tony, Ian, you summed up a lot of the fears I have with Pair Programming. I have seen jobs posted where they really advocate the pair side of things. It comes off a bit creepy because I can't shake the feeling that managers adopt it as some cheap way of cutting down on resources: PCs, desk space, phones. Also PP would cut down on employees personal use of internet/phones/email etc. Just seems a bit ugly. I got friends who have done PP, and very successfully too, but PP was a tactical decision to a specific problem, not the default MO. If anything PP is more resource expensive: the members need their own space and possibly a shared work area also. I want to appreciate PP, as it could be really useful where I am working now as a way of mentoring & sharing knowledge (and getting code in decent shape). Might even practice it myself on a new project. I just can't shake the feeling that it is used for its side effects, and that any attempts to get it to work right by calling in resources would eb viewed with suspicion. |
| Thu 23 May | Amir Kolsky | A couple of comments, 1. If you want to read on some academic research into pair programming, Laurie Ann Williams http://collaboration.csc.ncsu.edu/laurie/ wrote her dissertation http://www.cs.utah.edu/~lwilliam/Papers/dissertation.pdf on the subject. 2. If you look at how student assignments in collage / university are often allocated and fulfilled you'll notice that students often engage in PP without calling it by name. So, it *is* a natural way of collaborating, albeit not for extended durations. |
| Fri 24 May | Nat Ersoz | Amir, I read those articles and replied in another post, which I'm going to post here (sorry for the redundancy). ===== However, reading through the specific studies, much of the code and evaluation was done in a university setting. The exceptions to these being Ken Beck's and cohorts already documented experiences. For example, I am skeptical about the U. Utah experiment which found that PP resulted in only a 15% increase in man-hours worth of development and a corresponding 15% reduction in code defects. The first thing that should be a tip-off is that the time scales are measured in elapsed time. If this is indeed the case then it takes a team of 2 more time to complete a task than a loner. In the best case, pairs completed the task at 80% of the loner. That means a more than doubling of programming assets for the task. Our company cannot afford that sort of productivity hit. Secondly, the case for XP assumes that unit tests don't exist outside the non-methods universe (OK, I'm exagerating). Nevertheless, how does someone deliver code that has predefined performance criteria (as was the case in the Utah study) and not get a perfect score? How does this happen? You know the test scoring criteria, and yet you do not test to that criteria? Again, I'm suspicious. Finally, I agree that collaboration is a powerful tool (hence my ramblings in prior posts over the virues of cubes over offices). It is not my attempt to discount collaboration. However, I found the studies to be far too friendly toward pair programming rather than maintaining a healthy skepticism. |
| Usability guru designing a nightclub | Wed 22 May | Lawrence Attrill |
| Im looking for the quote about if a usability expert designed a nightclub, it would be well light, the music not too loud.. etc, etc. I cant remember if this was posted on Joels website or not. Can anybody help? Thanks in advance, Lawrence. |
| Wed 22 May | Jutta Jordans | I think it is a quote from Joel's 'User interface design for programmers' book, but I did not find it in the online version, maybe it is in one of the seven brand new chapters :-) Have fun, |
| Wed 22 May | Matt Christensen | It is indeed from Joel's book. The full quote is: 'Usability is not everything. If usability engineers designed a nightclub, it would be clean, quiet, brightly lit, with lots of places to sit down, plenty of bartenders, menus written in 18-point sans-serif, and easy-to-find bathrooms. But nobody would be there. They would all be down the street at Coyote Ugly pouring beer on each other.' Don't thank me, thank google. - m |
| Wed 22 May | MarkTAW | I believe that's from Steve Krug's book 'Don't Make Me Think' but I'm not 100% sure. |
| Wed 22 May | MarkTAW | oh... nevermind... |
| Wed 22 May | Anonymous Coward | That's an amusing quote, but it never made much sense to me. Why would you assume that brightly-lit surroundings, plenty of room to sit down, etc. would enhance the usability of a nightclub? Maybe a book store, but not a nightclub. Seems like a straw-man argument to me. If you did your usability research correctly, you'd end-up with Coyote Ugly, not the example described by Joel. |
| Wed 22 May | Leonardo Herrera | See http://www.dnalounge.com for an example of usability being applied to a nightclub. They took 2 years to finish 'refactoring'. BTW, this is Jamie Zawinski's (from Netscape fame) joint. |
| Wed 22 May | MarkTAW | Nice looking club. The new floor plan looks like an improvement. Night clubes are one of the few instances where difficult to see = good, except when you're talking about the stage. Anyone who's been in a bar at 4am when the lights get turned on knows exactly what I mean. |
| Thu 23 May | Charles Miller | The DNA lounge is something of a double irony. The first irony is that Zawinski quit Netscape because Mozilla hadn't released anything after a year, bought a nightclub, and then spent _two_ years redesigning and rebuilding it before it served a single drink. The second, of course, is that Mozilla 1.0 still hasn't shipped. |
| How often do you delete code? | Tue 21 May | Mark Alexander Bertenshaw |
| I am currently going through a whole lot of code which dates back to 1999, and has been much ammended over many iterations of bug-fixing. And a lot of that code is redundant and dead. I mean - there are sections which have four levels of commenting out (I ought to mention that this is a VB application). I cant take it any more - it is so ... messy. The temptation is to strip out all that stuff, effectively giving the code a good lufer-type scrubbing, peeling off all that nasty crusty epidermis, to reveal glowing pink ASCII (no, I dont really have my IDE set up that way). And that is before doing actual analysis on how to remove functional redundant stuff. Of course, what stops us from doing this is simply one thing: fear of screwing up working code. I mean, you might just - just need that section to deal with memory problems with ActiveX Documents in IE 3.0 again. Personally, as long as you make careful use of code tools, and use Source control, there should be no problems. So - how often in the software cycle do you actually delete code? |
| Tue 21 May | Claus Christensen | I must confess I don't usually throw out already out-commented code as well. It's easy to rationalize that we are not throwing that useless clutter out in fear we might overlook that single statement not commented out in the midst of all the comments. But it really comes down to that 'never touch a running system' feeling deep down. It all reminds me of that famous 'magic-more magic' switch story (http://burks.brighton.ac.uk/burks/foldoc/15/70.htm). Always keep your code in the 'more magic' position or get out those wire cutters. :-) |
| Tue 21 May | Matthew Lock | Great story that magic one! |
| Tue 21 May | Matt Woodworth | I've always felt that cleaning up the code is important. I like to comment it out and date it. If I can see that it's been commented out for a few months and it hasn't had any problems, I'll delete it for good. Of course, a good source control system is important. However, even if I didn't have it, I would still clean up the code. |
| Tue 21 May | Ori Berger | I do the same as Matt - that is, comment (or #ifdef) things out with a date/version tag, and then after a while if it's still unused, delete it. However, I _always_ leave a comment in the file (usually at the top of the file, unless the deleted section is in the middle of a routine) what was the function of the deleted code. Even though the revision control system maintains old copies, people don't review it unless they know what they're looking for - It just has too many details. Assuming the needs come back, if someone else is maintaining the code, they won't know where to find the (already working) code section in the past. So be kind, and give them a clue - it's not going to be yourself forever. |
| Tue 21 May | Johnny Simmson | I used to work on a very large system that was under constant change. You quickly learned never to delete code that was commented out. I don't care if it had been commented out for 8 years, you just didn't delete it. What you need is a good editor that can toggle comments on and off. |
| Tue 21 May | Tony | I like to delete stuff too, (as you said) with version control software you can always get it back. For VB I use code analyzer (aivosto) and it gives you a listing of dead code/variables etc, I always do this at the end of a project and I am ruthless, but then I've got the type of personality that likes a completely empty inbox etc, less is more in almost all instances for me. Removing dead code gives the next developer a chance to see whats going on. |
| Tue 21 May | IanRae | There is a strange reluctance to delete code. It feels like one is throwing out a valuable heirloom! But I can't actually recall ever needing to uncomment some of this 'saved' code. Do other people have stories of how commented out code saved the day? |
| Tue 21 May | Joe AA. | Commenting out and not deleting unused code is the practice that causes software to (eventually) 'be maintained to death'. I personally like to delete as it is more in like with what I consider 'proper refactoring', extends the effective maintainability life of a system, and generally improves the overall quality of a change (e.g. by not coding in a condition or other handling thingie for something that is obsolete - as a unused function when all of the function calls have been commented out, but (bad practice as it may be) the function sets a global switch)... But I have fought this practice and usually don't win. These are the excuses: 1) All code is valuable and must be preserved. 2) If it wasn't important it wouldn't have been there in the first place and I might need it again. 3) History of prior changes might be significant (ignores the possibility of any any radical changes) 4) You can't see deleted code in a code walkthrough (even though we did none). 5) If everyone deletes unused code then someone might blame me for deleting something I didn't. 6) I might be seen as not working as hard as I can because deleted code has nothing to show for itself. On one project, I remember one 5000 or so line module that was over 80 percent commented code. But commented lines happened to be included in the 'lines of code' count for the application and several managers (especially those from the consulting company) thought it was impressive enough to maintain the practice of commenting out code so that the LOC didn't get reduced. |
| Tue 21 May | Jutta Jordans | >Do other people have stories of how commented out code saved the day? I would not call it saving the day, but with some undecisive customers, commenting code out and back in proofed to be a quick way to adapt to their changing wishes. ('I think I would like the print button in after all'...) I also like to leave debugging and profiling code in as comments. I am no friend to #ifdefs, because they confuse me a lot. When I comment something out, it turns green in my editor and that is plain to see. #ifdefs tend to become invisible, especially if the code spans more than one screen page. When I actually change code, I normally do not leave the old version in for a longer time. Once the new way has proven to be working, I delete the old code for good (still have it in the source control system for emergencies, of course). Sometimes I am even too eager with that, at least I remember two or three times when I had to fish the older version out of source control and wished I would have left it in which would have saved me the effort. Have fun, |
| Tue 21 May | Nat Ersoz | I 'kill' code all the time. I almost always have to inherit something from another author for at least part of any project. At the outset, I establish the following rule: If I can eliminate it, I will. Why? Because if it can be eliminated, then it serves no useful purpose. Code that serves no purpose will only come back to haunt you. It often contains dependencies and behavior you do not know about. This goes to the subject of quality. One reason companies went to 'just in time' inventories back in the '80's was to expose weakness in their process. If a supplier was consistently late in delivering goods, then it exposed the problem - rather than compensating for it (by compensating, the company would stockpile inventory, masking over the issue). In software, if a glob of code is poorly written and not understood, then the first thing to do, IMO, is break it (time and resources permitting). Unravel it, deconstruct it, understand it, re-write it and document it. And then, once you've got your solution and verified it, put a bullet into the fellow's head who wrote it poorly in the first place. Simple... |
| Tue 21 May | Peter Ibbotson | Depends... If the old version has now been replaced with a new 'better' version. Then I'd delete the old code after a short while. Commented out debug cruft (e.g. debug.print for VB) I'd tend to leave in as one day you may want it back again. |
| Tue 21 May | David Clayworth | Our coding standards actually say that there must be no commented code when checking code in. Going back to old versions is what the source code control is for. |
| Tue 21 May | Jim Lyon | Old commented-out code is generally worse than useless. If it's been commented out for more than a few months, the chances of it actually compiling and working if you uncomment it are nil. I've read *lots* of code. My usual approach when reading code with lots of commented-out stuff is to make a private copy and delete the weeds before reading. Remember that if you want your code to be an asset and not a liability, then it must be readable and understandable by those who follow you. Commented-out gunk in the middle of the code usually defeats these objectives. |
| Tue 21 May | skautsch | I fully subscribe to deleting old code and letting the version control system do its job. At my present shop, I am *not allowed* to delete code and it drives me nuts. (I should note that I've programmed twice as long as anyone here who is responsible for these types of rules.) Most of the systems that I maintain here contain around 50% dead code. The worst is the presence of several variations of the same class, only one of which is invoked by code that is not commented. I have on many occasions wasted an hour looking for a class that was responsible for a certain task because the route was so twisted with this stuff. (I cannot always begin by stepping through code because I can never attach all of the devices that we communicate with. I generally have to do some winnowing of the problem 'by hand' before I go to the storeroom to get the devices I need.) The basic feeling of my coworkers is that all of the pain is worth it because it lends us job security - i.e., no one could possibly come in off the street and maintain these systems. Since I was out of work last year for five months I do sympathize a little, but I'd rather work in a good environment and not suffer the productivity hit every time we hire someone. |
| Tue 21 May | Nat Ersoz | David and Jim mention that they abhor commented out code (paraphrase), which I tend to agree with. But, just now, to debug a problem I uncommented some very useful debug code, which helped solve the problem. Hmmm... |
| Tue 21 May | Zwarm Monkey | At my work, many people leave old commented code. I can't stand it. The old code was commented out because it DID NOT WORK, but I still have to look at it everyday. It takes up valuable screenspace and my thoughts (as I mentally skip over it). I think there is one case where commented code is reasonable. If there is a very subtle (perhaps OS-specific) bug, including a snippet of the old buggy code PLUS a big comment explaining why it won't work so don't you go try this. In this case, pseudo-code is probably preferable to real code, otherwise some dufus will try to uncomment it and reuse it someday. ;-) Like someone else mentioned, people treat old code like an heirloom. Someone wrote that code once upon a time, so it is reasonable to assume that someone else could recreate it one day if necessary. Let's make smaller programs and reduce our KLOCs! (of course, the same project I work on has many functions that are thousands of lines long EACH.) |
| Tue 21 May | Adam | How often do you clean up your desk. Don't put away that book, I might need it! |
| Tue 21 May | Marc LaFleur | I almost always delete dead code. As someone else sugested, I also keep a section at the top that talks about any functions that were outright removed. I don't bother if it was just a block of code within a function. As for debug info, who has debug code? I mean, gee, can't you just write it correctly the first time? :P |
| Tue 21 May | njkayaker | Clearly, there is no 'one size fits all' answer to this question. Sometimes, though, it's quite clear that certain code can be deleted such as code related to a library change (e.g. proprietary FTP library to winsock, 16bit Windows to 32bit Windows). On the other hand, keeping commented-out debug code around might be useful since the debug code is not necessarily 'obsolete'. In many cases, just keeping the commented-out code around is just plain confusing. If the new code works, who really cares how it was done previously (incorrectly)? The commented-out code also makes simple 'grepping' much less useful. Typically, I don't keep commented-out code around because the old code has no value (that's why it was replaced). I might keep commented-out code that relates to 'important' calculated results (e.g. pension amounts) since knowing the history of these kind of changes might be important in understanding how the value changed. |
| Tue 21 May | Amir Kolsky | Interesting thread this... This is where Unit Testing can be used to save the day again. Note that writing unit tests for existing code is NOT for the faint of heart. However it's a great exercise for someone who wants to understand what a piece of code does. Moreover, the tests also document the code and bring to good use all the comments placed in the code akin to /* we added the c == 5 test to check for bloob-prats in the zweegs. */ With that comment, you are sure to make a test case with bloob-prats in the zweegs... Anyway, once you're done with writing the tests and you are satisfied that they do what you want them to do -- unit test the code -- you go about REFACTORING the code, which basically means you can do what the hell you want to do... As long as the tests run, since if they run -- the code does what you wanted it to do. |
| Tue 21 May | Ori Berger | I'd like (again) to quote Edsger Dijkstra in saying 'A line of code is a liability, not an asset'. Every compilable line of code, whether commented or not at the moment, is a liability - you read through it when maintaining the code; You sometimes update it if you update the code (heaven help you if you don't, and later assume the code just works). Measuring productivity by lines of code is similar to measuring value of a project by its cost. Not really smart. |
| Wed 22 May | John | I think Amir is on the right track. The only value in old code is that it might help you understand the history of development of the module. That, my friends, is why you use normal comments. Don't just comment out the old code, preserve the algorithm and the intent in a descriptive natural language of your choosing... and no, obscene blue streaks do not constitute good comments. |
| Thu 23 May | John Burton | The other similar thing are people who insist on putting in comments saying why they changed something. Things like :- // Changed i to i-1 to fix off by one bug Nice, but the bug isn't there any more so who cares what the code used to do and how you fixed it. Usually people who do this put their initials and the date of the fix in too. As if anyone will ever care. I just delete this kind of stuff whenever I see it. |
| Thu 23 May | Mark Alexander Bertenshaw | John - I partly agree with your sentiments about bug-fixes. Well, I'll have to since I have deleted a whole load of such things in the last four days. However, there are circumstances where these things are worth preserving, just as a warning in case people feel like 'optimising' what seems that pointless code. |
| Project Management Software | Mon 20 May | Paul |
| Can anyone recommend some good project management software ? Ive tried MS Project, which is nice but aimed at larger more complex projects, and often behaves unintuitively (imho). What Id like is just an easy way to track an hierarchy of tasks, with timescales, and an equally easy way for me and the other developers to log time on each task, with the output being a gannt schedule chart. Preferably open source, and Win32 rather than web based. Am I asking too much ? Thanks Paul |
| Mon 20 May | Adam | Use excell If Project is overkill, so will everything else |
| Mon 20 May | Adam | Sorry, excel |
| Mon 20 May | Herbert Sitz | This topic has been discussed before on this board. You might want to take a look at this: http://www.rik.org/articles/tasktracker.htm |
| Mon 20 May | Matthew Lock | Joel's written a nice article a while back on using Excel to manage projects: http://www.joelonsoftware.com/articles/fog0000000245.html |
| Tue 21 May | Nat Ersoz | Some columns I've added to Joel's spreadsheet to make days of week calculations- which helps fold your work back into the gant charts that the PM drags around :). Add column estimated end data: =int((weekday(D3,2)+G3)/7)*2+D3+G3-1 Add column 'Elapsed', my column H, used below =now()-D3-int((weekday(D3,2)+G3)/7)*2 Add column 'Remain' I15=if(J3<100,G3-H3,'') Explanation: Excel is almost as disgusting a 'programming language' as VB, but at least Excel serves a useful purpose. Anyhow, as you might guess, this is for ROW 3. Column 'D' is the start date Column 'G' is the estimated days to complete work on task. Column 'J' is the percentage complete column Hope this is useful... |
| Tue 21 May | chris | >Excel is almost as disgusting a 'programming language' >as VB, but at least Excel serves a useful purpose. ... >Hope this is useful... That comment wasn't useful. |
| Thu 23 May | Nelson Thomas | A nice inexpensive applet for managing/displaying a project's status is JustProgress found at http://www.mstay.com/jp10_ab1.html One nice feature is that it is driven from a simple text file which can be maintained programmatically from a database or whatever. It works for me and some of my clients. |
| The funniest thing about RealNames | Mon 20 May | Daniel Earwicker |
| The one usage example always given is that the name Ford Explorer would take you right to the official homepage of that model at the Ford Motor site. But, erm... try this: http://www.google.com/search?q=Ford+Explorer&btnI=Submit (BTW, the btnI=Submit part is like pressing the I feel lucky button.) |
| Mon 20 May | Leonardo Herrera | That's why lots of people -included me- think that Realnames' proposal is just a scam. They insists that the 'keywords' method was crucial to AOL's success in the past. Google's has come to bring order to chaos, and I believe it will the de-facto standard for name resolution. |
| Mon 20 May | Zwarm Monkey | My computer-illiterate parents just bought a new Windows XP computer. They don't know the difference between a URL, a search, or a keyword. When I tried to show my parents how to use Google, they started typing URLs into the Google search form. Jakob Nielsen claims this is a very common problem. I am a 'power user' and LOVE the IE Google Bar. When I was setting up my parents' new computer, I considered turning off IE's AddressBar and secretly replacing it with the Google Bar (and only the 'I Feel Lucky' button). Google is THAT good! In the end, I decided against this, but I'm still considering it. Perhaps I will try this experiment on myself for a few days. ;-) |
| Mon 20 May | pb | Of course keywords are important to AOL...it's the *only* address scheme in AOL! |
| Wed 22 May | Nick Hebb | Maybe AOL should call itself Asian On Line ... http://www.theregister.co.uk/content/6/25369.html |
| Thu 23 May | programmer | At the risk of revealing myself to be a complete idiot, what does Google's 'I feel lucky' button do? |
| Thu 23 May | anon | The 'I feel lucky' button redirects you to the first page in the search results for the search term. |
| reply to "updated topics first" | Mon 20 May | Joe AA. |
| Mon 20 May | Joel Spolsky | I like it this way, that's why I'm not changing it. But people ask about this every few months so let me reiterate why I like it this way. If we were to sort topics by 'most recent reply', this would cause several things which I consider to be detrimental to the quality of the discussion. (1) the religious flamewars that newbies find most interesting to argue about would be constantly pulled to the top every time a newbie walked into the group and started reading topics from top to bottom. Discussion would be repetitive and boring to regular visitors. (2) the order of topics on the front page would change constantly, making it hard to remember visually where you've been and what you've seen and which article is which. As it is by having a nonvariant order of articles on the front page it's easier to remember a mental map of the discussion. Basically I'm long believed that small changes to the UI of a discussion forum make big differences in the quality of the discussion. There are a lot of decisions in the design of the Joel on Software forum that are designed to create higher quality conversation: * quoting is extremely hard (I don't even show you the post you're replying to) because quotes make the topic more boring to read. When I'm reading a topic from top to bottom and poster number 5 has quoted poster number 4 extensively, then I have to read the same words again and again, and it's more boring. Instead of quoting, the software encourages you to reply directly. This reads better and makes the quality of conversation sound less repetitive and banal. * there's no checkbox to 'email me with replies.' Yes, this would be super-trivial to add. But it creates freeriders. I want people to keep coming back checking for replies, and, while they're waiting, maybe contribute an answer in another thread. Freerider checkboxes result in ghost town discussion groups like those boring usenet video driver newsgroups where every post is a question to which nobody is listening or replying. * there are no threads. Besides the fact that threads are a programmer-centric way of viewing the world, exhaustively persuing every possible branch of the tree doesn't make for good conversations. If your post doesn't belong on the main trunk, you can put it in a new topic, or, even better, put it in parentheses or something. The lack of threads is what makes most topics on these discussion boards read so well from top to bottom and keeps people from repeating what other people just said. Basically I'm very happy with the quality of conversation we have here and the choices made in the way the software works were taken very deliberately with the goal of creating a high quality of conversation, and I like it that way, and that's why it's not going to change. |
| Mon 20 May | MarkTAW | Joel, you forgot 'Everybody else does it the other way, so doing it this way is refreshing.' If this was a coffee house people would be asking you to serve the same stuff Starbucks serves too. |
| Mon 20 May | Martin L. Shoemaker | This points out an important reality: the end user for this board is Joel. Oh, of course, the rest of us are users, too. But Joel signs the checks (metaphorically). Think of this as a meta-lesson in the politics of requirements: the user you have to satisfy FIRST is the decision maker. (And in this case, the decision maker is also the implementer. We ain't gonna see a change in this one...) Actually, I find that I come back to this board more frequently than I have other boards in the past. I don't know why, but it must do something right. |
| Mon 20 May | Joe AA. | Well ok then.... just take your board and go home with it!! ;-) Seriously folks, I wasn't proposing that a change actually occur. And Joel, I didn't expect you to explain your position, but I was glad that you were able to. My post was really meant as a question for those that do avoid change in their application, simply because it is a change without any real thinking/reasoning behind it (And I do not advocate making a change just for the sake of change, nor because 'everyone else does it that way!'. And I certainly wouldn't bow down to a change because someone is holding a checkbook in front of me (there is another word for that vocation)). I guess I just run into too many change adverse types... my luck. Sometimes the committee meetings to avoid a change really get to me, especially when the only reason not to make a change is 'but we'll have to change code to do that!' in whiny tones I might add. Am I alone in this experience? |
| Mon 20 May | Johnny Simmson | 'If this was a coffee house people would be asking you to serve the same stuff Starbucks serves too. ' You mean its not already like that where you live??? All of the coffee shops around here pretty much serve the same thing. Baaa-baaa |
| Mon 20 May | Anonymous Coward | I largely disagree with Joel's position regarding threaded discussions and the ability to easily quote earlier messages. But, as others have pointed out, it's Joel's board and he's free to run it as he sees fit. That having been said, I'm not sure why it's advantageous to disallow people from editing their own posts after they post them. I've often wished I could go back and change a word or two -- or even a whole sentence -- in my messages. |
| Mon 20 May | Mark Bessey | Top eight reasons why software developers reject change requests from users: 1. Differences in opinion about what makes a 'good' interface. For example, look at Joel's response to the original question. This forum works the way it does because Joel thinks it'll be better that way. The 'enhancement' you want would actually run directly counter to some of his goals. 2. Users are stupid. Obviously, not all the users, all the time. But in hindsight, a lot of what seem like good ideas don't pan out in practice. Developers are wary of spending a lot of effort on something that the user will never actually use once they have it. 3. It would be a lot harder than you think. Sometimes, the internal design of a piece of software makes it nearly impossible to implement a particular feature well. For instance, I once worked on an application that was infamously lacking an 'undo'. People were always asking for that feature, but we couldn't make it work, because there was no central point where undo could be implemented. 4. Simpler software is easier to use and more reliable. Too many features (especially optional ones) make the software harder to use. A simple web forum like this one is a lot easier to just start posting in than something like http://slashdot.org , which has a very complicated viewing/comment system. 5. Developers don't think like 'ordinary' people. A lot of times, the external interface of an application closely matches the internal representation of data in the program. Users don't see the program that way at alll - they think of it in terms of the work they're trying to do. When a user asks for something that's not implicitly planned for in the sofdtware's design, developers often can't even understand the request - 'but there isn't even a 'date visited' field in that structure! It can't be done'. 6. Developers are arrogant jerks. Obviously, not all developers, all the time. But it's not unheard of for a developer to get attached to their 'vision' of what the program should be, regardless of what the 'stupid users' want. 7. Someone else is calling the shots. A lot of times, the developers would like to respond to user requests, but they're too busy doing other things - responding to panic calls from Support, implementing the one Big Feature that Sales says will net zillions in revenue, etc. 8. Get in line... Maybe you weren't the first person to ask for a new feature. In fact, maybe your feature just didn't make the cut over more pressing work. Anybody have others? -Mark |
| Mon 20 May | Sebastian Wagner | 'I'm not sure why it's advantageous to disallow people from editing their own posts after they post them' Because it has the potential to make people responding to the original, (==unedited) answer sound stupid, off-topic, whatever. I don't think it's particularly bad to have some typos in your post. What I'd like to have instead is a preview button... |
| Mon 20 May | Ori Berger | 9. Because of the additional overhead - rewriting manuals, updating FAQs, training materials, updating support people. Some features, however simple to implement, will introduce many other changes, with the bottom line being 'not worth it'. People who dig software downplay the importance of this; But changing the visual layout of a dialog is not something to be taken lightly. |
| Mon 20 May | pb | Allowing people to edit their posts is dumb. #1, it reduces the need to be careful. #2, it changes a small part of history. #3, it makes posts that call attention to your blunder inaccurate. Joe, the topic you brought up is ironic in that what I despise is people making suggestions that are either 1) bad or 2) go against specific designer preference. |
| Tue 21 May | Brent P. Newhall | >>I'm not sure why it's advantageous to disallow people from editing their own posts after they post them. I've often wished I could go back and change a word or two -- or even a whole sentence -- in my messages.<< Here's my opinion on that: This system encourages participants to get their messages correct the *first* time. Also, if one only needs to change a few words, the change probably isn't critical. The system encourages you to let small errors be. If a message is seriously wrong, one can always post a second message. |
| Thu 23 May | Amir Kolsky | Here is what I'd like to see happening: Keep a cookie on my machine with the topics I read, and the date/time I read them. When the page comes up, show me those threads that have changed highlighted somehow... You can also do it by tracking the users (requires logging on to something, but it's more work. Once you have that, implementing views / filters, is easy, when Joel will feel like it... Quote of the day: 'Not all options indicate a bad UI' |
| Code Reviews (Methodologies, sort of) | Mon 20 May | Nat Ersoz |
| If I could see a show of hands, how many of you have participated in a formal code review, either of someone elses code or your own? I dont mean an interface review, doc review, or functional review - that would be more like a specification review. I mean having yours, or someone elses, code taken apart by private method and state and formally reviewed? Personally, I never have. Im reading Alistair Cocburns Agile Development, p.144 embelishment. Very nice, a topic noted as uncovering should. He even makes the statement: Personally, I tend to embelish around tests and design reviews. XP/pair programming prides itself in the fact that every line written is peer reviewed code - so that would count as code review. So... are code reviews effective? Necessary? Since Im camping out on Joels site, Ill note that code reviews do not show up on The Joel Test: 12 Steps to Better Code. No item for code review there... So hey - for the sake of argument, try this on for size: there is no need for a code review unless some functional unit is chronically broken. If a function is chronically broken, then there is a significant likelyhood that you might also have a broken developer in your midst. As for interface design reviews, those are a constant conversation between client and object. I like what Martin Fowler has to say best regarding this: http://www.martinfowler.com/articles/published.pdf Publish only if you have to, and as late as possible. |
| Mon 20 May | RK | I've done code reviews a lot. There are various stages where code review is done. You are right when you said 'code is broken do a review' which is what happens most of the time. My strategy is when people are new every code the write is review by me as I the leader. I look at every aspect of the coding like - function length, naming conventions, assertion checks and some other things. Once guys get the idea then the code reviews will be come less and less. And like you said somethings get broken code review gets done while fixing. But its too late and nothing worthwhile is accomplished in terms of code quality. We have our coding standards in place which people ignore when they want to get things fast. The best way is start at the beginning. My team is small and I can do it. For big teams this strategy may work |
| Mon 20 May | Charles Miller | Code reviews are very common in Open Source projects, because the quality of supplied code can vary so much. Nothing gets into the Linux kernel without going through Linus, while more sanely run projects (apache, the BSDs) have a relatively small number of 'committers' who have CVS access, and won't add any code they don't know well enough to trust. The Mozilla project takes this to wildly bureacratic extremes and requires all patches to be reviewed twice - once by the module owners of whatever parts of the codebase the patch affects, plus an additional super-review by one of a core of 'strong hackers' who perform another check, and also look at things like the coding style, possible cross-platform issues, the use of interfaces and so on. I can imagine that a similar process would be necessary on other projects the size of Mozilla, Open Source or not. Having never worked on a project that large, I wouldn't know. It's a value proposition - at what point does the effort of performing code reviews become less than the effort required to fix the bugs they don't catch? Obviously, Mozilla passed that point. When you have millions of lines of code, you _really_ need to spot where someone's not checking whether an argument is null EARLY, rather than waiting six months for another totally unrelated checkin to trigger the bug. |
| Mon 20 May | Charles Miller | Er, I _should_ have said: 'At what point does the effort of performing code reviews become less than that needed to fix the bugs a code review would catch?' |
| Mon 20 May | Johnny Simmson | Code reviews are good at catching bugs where the developer thought none existed. |
| Mon 20 May | Matt H. | As someone said above, when we typically get a 'new guy', the person is typically assigned a maintenance project. After check-in, a Senior Developer typically looks through the code for exceptions, potential looping problems, naming conventions (lack/mis-use of hungarian notation), dead variables, etc. This continues until the new coder 'gets' our style. When I've seen this done, the learning curve is shortened. When it isn't, we ship bugs. But that's just my experience. As for multiple-people formal code reviews, we've done one or two, but they didn't seem to really shake out the bugs. regards, |
| Mon 20 May | Joe AA. | I agree with Matt... multiple people formal code reviews don't seem to shake out the bugs. A one on one review with someone that actually knows how to code is usually best for that purpose. I think it's due to the 'groupthink' aspect when more people are involved, it's just easier to convince more people that something is correct and the subtle aspects get overlooked. Groups seem to focus on 'style' and conformance to established standards rather than what the code is doing. One minor code problem was of the type with a condition like: 'If a and b or c'. The developer easily convinced the group it would evaluate as 'a and (b or c)' which of course it didn't but which would have been correct in terms of functionality. When it executed as '(a and b) or c'... when c was true and a was null, it happily wrote over code memory, eventually causing a problem somewhere else far away from this statement. IMO, code reviews with a group are more ceremony than practical. |
| Mon 20 May | Ian Stallings | I was at a client creating a web application, where our team of about 30 developers consisted of 8 smaller teams, one of which I was a lead. After our code for the app was finished, we froze the code, and it was deployed to the QA environment. I then had to attend a code review with the client's top architect and one of their lead developers. I was asked to print out all of our modules code onto printed pages. We then sat for hours going over each piece with a fine tooth comb. This did absolutely no good in my eyes and the best contribution came in the form of code optimization/refactoring and error checking that we may have missed. My objection to it was the fact that I had to print it out for each person at the review and it was about 250 pages of code and also that it had come at the very end of the release. It did not offer enough value because we were all in 'look blankly at paper' mode and we still had just as many bugs as the other releases where we had no review. The method for app development there consisted of big ass design up front, each team would code a section of the app with no unit testing, then integrating in QA, then coming back and fixing all the bugs. It worked, but I don't think it was as effecient as having ongoing code reviews by senior members during production and constant integration. I had a better experience on another project where the code review was done by pairing developers. When the code was checked into CVS the lead developer/architect would do his own review and address anything he saw that was incorrect and then come and explain to us why it could have been done better and how to address it in the future. Sometimes that conversation would be: 'you can do x better if you use y'.. sometimes it was: '(scribbling on whiteboard) I dont ever want to see this $^#%! again!'. It was a more strict method but we released with very few bugs and the proper techniques where propogated to the less experienced developers immediately instead of in hindsight. |
| Mon 20 May | Scott MacHaffie | I have never done 'formal' code reviews. Instead we do 'informal' code reviews. The format is general 1 to 2 hours and we try to cover roughly 200 lines of code from 3 or 4 developers. We try to do this every two weeks. This seems to work pretty well. We cover significantly more code than we would in a formal code review. We still don't keep up with the amount of code we generate, but we cover a reasonable fraction of it. Everyone's code gets covered on a reasonable cycle (about every 6 weeks at my current company--every 2 or 4 weeks at my previous company). We cover a variety of topics in code reviews. For example, we found memory problems (leaks and double deletions), style problems (using more than 80 columns makes code hard to print), and generally discuss code and design. We don't read through every line of code during the actual review time. Instead, we go around the room and have each developer bring up any issues they found when reading the code. |
| Mon 20 May | Nat Ersoz | 'Instead, we go around the room and have each developer bring up any issues they found when reading the code' I like this... |
| Mon 20 May | Jim Lyon | I have participated in informal code reviews for a long time (about 20 years), and formal code reviews for a short period during that time. In my experience, the formality didn't add much, except for causing otherwise-reluctant people to get started. In general, I love code reviews. In addition to finding bugs, they also frequently find better ways to do things. They're a great means of education: either the reviewer learns something new from what the author wrote, or the author learns new techniques from the reviewer. Frequently both. But the most important benefit of code reviews is also the most overlooked: almost everyone writes code differently when they know that someone else is going to read it. So the first 75% of the benefit of a code review is simply the knowledge that there will be one. All else is gravy. Given this, the answer to when you stop doing code reviews is easy: never. |
| Mon 20 May | Mark Bessey | I've been involved with a couple of different kinds of code reviews, which enjoyed varying levels of success: 1. The first code review I ever participated in was when I was leaving my first 'real' job. I had at that point been designing, implementing, and enhancing a fairly extensive API for an embedded software project for about two years, essentially all by myself. The purpose of the review was to transfer as much information as possible to the person who'd be taking over the API (the programmer who was responsible for the client applications, as it turned out). We spent the better part of a week going over internal implementation details, areas where I knew the software was lacking robustness, critical performance bottlenecks, etc. From what I heard afterwards, that code review was the only thing that kept that guy sane in the coming months. By the end of the process, he knew almost as much about the API as I did. He took copious notes, which served him well later. 2. At my next company, they generally didn't do code reviews, except during code freeze periods prior to release. The way the process was supposed to work was: When you fixed a bug, you got your fix reviewed by somebody that understood that part of the code well, then you had to defend the change in front of a Change Control Committee (CCC). The members of the CCC (including representatives of QA, Engineering, and Tech Support) would evaluate the 'risk' of the proposed change, and either allow or deny the change (denied changes usually went into the next version). The effectiveness of this process was wildly variable. Often times, the most appropriate person to review a change wasn't available to review it, or they were under too much pressure to fix their own bugs to devote much effort to reviewing somebody else's code. The CCC was often more of a rubber-stamp affair rather than an honest attempt to evaluate the risk of each change. I think one of the big problems with this method is that it added extra work to the development process right when the developers were feeling the most pressed for time. 3. After that, I went to a small startup that was developing a new embedded microprocessor, as well as their own set of software development tools (compiler, debugger, and IDE). I was a member of the QA team for the debugger. As part of the usual development process, we had weekly code review meetings. The way these meetings worked was that each week, someone would bring in some code they'd written (usually to implement a new feature), and three or four other people would read through the code and ask questions and make comments. Yes, this was powerfully boring. And it got really quiet in the room sometimes. But when a question was asked about one part of the code, often that would lead to discussions about other aspects of the code under review. One thing that always amazed me was the number of really stupid little things that we caught in these reviews. A typical exchanges might go something like this: Me: What happens if this call on line 217 fails? Developer #1: No problem, it returns zero in that case, so we just skip over this loop without doing anything... Developer #2: Actually, that function returns -1 in the case of failure. Developer #1: Hmmm. I guess I should check for that. And just like that, we've eliminated an infinite loop in the code. Don't even get me started on the excessive use of the 'unsigned' types in C... One of the nice things about having several people in the room at once is that knowledge about the 'right' way to do things diffused through the group naturally. Actually, one of the unexpected (to me, anyway) benefits of doing this kind of code review is that all the comments in the code were accurate, which saved a lot of time for people trying to figure out things later. Well, that was longer then I intended, but hopefully there's some useful info in there. -Mark |
| Mon 20 May | Alyosha` | Code reviews are essential, in my experience. They provide accountability, make the project more transparent, encourage uniform coding style, disseminate good programming practices, and last but not least, they find more bugs per hour than black box testing could ever hope to find. Timing is an important element of having code reviews, however. Just having code reviews may not be enough. Some over-zealous groups will want to review early code which is still in a state of flux; other groups will do 'code reviews' at the very end of the project, when there is absolutely no chance to actually act on any of the insights the review process brings. Both are useless ceremonies and will do more harm (in employee morale) than good. Our process went somewhat along the lines of this: 1. The developer completes a major feature add, is confident with her work, and gives the OK for the review. 2. Three or four of her peers take her diffs, print them out on paper, and spend about an hour or two per 400 semicolon lines of code 'prep time'. 3. In the logging meetings, everyone gets together and goes line-by-line through the code, itemizing each issue as they occur. Each issue mentioned is written down or stored in a database. It is important that debate be minimized during this meeting, as it is rarely fruitful and just bogs down the meeting. Each meeting should last no longer than two hours and covers about 400 SLOCs. 4. The developer goes back and investigates/addresses each issue raised in the meeting. 5. A follow-up meeting is optional (to ensure coverage of the issues raised in the meeting, or to verify certain issues were handled correctly). 6. The developer's branch is merged into the main trunk. Bugfixes and other maintence changes need not go through this process, but each change would also be reviewed and approved by at least one other developer prior to merging. The upshot of this process is that every line of code has been seen and understood by at least two people prior to commiting to the tree. |
| Tue 21 May | Jutta Jordans | I found code reviews very helpful in establishing a common coding style in a team of developers (and by style I do not so much mean naming conventions, indentation and other rather cosmetic stuff, but decisions like 'What do we make const?', 'How do we handle errors?' and the like). I am really pro code reviews and I try to make them part of our development routine by convincing my colleagues of their usefullness, but there is a great reluctance in some of them. Their major argument is about time normally 'This has to be finished yesterday, so don't bother me with something like a code review.', but I think, this is not really the point. Actually, I think it is very difficult to handle a code review in a way that does not offend the person who has written the code. After the first reviews of my code, even though they were done by a colleague who acted as my tutor at that time and tried to tread lightly, I was close to tears. It just does not feel too good to be told what you do wrong; I tend to be very emotional about my work. I know that I learn a lot from code reviews, still I find it hard to accept the criticism involved. I did pair programming, too, on a smaller project, and that was even better from the learning side and also felt better emotionally, escpecially when the driver changed often, because it becomes more of a give and take. Have fun, |
| Tue 21 May | Scott MacHaffie | One idea that my wife told me has helped a lot in code reviews: don't bother with more than two or three things. You should always point out all of the bugs so that they can be fixed. But for stylistic things, most people can only handle about two or three things. Just pick the top couple and stop there. |
| Tue 21 May | Nope | jutta - i suppose to to an extent you are right, it is important code reviews do not get personal. to be honest though, if by doing that people go easy on their colleagues, that a) misses some of the point of reviewing, and b) misses out on some of the fun. reading code is a boring job and unless there is some pay-off it is likely to be something people don't want to spend time on. as long as there are no managers present, reviews can be good fun if done in a spirit of (light hearted) competition between developers. as long as the people involved are playing the same game this can actually be quite a lot of fun :-) introduce someone, like a manager, who might want to use code review results for some other purpose, and they become stressful, and things to avoid. |
| Tue 21 May | Brent P. Newhall | At my last job, I really liked the system that we had in place: A developer would be assigned a trouble ticket to fix or a new feature to implement. The developer would come up with a fix. Before checking in the changes, the developer would put together a Cutover Sheet, which contained a brief summary of the change made or the feature implemented, with a printout of the affected code attached. If only a few lines were changed, a printout of just the surrounding few lines of code was sufficient, and diffs were acceptable as well. This was meant to be a lean and mean form. The developer had to show the Cutover Sheet to a colleague, who would review the code him/herself. That colleague would have to sign off on the Cutover Sheet. The Cutover Sheet then went to the developer's manager for a final review before the code was checked-in. Completed Cutover Sheets were kept in a drawer for a few months so that we could track down culprits. ;-) This sounds time-consuming, but in practice, it only took about 15 minutes to fill out a Cutover Sheet and print the code, and the colleague and manager would only need to spend 5-10 minutes each looking over the code. The code would be reviewed by two people -- one with little 'bias' and one that was very familiar with the problem that had to be solved, capturing the advantages of each. We caught a lot of bugs and inefficient code this way. We also each learned a lot more about the system, because we were often being introduced to alien pieces of the system through other developers' Cutover Sheets. Both at that job and in my current job, we did a few formal code reviews, in which a group of us all studied a printout of code, one page at a time. I found that, while we often didn't catch many bugs in the meeting, the knowledge of a pending code review would push us to clean up our code more than we would have if our code had stayed unseen. |
| Tue 21 May | Katie Lucas | Personally, all of my experiences with code reviews have been bad. Pair programming, much better. But code reviews always seem to turn out to some sort of geek grandstanding competion. Whether the code works or not is insignificant compared to whether the lines are indented properly and if the naming conventions agree with what the least literate person on the team deems 'suitable'. Add to that the lack of social skills of most software developers and it's all completely annoying. Having people hand you huge wads of paper, which have wiggly lines next to things with 'this sucks' type comments on it is not at all good for my morale and doesn't endear me to the writers. At no point were the contributions at all constructive. It was like being back at school. 'this is wrong, this is wrong, oh and this is just hopeless. Redo it.' No-one ever wanted to know the reasoning behind algorithm choices, they just wanted to demonstrate their alpha-maleness. Code reviews end up confrontational and are disempowering to those developers who are completely competent but just aren't up to partaking in yelling matches. It depends if you value competent developers or just the ones whose skills lie in 'winning' confrontations. |
| Tue 21 May | mackinac | I live in a different space-time continuum from Katie. My experience with code reviews, though limited, has generally been good. The reviews I have participated in involve a couple of steps. First, the reviewers review the code. Second, there is a meeting to discuss findings and decide on changes. In my current project there is a web based commenting system, sort of a discussion board, that allows for on line comments and discussion between the developer and reviewers. There is still a meeting for making final decisions. A few years ago a project I worked on tried code reviews where the reviewers got together and went over the code line by line in the meeting. It didn't work and we gave that up rather quickly. I find that informal self reviews can be useful. I print out the source code and read through it. If I am looking at it for overall understanding, I see problems that I missed when I was at the terminal trying to decide what the next line would be. |
| Wed 22 May | Brent P. Newhall | Katie: Out of curiosity, did your code reviews include a strong moderator, one who pushed the review along when it was stagnating? It sounds like those code reviews in which you were involved fell victim to bad personalities. I wouldn't want my code reviewed by developers who grandstand either, unless there was a good, strong moderator to direct the proceedings when people started nitpicking about indentation. Personally, I don't mind nitpicks, as long as they're parenthetical and extremely brief. |
| Wed 22 May | Nat Ersoz | I have to say that I can relate Katie's writings - not with respect to code reviews but the architecture 'discussions'. Often, it is hard to authoritatively say 'this is best because...' and come away with an analytical objective reason why A is better than B. For me, simpler is always better. It also agrees with the XP notion that I only implement features when required. I don't code future features today (this reduces software cost and investment, nicely spelled out in XP explained). Others, however, see extensibility as the most important architecture decision. This rarely leads to minimalist implementations, let alone testability. Which way do you go? It most often comes down to 'guru' opinion, group think, or corporate doctrine. |
| Wed 22 May | skautsch | I have found code reviews to be both worthwhile and useless. They are useless (and aggravating) when they are conducted in organizations that do not know how to hold *any* kind of meeting. They must have a stated intention and goal which everyone agrees is attainable in the context of a (two-hour?) meeting, and the moderator must be *strong* and committed to keeping egos outside the door. There *are* ways of doing this. Generally, if more than a couple of people in an organization complain about the efficiency of reviews, it's time to get some training, or perhaps new moderators. When done correctly, I have found them cost efficient. I.e., they produce more value, in a variety of ways (including mentoring), than they cost. I miss them - they don't believe in such things where I work now. (At least they're frank about the non-commitment to quality.) |
| Wed 22 May | X. J. Scott | Katie, My experience has been like yours. You have identified the problem correctly too I think -- it occurs when testosterone kicks in and the reviewers are under age 26. Here's a typical exchange, ChimpBoy: 'This code of yours to exchange two variables is incorrect: temp = a; a = b; b = temp;' Me: 'What's wrong with it?' ChimpBoy: 'You should have used the more efficient and standard idiom: a ^= b ^= a ^= b; This is better because it does not wastefully use a temporary variable and is thus much faster and more efficient. It is also easier to understand because it uses two variable names instead of three. Recall the Rule of Seven.' Me: 'Yes, I have seen the XOR exchanger in the Obfuscated C Contest but I don't agree with you that it is faster and I certainly don't agree with you that it is easier to understand or more maintainable.' ChimpBoy: 'Well that's where you are wrong and I won't have you arguing with me -- I just want you to change it. You think you know everything but you don't.' Me: 'Let's profile each one and see which is faster.' ChimpBoy: 'I won't tolerate your backtalking to me. Besides, profilers can lie.' Me: 'I can produce the compiled assembly if you like and tabulate from the CPU user manual for you the number of clock cycles for each method.' ChimpBoy: 'Just change it and stop being a smart ass.' Me: 'Yes Sir!' |
| Thu 23 May | Brent P. Newhall | X.J. Scott: It sounds like you've been dealing with bad co-workers, which doesn't necessarily reflect on the code review process itself. Any process can be rendered worthless by sufficiently annoying people. |
| Software License Management ... | Thu 16 May | James Ladd |
| Peeps, Have any of your integrated a software license management solution into your product ? What solution did you use ? What were the pros and cons ? Any comments much appreciated. |
| Mon 20 May | Andrew Cross | Just a follow-up to my suggestion of using #define malloc to help in copy protection. Some points ... 1) Obviously your 'licensed' routine does need to be quick. If it is not, you can do all sorts of things to make it, one secure way to speed it up is to use a static variable that is reset periodically another thread to avoid it simply being changed by a hacker at run-time. 2) Someone pointed out that you should not use a Licensed()?true:false kind of check. In my post I did say that this is a bad way of doing it. Much better to do something like long LicenseResult=LicenseKey^RegistrationKey; (or some other check here that might produce a result that has some value -not a bool- if long MemoryToReduceBy=((LicenseResult&0xff000000)>>24)+((LicenseResult&0xff0000)>16)+((LicenseResult&0xff00)>>16)+(LicenseResult&0xff)); return malloc(a-MemoryToReduceBy); This is going to be really hard to reverse engineer for a hacker since it is going to put a mathematical expression inline for the malloc() and not have any true or false check. The hacker now has no way to simply 'doctor' a single routine in the code, but probably modify hundreds (thats why its a #define). 3) It is indeed bad to have your application 'crash' if a unregistered user is using it. However I would recommend that you have proper exception handling in all your code anyway ! Just put an additional license check in the code that reports exceptions to users to let them know that its probably because they are using an unlicensed copy. 4) Don't user copy-protection at all. Make users want to buy the software ! Andrew |
| Mon 20 May | Ori Berger | <<< 3) It is indeed bad to have your application 'crash' if a unregistered user is using it. However I would recommend that you have proper exception handling in all your code anyway ! Just put an additional license check in the code that reports exceptions to users to let them know that its probably because they are using an unlicensed copy.>>> Ahm. This is exactly the kind of 'bugs' (intentional in this case) that exception handling is NOT supposed to handle, and it's generally impossible to robustly handle. However, you should have a 'simple' license check upfront, and a relatively high probability to blow up within 30 seconds of actual program use. That said, informational-only or total-lack-of licensing schemes are better for all - customers and producers alike. There are very few examples to the contrary, and many in favor. |
| Mon 20 May | Brad Clarke | 'Whatever kind of security scheme you use (S/N, dongle,...), the first door visited for crackers is always the same : Where in you program do you call the license-check function. You can have 128 bits encryption, a 68 digits prime number or a Hasp (Aladdin) dongle. The situation is the same : At the beginning of your program, if you have a call such as if (LicenseFound()) GoFullFeaturedMode();' That's why you need to make multiple versions of 'LicenseFound()' and make a call to one of these key validators for EVERY action the program takes. It adds a lot of overhead to you app, but it gives the crackers a bigger headache. |
| Tue 21 May | James Ladd | So many excellent point and suggestions. Some of the noise was kewl too. Thanks heaps people. If you have any more, then please add it. Regs, James. |
| Tue 21 May | Ted Christiansen | You might want to look at Concept Software, http://www.softwarekey.com . The protection part is done using Protection Plus. The Electronic License Management is done using the SOLO or Instant SOLO products. They have been doing this 10 years and appear to be striving toward making the activation of software as painless as possible, which is key to retaining customers. Ted |
| Tue 21 May | Lynn McGuire | 1. Execution protection is easy to screw up ! You can easily offend your customers in fighting off the crackers. You can also end up spending all of your time working on the security code. Dont be surprised when you see your software on news://alt.binaries.warez.ibm-pc (saw ours this week ! twice !). Go to http://www.google.com/ and look for 'crack' 'your-company-name'. You might be surprised (and terrified - how do I feed my kids this week ?). 2. Find something that is easily repeatable on 98% of PCs. We use a munge of the IDE hard drive serial number. See http://www.winsim.com/diskid32/diskid32.html for info on how to get the hard drive serial number on Win9X / WinME / Win2K / WinXP. Dont confuse this with the volume serial number. 3. Use good encryption like twofish http://www.counterpane.com/twofish.html for your passwords. Ours is 128 bits (32 chars of hex digits). Yes, the customers scream having to enter 32 characters. We used to use 64 bits (16 chars of hex digits) but they cracked it. 4. Make people send their Computer IDs to you for a testdrive password to be emailed to them. You've gotta have complete control over the password generator in order to do this on a secure box (we use FreeBSD) so that the crackers cannot attack it ! See http://www.winsim.com/gen2wkps.html for our password generation page. 5. Make sure that your testdrive passwords have start dates AND stop dates in them. Keep track of what date that they run your software somewhere on their PC. In fact, several somewheres. Otherwise, they will roll the clock back on you. Good luck, you're gonna need it ! Lynn McGuire |
| Tue 21 May | Amir Kolsky | Re: AOP and Patching Code << Which helps not, because if done this way, patching it amounts to patching just one 'aspect' of the program. >> Of course it amounts to pathcing just one aspect of the program! That's what we wanted to achieve! Make the code run on entry to every method / function (or whichever combination of conditions you desire)... The point is that you write it ONCE, in ONE place, and it gets incorporated into EVERY function call, automatically. |
| Wed 22 May | Anders Bengtsson | Re: Timebombs I wouldn't purchase software that has a timebomb in the (production) licence. Imagine the software company going bancrupt, or simply their licence renewal service having a few days downtime, while your business grinds to a halt. If the software you're buying is of any importance to your company then you shouldn't be taking this kind of uncontrollable risk. |
| Wed 22 May | Not A Peep | I am not a 'peep!' |
| Wed 22 May | Ori Berger | < |
| Thu 23 May | Amir Kolsky | Ori, I'm sorry to be so blunt, but you are dead wrong. If I specify an AspectJ rule to add a piece of code on entry to every function (Which is a VERY simplified case of what you can do), that rule is applied by a pre-compiler to EVERY function in the program. In order to remove it, you have to manipulate each and every assembly reference in the code. You have 100 methods? That's 100 places to look... |
| Thu 23 May | Ori Berger | I might be dead wrong, but I doubt it; It will make more work to create disassembler/decompiler tools that decompiles aspects, but eventually it will be there - Java bytecode is too regular. You're invited to decompile any of your Java or Python files (using decompyle or Jode) and observe with horror that except for local loop variables and comments, they reconstruct the source intact. 13 years ago, I wrote a program that was able to automatically remove any 'shell' around an executable, be it a virus, compression scheme, encryption scheme, etc. It did this by analyzing what the code actually did, run it several times, dumping memory to disk at various stages, comparing all of the images and eventually generating a 'true image' that is both (a) a memory dump of the process after it has REALLY started running (past the outer layer of code), and (b) exhibits the same attributes as all of the analyzed images. This may sound extremely complicated, and it isn't simple, but it took no more than 6K of a DOS COM file (written in Assembly language) to achieve, and was nearly automatic - to the extent that 6 years afterwards, it still took me less than 5 minutes to apply it. What protection/licensing schemes don't give in to automated analyzers? Those that are not automatically applied, or those with such random variety in application that they are for all practical analysis purposes independent. I haven't examined any AspectJ output code, but I suspect that without global bytecode optimization or optimized compilation to native code, it will be relatively easy to manipulate program aspects at the bytecode level. Native code is significantly harder to manipulate, but technology is also advancing in that front - e.g. JiiTi and valgrind that both analyze and rewrite native x86 code on the fly. |
| Thu 23 May | Richard Stanford | >>> I wouldn't purchase software that has a timebomb in the (production) licence. Imagine the software company going bancrupt, or simply their licence renewal service having a few days downtime, while your business grinds to a halt. If the software you're buying is of any importance to your company then you shouldn't be taking this kind of uncontrollable risk. <<< Excuse me? Most enterprise contracts on any scale (which what you're describing would be if your business is grinding to a halt) have a couple of clauses in them. First, you'd have a penalty clause if they couldn't relicense your software. Besides, you should have started that process a month (or more) before it expired. More if you're doing contract negotiations around it. Second, why on earth wouldn't you have an escrow agreement for not only the licensing algorithms but proabably the application code itself if its that business critical? You present a legitimate enterprise-software complaint, but one that was solved a very long time ago. - - - Having said that, my enterprise product doesn't currently have any form of strict licensing. It is a pain to deal with, and in all fairness if anything did screw up it can be very expensive for any software vendor (assuming that their customers are larger than them and that there are some pretty stiff penalty clauses in the contracts). Its hard. Maybe a technical solution could work ... maybe a social one is better ... or maybe a combination? You could do something like this though: For a support call, have the reporting user execute a command on the installed machine. This would return a data fragment (it can be long, cut-n-paste into email is fine here) that encrypts their product key, the current date, and the peak number of users (maybe even some more advanced distribution data). This is required information before support can be given. No enterprise customer is going to go long without support, after all. If you find out that they are over their limit, you go ahead and support them anyway but pass that information on to your Sales team as an easy win. |
| Visual Basic vs. Visual Basic.Net | Tue 21 May | Yoav |
| I have about a year and halfs worth of experience with ASP 3 (VBScript). I want to move up and have been thinking of teaching myself Visual Basic 6. Then along came .Net.... Is it worthwhile for me to learn Visual Basic 6 or skip it altogether for Visual Basic.Net? What are some of the factors that should affect my choice? Note that I dont necessarily want to work full-time on the Web. Thanks for the help. |
| Tue 21 May | VB hater | The world would be a better place without VB, of any variety. If you're going to use .Net and are starting clean, use C#. |
| Tue 21 May | Marc LaFleur | There is such a world of difference that it really depends. If you plan on doing real work right away, .NET isn't the way to go (the runtime just isn't wide-spread enough) but if you are looking at a year or two down the road, VB.NET will be worth while. As for C#, it matters little. Learn C# or VB.NET. Once you know one, you can pick up the other in no time. Just for the love of god skip unmanaged C++. You'll end up hanging yourself if you try to teach it to yourself. Oh, and forget about ALT and COM+ too . Not only will they make you kill yourself, you'll take out 10 people with you! |
| Tue 21 May | Mark Alexander Bertenshaw | A tricky one. It depends what you want to do, and who you put your trust in. If you want to maintain old VB code, then go for VB6; if you want to do new stuff, then learn VB.NET. You migth want to take into account that VB.NET is one of the languages which you can write ASP.NET applications. If you believe Microsoft, and its various parasite companies (that's not necessarily perjorative), there will soon be millions of developers going ahead with .NET projects. I can't tell whether this is true or not. But do remember that Microsoft has managed to keep their momentum going for many years, and it is possible that they will be leading for the forseeable future. Another thing - learning one won't help you learn the other. There are many differences. In terms of syntax, VB.NET resembles VB6 ... kind of. Personally, I consider them to be dialects of the same language (think Glaswegian vs. Cornish English). One thing's for sure - learning VB6 won't help you if you want to learn VB.NET. The other thing is the behaviour of the IDE. Many people comsider that whilst we have gained many things (such as a decent menu editor), some of the features that made VB so cool have been left out. The principal one is the 'debug - edit - continue' feature of all VBs up to 6. Since VB.NET is not evolutionary, but revolutionary, it has a completely brand new IDE, shared between all Visual Studio.NET languages, and this feature is not supported. Maybe next version, I hear people say. |
| Tue 21 May | chris | Why not do both? If you have already done vbscript for a year and a half you should be able to pick up VB6 basics in about a month. Just pick up a 21 days book and go through it. Then I would probably pick up c# just so you don't confuse the two languages. After that, you can choose which one will be more valuable to you and make your own decision about which one to delve into. Knowledge is power. |
| Tue 21 May | Nick | Since VB 6 is IDE-centric, I wouldn't bother picking it up unless you actually planned to use it or just like throwing money around. VB.NET, C#, and other .NET applications can be developed without VS.NET - Jjust download the .NET Framework. I'm not sure how well this works and what limitations there are (maybe others could chime in), but free is always a good option when you're dabbling in or learning a language. Also, the C# syntax is very similar to Java. Relative to Java, VB job opportunities have declined much more sharply in the past year (above and beyond the industry-wide decline). So it might be more worthwhile to learn C# & the .NET thing. |
| Wed 22 May | Brad Wilson | It's not only perfectly feasable to write .NET software without Visual Studio.NET, it's the only way I work. I find the VS.NET IDE to be slow and limiting to me. But I'm not your average programmer. I self-teach myself new technologies all the time, and I'd rather know and understand what's going on in the code than drag and drop and drool and ship. YMMV. |
| Wed 22 May | Yoav | Thanks for the very informative feedback. |
| exit strategies | Sat 18 May | strategist |
| What is your exit strategy for leaving your career in IT? I have tried, and cant visualize myself sitting at a desk in front of a computer when im 50 (im 29). Even if I wanted to, I just dont see the opportunity for making a decent living to still be there. As a manager, maybe. but I really have no desire to manage IT projects. anyway, Im currently looking at becoming an ICU nurse or an ASE certified mechanic for luxury vehicles. id have to start out at the bottom, but after 5 years each seems to pay about the same as a developer with 5 years of experience. (i.e. about $100,000). Both seem sort of interesting and useful, and Id get to be up and about, rather than chained to a desk. What are other people planning? ps: this might seem like a troll, but im actually curious. |
| Mon 20 May | MarkTAW | I agree with 'a programmer.' You have to figure out what would be better about a different job, be it mechanic, nursing, or whatever. A lot of the time you can delude yourself into thinking another course will be more fulfilling but it won't. Or maybe you're just unhappy with your job, and a job at a different place in the same field may cheer you up. I agree that being frugal and investing is wise no matter what your career. There are some fun planning tools on schwab.com, and once you know how they work you can program your own. For some reason 12% seems to be the magic number for retirement income. You should also look at things outside your career. Perhaps it's not what you do 9am - 5pm that needs changing, but rather what you do from 5pm - 9am. |
| Mon 20 May | Brad Clarke | 'but after 5 years each seems to pay about the same as a developer with 5 years of experience. (i.e. about $100,000). ' Sure you can....I've been in IT for 14 years and make about half of that (not in the US). |
| Mon 20 May | Brad Clarke | 'There aren't many 50+ programmers b/c programing is a relatively new field. People who are 50, would have had to have started programming in 1970. ' I know a programmer in Germany who is 55. He started programming in 1966 and he still does it today and enjoys it very much. |
| Tue 21 May | Bella | http://editorial.careers.msn.com/articles/mistakes/ Career change mistakes |
| Tue 21 May | bryan | as far as the 12% goes, that is because it is the historical average return of the S&P 500 (which approximates the historical average return of the stock market as a whole). |
| Wed 22 May | Bella | Annual 12% is an absurd assumption for the next decade. Annual -12% would be closer to reality. Quiz: If you started with $1000, and realized a -12% loss each year, what would you have at the end of 100 years.? Hint: Anyone recall the logarithmic exponential decay formula from High School ? |
| Wed 22 May | Brent P. Newhall | ...And the NASDAQ will never reach 10,000. No offense, but I tend to disregard any prediction about the future of the stock market unless it's based on strongly documented historical trends. Just because America's going through a downturn right now doesn't mean that it will continue for a decade. The S&P 500 *has* had a documented 12% rate of growth for decades, just like the Dow. They're pretty safe bets. |
| Wed 22 May | Bella | Market went bezerk in last decade. It looks like we've got YEARS of declines to get us back into line with your historical average of 12%. |
| Outsourcing Development Overseas | Mon 13 May | Name changed to protect the innocent |
| My company has recently outsourced their core development overseas rather than pay the higher costs of developers wages. They are planning to retain a minimal staff of developers at the company to install and liaise with clients, while the development is carried out overseas. Now I know this is a terrible idea for a company whose core is software development, but I would be interested in hearing any stories you might like to share if you have been in a simular situation. |
| Tue 21 May | Joe AA. | 'I've never been able to get a straight answer out of anyone as to whether or not outsourcing saves money' And you never will... because it doesn't. It causes a redistribution of funds, ignores the overhead costs, hides other unanticipated costs. You can prove anything you want through accounting... ya just have to not include the account ya don't want anyone to know about. No company (as with an internal IT department) does true total costing of the IT service... outsourced or not. |
| Wed 22 May | Hugh Wells | The way outsourcing contracts are presented, management execs can think they're getting software at a cheaper price. But of course something has to get squeezed somewhere, and the thing that gets squeezed is quality, robustness and maintainability. Management execs frequently don't have the expertise to assess these factors, and sometimes their IT managers aren't articulate enough to discuss them. Downstream costs can be higher, due to excessive ongoing maintenance, and lost opportunity costs can occur too when the software can't readily be adapted for new business missions. |
| How to plan a web app | Mon 20 May | Sergey |
| Hi, I have been envolved with web applications for a year now, mostly doing Perl + MySQL stuff. And now i come to realize that i just cant figure out how to implement all the good software creation practices that are discussed by Joel and on this forum. I am now trying to actually make a detailed plan for the app that i am going to write. Lets assume that this is a Weblog. I just dont know how to break all the work that i have to do into small tasks that can be put into task management software, etc. I always come up with a detailed step by step description of what a user do and what the app do, how they interact, but it seems to me that i miss the big picture, it just doesnt feel right to me and I never finish this planning work and just go on with the code, without actual planning. Can somebody please explain me on a simple Weblog example how to plan software development? I am searching for a simple straightforward technique, but any real world example would be great! |
| Mon 20 May | Joe AA. | People frequently confuse planning with scheduling. Planning is an ongoing, day-to-day process of decision making when new information comes to light. The belief that anyone can produce a detailed schedule without knowing everything on a new development project is just another management fantasy. It also ignores changes that are bound to occur as the project progresses. Sticking to a detailed schedule when new information is known is merely stupidity in action. Management is not the practice of forcing conformance to schedule... it is the day-to-day planning and making those hard decisions. But I commend you for trying... it's one way to totally understand the limitations. |
| Mon 20 May | Adam | Start with Use case analysis. 1: Who are the people that use the application. Usually you will have at least 2, the everyday user and the administrator. Figure out what kind of things tey want to do. For a web log, you may start with two use cases: Read message, add a message. POsbbily a fourth for adding a new topic. Sketch out a simple UI to support each of the uses cases. Don't be afraid to break use cases down into smaller ones, as this is the primary place where you do top down design. At this point, start your data model. Figure out what tables you are going to need to support the UI you have just sketched out. Keep things in the highest normal form you can...you can denormalize later using Code/Views etc. Keep things simple. start out with the absoute minimum amount of functionality you will need to get a wortking app. Actual;ly, start with Hello World, and work towards a functional app. Build unit tests for everything. Don't over design. Don't try to do too much at once. Implemnet your most important use case first. |
| Mon 20 May | Jeff MacDonald | I stumbled onto this several days ago at Borders: 'Building Web Applications with UML' by Jim Conallen ISBN: 0-201-61577-0 http://www.amazon.com/exec/obidos/ASIN/0201615770/qid%3D1021950341/ref%3Dsr%5F11%5F0%5F1/102-4580311-7503313 I can't truly recommend it (yet), since I haven't completed it, but I'm about 1/2 way through and, although simplistic at times for the more seasoned developer, it's given me some great ideas on how to tackle some of the challenges you appear to be facing. Any other recommendations from the group would be great, as well. |
| Tue 21 May | Philippe Back | I tried to use that book (I happen to be teaching UML BTW). Using the stereotypes for any kind of real app is impossible. Use case modeling is fine if you want to get a rough sketch. Domain modeling is also good for UML, as well as state machines modeling (the diagram is quite extensive). But for the spec itself, do yourself a favor and sketch the screens on paper and connect them with arrows. First of all, use a decent framework for the web app (I use struts, which is now really useful with its 'Tiles' extension). So you have a decent architecture at a low price (and benefit from the improvements others are making). One good thing to keep in sight is the data access stuff. I would love to use www.pragmatier.com for the data access layer but they don't (yet) have the Java version. So, you have to go back to one of those lower grade frameworks like JRF (Java Relational Framework) for the persistence. For any real web dev, use the Java Servlets platform, they are maintainable and can scale. Just my EUR .02... But they proved to be working in production applications (especially with a good caching mechanism - you may want to look at oscache for that). |
| Tue 21 May | Philippe Back | As for the application, have a look at your actors: - guest (the guy reading your prose) - registered user - administrator (you may want to have some delegates) [for the weblog, you may end up being the only user, so you have guests and administrator] As for those actors, have a look at their goals towards the system and which events they will generate or receive, as well as which data flows in and out of the system. Then chunk the list down into pieces. Administrator: - Log entries management: - create new log entry - preview log entry - publish entry - remove entry - modify entry - Reports: - daily report - weekly report - ... - User management - modify password - lock user - unlock user - ... - Authentication - login - logout - ... Visitor: - Weblog usage: - Home page: - Main news - Sidebar - Online people on the site - Detailed view etc etc Then you take the nice excel sheet from Joel and you give an estimate for creating every single part of the above list. Remember, you have to create the development environment (directories, CVS entry, ant tasks, appserver environment, editor) and the basic structure of the app (e.g. have struts working properly with a clean blank application). So be sure to plan for it. Then feature by feature, put a time estimate for (and this for every single screen in the feature): - screen creation - objects supporting the screens (formsBeans, domain beans) - logic for managing the screen (state machines, acces control etc) - database tables and constraints and indexes (+initial data rows to get the ball rolling) - database access code and queries (SQL SELECT|UPDATE|INSERTS) or triggers or stored procs. Then you will see that it will lead you to spend an awful lot of time to get the thing done and that's where you will put priorities ! ... and do the simplest thing that you can get running. After that, this should build your motivation to spend all your nights on the beast :-) Have a check at http://www.rik.org for something better than excel to arrange your tasks. Well he moved that here: http://www.positive-g.com/ and I guess that you will now have to pay for it. Hope it helps, |
| Another MS Office killer? | Mon 13 May | Jan Derk |
| I wonder what everyone else thinks about OpenOffice 1.0. Over the years there have been many announcements about competitors for MS Office and all failed for a variety of reasons. After playing with OpenOffice for a few weeks I never once needed to revert back to MS Office. Im no MS hater, but something tells me says that OpenOffice means trouble for Microsoft. While there still might be features lacking (I didnt notice any, but then again I am not a power user) on many accounts its as good or better than MS Office, plus its free. Simple logic says that, even for a giant like Microsoft, its hard to compete against a free competitor which is as good as your product. And Microsoft can never complain, because they used the same tactics to get rid of Netscape. Heres a rather positive review in the Washington Post about OpenOffice 1.0: http://www.washingtonpost.com/wp-dyn/articles/A4246-2002May11.html Joels gonna love this part: This programs one real failing as a writing tool is its word-count function, which is concealed inside the File menu and cant measure selected text, just the entire document. |
| Mon 20 May | Nat Ersoz | 'Considering that exchanging documents with external parties is one of the primary reasons to use MS Office, this seems rather silly'. This was a problem at times. I don't know what resolution came of this - at some point I'm sure they upgraded to a later version, but it was postponed until some pain threshold was reached. However, as the yahoo biz report mentions, they were not unique in this, merely ahead of their time... 'Customers said no. Microsoft extended the October deadline until December, then reset it again to July 31. With the latest deadline just three months away, 65% of enterprise customers surveyed by Gartner Group have yet to decide whether they'll buy into the program.' and 'To be honest, we currently have Office 2000 and Windows 2000 and we don't need to upgrade,' says Dave Duvlea, who runs information systems for Witcher Construction, an arm of the $1.5 billion J.E. Dunn Construction Group, outside Minneapolis. 'We hardly use the gobs of features on Office 2000 as it is. Why would I want to commit to buying upgrades on something we don't fully utilize?' |
| Mon 20 May | Tekumse | Andrew wrote: > Of course no one pays for Office. As far as I'm concerned > it's free: as a student I used it in labs or the $5 copy I > could get through my university's bookstore. My wife's > still a student, so we can always get the new version > for $5. Andrew, you are so blind. Look at your tution bill and you'll notice you have paid at least several hundred bucks for software licensing fee. At the bookstore they are charging you only for the media and distribution. There aint such thing as free lunch. |
| Tue 21 May | Brian Schnell | http://www.nzherald.co.nz/storydisplay.cfm?storyID=1993017&thesection=technology&thesubsection=general Enza says 'no' to Microsoft 21.05.2002 By RICHARD WOOD ' Fruit exporter Enza is saying no to Microsoft's new Software Assurance licensing scheme and is likely to dump Microsoft Office for the bulk of its 500 users..... Hunt said the new Microsoft licensing model was based on more frequent upgrades than Enza's financial system, SAP. He predicted Microsoft would be hit hard by free 'open source' software. 'If you look at me as a typical example, I've got, say, five hundred seats. 'Maybe I put 400 over those onto Open Office and I leave a hundred. So they lose 80 per cent. That's got to hurt.' Another trend, the use of Citrix's thin client technology, favours Microsoft. Citrix allows Microsoft Windows to run across terminals and lower-cost PCs. Hunt said he was considering using Citrix at Enza. He said there was no complete alternative to Windows available for the free operating system Linux. But he said it was only a matter of time before a free open source equivalent was developed, which he believed would force Citrix to release a Linux version. 'Then it would be extremely easy for me to fill my data centre up with Linux boxes running Metaframe. 'It would cost around $300 a seat and I'd never have to touch a PC on the desktop again. I could run Open Office on those boxes, and SAP on it, because SAP runs on Linux.' --- I suspect that this scenario is going to be played out around many small and medium sized businesses in the coming 1-2 years. |
| RealNames | Mon 13 May | pb |
| Amen!! Im so sick of RealNames. It is almost as silly as AllAdvantage. I asked 20 people at my company if they had ever used a keyword and not one had (ok, it *is* possible they did so without knowing about it, which does indicate *some* value in the service). But Teares current behavior is completely insane. Microsoft should not base its desicion solely on business concerns? Hey, Teare, maybe Microsoft came to its senses and realized its just plain dumb! |
| Tue 21 May | Jan Derk | Personally I could not care less, but it seems that the Asians are not happy at all that realnames goes under. Here's another article from The Register: http://www.theregister.co.uk/content/6/25369.html |
| Irrational client behavior -- another example | Sun 19 May | Jane Gallagher |
| The earlier thread (Weird client behavior) inspired me to share my experiences. In the past year, Ive created two websites: one for an obstetrician, and one for a mom-and-pop sporting goods store. In both cases, the clients are acting irrationally. The obstetrician is very aggressive. She advertises all the time; she tries to get stories planted in the local paper; she took out a huge billboard near the hospital, etc. She told me shes happy with the website, but she never includes the URL in any of her advertisements. The sporting goods store is the same. They like the website. They periodically send me updates to include on the site. They pay their bills on time. But they never include the web page address in any of their promotional materials. Ive talked to my clients several times about the need to include the URL whenever the street address and/or phone number are listed. The clients agree in principle that this is a good idea, but they never act on it. (Incidentally, all the clients are largely computer-illiterate, which may explain things.) I tell you, its enough to drive me bonkers. My friends tell me that it doesnt matter, as long as I get paid. But I just cant stand to see people acting so irrationally. I sometimes want to grab them by the lapels, shake them, and scream, What are you people thinking?! |
| Mon 20 May | Charles Miller | The irrational behaviour is not that they don't put the website on their stationary. The irrational behaviour is that either of these particular businesses have websites at all. |
| Mon 20 May | Robert Moir | Good point Charles. I'd love to know how many referrals they think they get from their websites, and how many they really get ;-). I'd love to know if they've even thought about how they'd tell how many referrals they get. If you can't measure you can't manage. |
| Mon 20 May | Jane Gallagher | Charles Miller wrote: 'The irrational behaviour is not that they don't put the website on their stationary. The irrational behaviour is that either of these particular businesses have websites at all. ' I'm surprised that you think so. There would have been a significant return on investment had my clients used the websites the way I recommended that those sites be used. The sporting goods store runs sales about every two months. They take out small newspaper advertisements, but they don't have enough space to list all the sale items. If the store had included the website's URL, then interested newspaper readers could have visited the store's website to find out the prices, item-descriptions, etc. A handful of major purchases would have paid for the site. (I.e., a ski package can cost upwards of a thousand dollars.) Similarly, the obstetrician makes so much money off her patients that it would only take about 2 or 3 referrals over the lifetime of the website before the investment paid for itself. After all, it costs no additional money to include the site's URL at the bottom of newspaper ads or outdoor billboards. I think that the dot-com meltdown has caused people to go to the other extreme -- to become overly and unjustifiably cynical about the value of a web presence. |
| Mon 20 May | Jane Gallagher | Robert Moir wrote: 'I'd love to know how many referrals they think they get from their websites, and how many they really get ;-).' The clients don't think about it at all, but I do. The volume / quality of e-mail correspondence suggests that a small but significant number of potential customers / patients are visiting the sites. Analyzing the site logs also provides some useful measures. I've recommended to my clients that they ask new customers / new patients (or at least some fraction of them) how they heard about the business / medical practice, but as far as I know, the clients haven't acted on my advice. |
| Mon 20 May | Martin L. Shoemaker | << I've recommended to my clients that they ask new customers / new patients (or at least some fraction of them) how they heard about the business / medical practice, but as far as I know, the clients haven't acted on my advice. >> Any advertiser who doesn't follow exactly this advice has not a clue which advertising dollars are well-spent and which aren't. Different ad strategies appeal to different clientele, so they need to learn which strategies are attrracting their clientele and spen mor money and effort on those. If they're not doing that, they don't comprehend advertising. |
| Mon 20 May | Paul B. | Maybe there is a fear of commitment from your customers. If they do not make their site public they could yank it down at any time w/o feeling they lost anything . If they make it public then they are forced to keep it for a longer amount of time. Good luck trying to convince them to publish the URL. |
| The bad thing about .NET is... | Wed 15 May | Fleeno Glarkenstein |
| ...you cant search for it! Both Google and AltaVista strip the period off and give you every page that contains the term net. Thats a lot of pages. |
| Mon 20 May | Brad Clarke | 'Friends tell me that command line programs written in .NET languages are just as fast, or faster than the same code compiled with a regular C/C++. ' On my XP partition, I was running a C# IDE (SharpDevelop)which is written in C#. It runs almost as fast as an equivelent native compiled IDE I use for Java. |
| consulting company (body-shop) rant | Mon 13 May | anon |
| How do companies (employers) benefit from dealing with consulting companies that are essentially match-makers? Note that in this case, Im only discussing the companies that unite employer and employee and then proceed to take their fair share of the hourly rate. My POV, is that these companies have a list of customers (employers) that they get help wanted lists from. The post the jobs on Monster, HotJobs, etc and then wait for their Inbox to fill up. Granted some companies serve as filters so the employer doesnt have to sift through hundreds or thousands of resumes. However, most Ive found only look for candidates that would not embarass them terribly by submitting their resume. This is what a headhunter asked me once... HH: I see youve been working with MTS. Have you ever done anything with COM? Me : ... My biggest gripe is that once Im in the door, why should these companies have a right to the money Im making for them. Ive been with a company for the last year and a half at the same client. They pay half my health-care, take care of my social security and take care of my taxes. (Which they get right approximately 60% of the time, I might add.) And they gladly take $20 out of each hour I work. I understand how developers benefit (with respect to GETTING the job), but I dont understand how companies (employers) benefit. Any ideas? |
| Mon 20 May | Eric Kidd | A number of years ago, I received a lot of business through a NH-area contracting agency, and I really valued their services. They found me interesting clients, took less than 20%, provided sensible business advice (if you cared to ask), and once handled collections for me when they accidentally assigned me the Client From Hell(tm). In exchange for a ridiculously low free ($150/quarter) they even offered to reduce their take to 8%, but I told them, 'You're doing a GREAT job! Why should I suddenly decide to pay you less money?' They had sane policies for long-term contracts, and for contractors who got hired. And, when I once used them to *find* a programmer, they found top-notch talent quickly. So, why do companies do business with huge, dishonest body shops when there are true pros who charge less? I think it's the same reason some companies hire bad programmers at low wages to work on critical software: stupidity and incompetence. If possible, try not to work for people like that. :-) |
| should I quit? | Fri 10 May | quitter |
| Hi, Im trying to think of a reason to stay in software besides the money. I got into the field I found it very easy to do, not because I have any particular love for sitting in front of a computer all day. I thought a good litmus test would be to think up some application I really wanted to have, and code it for myself. However, I cant think of anything I really would want to have, so Im thinking perhaps I dont have software in the blood. Has anyone else been in this position? |
| Mon 20 May | Richard | Hey quitter, I have faced situations like yours before. I am a tech guy through and through, but its important to me to be able to make a difference in what I do and exercise my creativity. I like the satisfaction of solving problems however little, and seeing things getting built with my own hands. I have learnt to see achievement in little things, and the sum total of my achievements gives me work satisfaction. Other peoples opinions (outside of pay reviews) are fairly irrelevant. That said, i am very picky and fussy about my work. I get really depressed when I am stuck in a rut. I have never really been in a situation where my work has been routine or dull (with the exception of long term architecture/ documentation work) but I am pretty certain that I wouldn't like it much. I might like it enough if I was paid well for it, but I don't know. I am the same age as you, and yeah, I feel old; which is a really wierd feeling. I look younger than I am (long may it remain so) but I find that in my last few jobs I am always trying to recreate a historically happy time in my working experience. One person mentioned that you can live to work, or work to live. I try to find jobs where I can do both. I am Irish, and we know how to do both. But still as I get older, I wish there was more to my live besides work. I go skiing and love it, I like travelling and i am a bit of a party head too. But a guy I know quit his job and went on a years trip to new zealand, and I was so jealous. I have travelled and worked abroad, maybe you should do something like that too. get a feel for a different working life. Find out what you like about work and what you don't. Maybe its not programming you dislike, just the environment that you are doing it in. If you can't get a lesser working week, try getting more holidays in your next pay review. Use it to really see the world, its refreshing to see a country where people have real priorities. Try it. |
| The advantages of Methodology | Wed 08 May | Ged Byrne |
| In several XP orientated threads it seems that there are a lot of people who agree with most of the ideas in XP, but dislike its packaging as a methodology. Some interesting quotes are: ------------------------------------------------------------------------- the last person that made us wear uniforms was Hitler This engineer has never submitted to dictatorial nonsense of any sort, no matter how sweet the stock options... ------------------------------------------------------------- Nat Ersoz ------------------------------------------------------------------------- This REALLY IS an interesting socio-cultural phenomenon. Many of the quotes from XP proponents above are verbatim quotes from apologists for Communism and various cults. Probably fascism too. ------------------------------------------------------------ Hugh Wells ------------------------------------------------------------------------- I think most people are missing the point, that XP is mostly a way to sell books, consulting, and conference appearances. There are some interesting ideas in the books. Not sure what the big deal is. ------------------------------------------------------------------- anon It seems to me that they are argueing against the idea of having a methodology, rather than XP itself. So, is there any advantage to having a Methodology? I see the following advantages: 1) Team members can work together by establishing a common working practice and vocabulary. 2) It is easier for corporatations to adopt, because the structure of the team is already set out for them. 3) It is easier to initiate new members to the team. Ideally each member of the team to have a broad knowledge of best practice, but it can be hard work getting your average graduate to work his way through code complete. Some people prefer to just be told what to do. 4) It provides a standard for supporters to back, enabling them to raise the profile. 5) It makes it easir for mass market tools to be produced for supporting the methods. For example, we are starting to see the emergence of Refactoring tools. Sure, people have been refactoring for decades, but it is only since Refactoring as a named phenomenum appeared that companies are starting to market tools. |
| Mon 20 May | Nat Ersoz | At the risk of sounding like I'm saying 'me too', uhh, me too. I accept that methodologies are necessary. Everyone has some procedure for getting work done even if they are not formalized. I think its important for an engineering team to formalize their methods. My main reason for doing so is that if you don't do it, someone else will do it for you. And then you're headed quickly into the dilbert zone. All that is really necessary is for you do 'say what you do and do what you say'. It is as simple as that, or at least I want to keep it that simple. Formalizing methods (that is documenting them) is really an insurance policy against human weakness. Anyhoo... I could ramble on for hours... |
| XP is wearing no clothes | Tue 07 May | Hugh Wells |
| I think XP is a classic case of the Emperor wearing no clothes. Most of its tenets are nothing more than good practice, and most have the feel of the lessons of someones first successful development project. I dislike XP because it is exclusionary; the use of new jargon words such as Refactoring to describe existing practices is a classic social technique to exclude non-members from a group. Pair programming is all about requiring people to work together in a certain way. Its not necessary, and the compulsory nature of the requirement is something I find offensive. People in a team work together as required. Theres no need to change that. I think the big reason for XPs popularity is that it strokes the egos of senior developers; that is, the people who decide whether to implement XP. Contrary to the ego-less claims of XP, I think Pair Programming creates a strong hierarchy in which more senior developers receive positive rewards, and since they decide whether its good, thats sufficient to carry the movement forward. I notice proponents adapt their definitions of XP on the fly to include everything their audience considers good, and to reject the bad. Just my view. Im sure others will give me their views. |
| Mon 20 May | Nat Ersoz | OK, John, those are interesting articles. That is exactly what I was interested in. Thanks for posting that and for the direct links. However, I remain skeptical. First, if I didn't think there were any clothes for 'XP to be wearing', then I wouldn't have read XP explained twice - the second time taking notes. So, I'm not hostile to XP (although, granted I made some hostile statements). However, reading through the specific studies, much of the code and evaluation was done in a university setting. The exceptions to these being Ken Beck's and cohorts already documented experiences. For example, I am skeptical about the U. Utah experiment which found that PP resulted in only a 15% increase in man-hours worth of development and a corresponding 15% reduction in code defects. The first thing that should be a tip-off is that the time scales are measured in elapsed time. If this is indeed the case then it takes a team of 2 more time to complete a task than a loner. In the best case, pairs completed the task at 80% of the loner. That means a more than doubling of programming assets for the task. Our company cannot afford that sort of productivity hit. Secondly, the case for XP assumes that unit tests don't exist outside the non-methods universe (OK, I'm exagerating). Neverheless, how does someone deliver code that has predefined performance criteria (as was the case in the Utah study) and not get a perfect score? How does this happen? You know the test scoring criteria, and yet you do not test to that criteria? Again, I'm suspicious. Finally, I agree that collaboration is a powerful tool (hence my ramblings in prior posts over the virues of cubes over offices). It is not my attempt to discount collaboration. |