Hehe for a bit of a flashback have a look at this lecture given by Edsger W.Dijkstra back in '72. http://www.cs.utexas.edu/users/EWD/ewd03xx/EWD340.PDF
(For the index to that collection look at:) http://www.cs.utexas.edu/users/EWD/indexBibTeX.html -----Original Message----- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Sunday, August 18, 2002 09:44 To: Struts Users Mailing List Subject: Re: XP (and not the Microsoft kind) Kent Beck's book, Extreme Programming Explained, covers all these issues in-depth. Anyone who's the least bit interested in XP should read this book first. It's less than 200 pages and covers all the bases. -Ted. Stan Baranek wrote: > ok - devil's advocate: > > Open Workspace - done it. great idea but I want to pick the other > programmers who go into the pod with me. > Iterations - of course. > Retrospective - put some lipstick on this pig. > > It all sounds great but what if you don't want to give up your cushy > office to sit in a big room with a bunch of lousy programmers > explaining things to them all day before a deadline only to see them > leave at 4 in the afternoon while you stay 'till 2am to finish the > coding. And repeat that every day for 2 months and then watch the > pointy haired boss pat them on the back for their hard work. What if > I want to telecommute? > > Many brick and mortar companys have bad programmers that are lazy and > just don't care that much about deadlines because nobody ever gets > fired. This is a shame since many good programmers are unemployed > right now. > > I totally agree with disposing of much of the formality. Most people > get so wound up with formality like the Rational Unified Marathon of > processes that they completely forget about a little something called > "common sense". > > Here is a typical senario from an IT shop: - let's call it IT shop "X". > Use Cases are produced whith complete jiberish straight out of a > Rational Rose example which makes absolutely no sense in this > particular application. Wasting weeks completing verbose documents > that don't even resemble the finished system and never get read by > anybody and get lost in the corporate backup of Terabye infinity. > Users that scratch their heads while saying "yah. Yah - that makes > sense I guess." when you know full well they don't understand a damn > word on the document. Why not dum down the use-case so that it > actually describes what the system does? I don't think Rational > carved their examples in stone. Pointy haired manager gives analyst a > pat on the back for producing more than 4 pounds of documents. > Programmers code quitely in the corner with the REAL use-cases in > their heads. Bad Programmer "C" makes a pretty collage by cut/pasting > code from other better programmers. A new IT directive is emailed > out: "We will switch technology every 2 months randomly and for no > good reason so that we don't get really good at anything and we don't > spend too much time building actual applications. Programmer "X" would > really like to work with technology "Y" so we will take the highest > priority project and announce to the entire company that we will > complete this project in half the required time with the completely > new technique that nobody knows yet.... and we will do it while > blindfolded... and smoking a cigarette. Ready - set - go." > > You're much better off getting a couple of GOOD programmers to > understand the system AND sit in the same room to hammer it out. Down > with documentation! Who's with me? (did I say that out loud?) > > XP sounds great for ideal situations but I don't think some of the > practices would fly in all shops. Although I wish I lived in a > utopian world where users and IT could get together, share a coke > while holding hands and singing Cum-ba-ya. Sometimes it's like trying > to bring peace in the Middle East (which I also wish was possible). I > can see XP being hyped, mandated, tried, failed, try it again, failed > and being dropped for ever like ISO9000. > > People aren't convinced they have a problem. > People know they have a problem, but are afraid to risk doing > something different to try to solve it. > People know they have a problem, are willing to try to solve it, but > misunderstand the problem they are trying to solve. > People know they have a problem, are willing to try to solve it, > understand the problem, but are constrained to the status quo. > Some people are complete idiots without a stitch of common sense. > These people will always have problems. > > ...anyways. It's the programmers that actually get the job done. > Managers and users are merely window dressing although we do have to > make them happy:-) > > Disclaimer: The characters of Bad Programmer "C" and Programmer "X" > were ficticious. Any similarity to actual programmers is completely > coinsidental and should in no way be used to incriminate me. The > pointy haired manager is real person and I can give you his address if > desired. > > Here's lookin up your old address, > Stan -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
