An interesting article on text-book vrs real-world programming

It was thus said that the Great Mouse once stated: But it's an awfully small "there". I'm thankful we don't have to deal with Agile where I work as I feel the concept is meaningless with respect to the coding we do. My job here is to test several coponents of a much larger product; each component (and there are six we're responsible for) are independent programs that all communicate amongst themselves. Each program is conceptually simple. For instance, one component waits for two particular SS7 [1] messages, does some data lookups and sends a request to another piece over IP; it then waits for a reply on the IP side before responding to the SS7 network. The second component receives the message (from the SS7 component), does some data lookup, and it might in fact send a DNS query [5], send a message to a cell phone [6] and wait for the cell phone to query back to the component before replying to the SS7 component. Perhaps I'm not imaginative enough, but I personally have a hard time seeing how Agile, scrum meetings and test-driven design [3] applies to the project. Heck, it's hard enough testing the fully written components (especially the SS7 component [7]), much less unit testing on individual routines (each component is a "unit"---I can't see any further decomposition going on). It doesn't help that the components are written in C *and* C++ (with respect to unit testing). I best stop before I go into full-on-rant mode. -spc (Running a regression test takes at least a half-hour to set up and that's if everything is running smoothly ... [8]) [1] Signaling System 7---a telelphony network stack [2] [2] and the stack we use *SUCKS* but I've been advised that the SS7 stack we use is, in fact, *BEST OF BREED*, which doesn't bode well for SS7 stacks in general. [9] [3] Okay, I can't tell if the following article series is satire or a genuine attempt at test-driven design: http://xprogramming.com/xpmag/OkSudoku http://xprogramming.com/xpmag/Sudoku2 http://xprogramming.com/xpmag/SudokuMusings http://xprogramming.com/xpmag/Sudoku4 http://xprogramming.com/xpmag/sudoku5 I mean, it's Ron Jefferies, who I understand is a cheerleader for Agile development, but then, he says stuff like: def square_indexes(square_number) result = [] first_row = square_number / 3 first_column = (square_number % 3) * 3 first_row.upto(first_row+2) do | row | first_column.upto(first_column+2) do | col | cell_number = row * 9 + col result.push(cell_number) end end result end That?s a lot of code, and I?m afraid it won?t work. When did 14 lines of code become "a lot"? Is he serious? [4] [4] Please tell me he was writing satire. [5] Caller ID internally is done using DNS records. NAPTR records in fact. Surprising, but on retrospect, it's not a bad match. [6] SMS or proprietary protocol, depending on how fast the SMS network for the vendor is. [7] "One does not simply 'walk' into Mordor," was the response I got when I asked about SS7 networks. [8] Two years and only just last month did I learn that once I open up an SS7 endpoint, I *may* have to wait up to 30 seconds for it to "register" with the network, else sending messages will fail. Did I mention that the SS7 stack we use *SUCKS*? [9] For instance, it maintains static data behind your back. And error conditions? Yeah, you have to crawl into memory *past* a structure to get the actual reason for the error. Seriously. It *SUCKS*.