This Weeks GiveAway:

[Carl Trusiak]

We are giving away four copies of "The Pragmatic Programmer: From Journeyman to Master", and the Authors, Andy Hunt and Dave Thomas , are on-line!
Everyone give Andy and Dave a warn welcome (maybe we can talk them into mirroring their Tips Page )

[John Zukowski]

Don't you have any more books from that Zukowski guy to give away....
------------------
John Zukowski Author of "Definitive Guide to Swing for Java 2" and "Java Collections"

[Jonathan Andrew King]

Originally posted by Carl Trusiak:
We are giving away four copies of "The Pragmatic Programmer: From Journeyman to Master", and the Authors, Andy Hunt and Dave Thomas , are on-line!
Everyone give Andy and Dave a warn welcome (maybe we can talk them into mirroring their Tips Page )

Hi,
Got the book already, A good read. A Principle Consultant at a previous company went to a SANS conference and came back with a copy for everyone on the development team.
I am working in Oracle 9i and you can develop the entire middleware tier using wizards.

[Carl Trusiak]

Originally posted by John Zukowski:
Don't you have any more books from that Zukowski guy to give away....

You just want to win another copy

[danny crasto]

I love a chance at getting this

[Suzanne Reiner]

Our office has yet to define a "workable" method for tracking and managing code. Similar to many offices, our method is... "yeah, we have that 'standards document' thingy... I have no idea what's in it... but I'm sure its pure EVIL!" and "WHY the HELL did you do THAT?" or "Test-box?"
Seems the difficulty lies in determining a method of tracking and documentation that will "feel" comfortable and reasonable to us most of the time. And locating that sweet spot: the development environment standard (ie text editor vs. which IDE).
To that end we have taken up readin' and discussin' books to help us define our directions more clearly. Problem thus far is the rigidity (of topic and ourselves). Perhaps we are taking the more hardline... "I don't want anyone dictating to me" approach versus the "I can be me and still program within our block of standards."
Love to get a copy of this book ('specially a free copy). Suppose I'll have to hold my breath (hah!) and cross my fingers to get one the cash-free way.
'Course... there is always the Super.Kick( Stomp( "Pout" )) method... I inherited from my Mother....

[Heath Lilley]

This book sounds like something I could use. I have been looking for a good book that shows the "big picture" of software development. I have read a lot of technical books (Orielly) but they don't have any of the fundamental development theories that I desire. I also wanted to get a feel for where current software designs came from, in the hopes of getting a handle on where they are going. I have looked at XP and UML in terms of design methodologies, however the books I have read do not have a "Ground Zero" starting point.
Does anyone have any suggestions of other books that have what I am looking for? Language independent text would be a plus. Java is a wonderful language (based on my limited exposure) but it is not the only language out there.

[This message has been edited by Heath Lilley (edited May 22, 2001).]

[Mirko Froehlich]

Hi Andy and Dave, great to have you here! I read your book last year and liked it a lot (particularly the nice analogies to boiling frogs and such... ;-))
I actually bought it twice because I somehow lost the first copy when I took it with me on vacation. ;-)
-Mirko

[Desai Sandeep]

Hi Andy and Dave, it is nice to have you here!I am looking forward to getting this book.It is bound to be on my shelf sooner or later
Thanks,
Sandeep

[Andy Hunt]

Hi everyone!
We're here. Thanks for the kind words about The Pragmatic Programmer; I'm pleased to say that the Japanese translation continues to do very well in Japan. It was in the top 100 over there for quite a while -- almost three months, I think.
So what's on everyone's mind?
------------------
Andy Hunt
Author of "The Pragmatic Programmer: From Journeyman to Master

[Avijeet Dash]

Oh! I just saw the table of content on amazon and it looks sexy.
Its a kind of book i would dream to write.

[Andy Hunt]

Well I don't know about *sexy* per se; but it was a lot of fun to write.
Dave and had been consulting together on various projects over the course of a few years, and we noticed that we kept saying the same sorts of things to people over and over again. Not always rocket science, but basic bits of development practice that don't seem to be taught in school. Stuff you pick up after years on the job, or learn from a mentor on the job.
So we decided to write a book. Helpful tips, tricks, techniques and philosophies, but presented in a way that's readable and enjoyable. God knows how many comp-sci books I've read over the years that put me to sleep by page twenty.
That's easier said than done, of course, but I think we did pretty well at describing concepts of personal productivty, development methodology, computer science and so on using funny stories, neat metaphors and more than a few jokes.
But the main thrust of the book is the idea of being pragmatic, not dogmatic. Too many folks are convinced that THEIR WAY (whatever that happens to be) is the ONLY WAY. It doesn't matter whether their way includes XP, UML, XML, Java, Cobol, PalmOS or a Ouija board. All of these things have their place, and their usefulness (well, maybe not the Ouija board). Nothing is a panacea, and nothing works for everyone everytime. You must constantly analyze what you're doing -- and why you are doing it -- and adapt accordingly. In fact, isn't that the marine's motto? "Improvise, Adapt, Overcome".
Since then, we wrote the definitive English-language reference for a new language called "Ruby", and have been active in the Agile Alliance (www.agilealliance.org -- see if you can find me and Dave in the picture :-)
Does that answer your question?
------------------
Andy Hunt
Author of "The Pragmatic Programmer: From Journeyman to Master

[shailesh sonavadekar]

avijit , you can delete your own post by clicking on edit / delete icon & selecting delete option.

Please do the needful.
Shailesh.

[shailesh sonavadekar]

welcome Andy Hunt. It is nice to have you in OOPs forum. It will great week with you . Really like to hear pearls of wisdom from you guys.
Once again Big Welcome.
Your Friendly Bartender
Shailesh.

[Andy Hunt]

Ahem, that would be *rubies* of wisdom :-)

[Avijeet Dash]

anybody, how is this book?
After the Gold Rush : Creating a True Profession of Software Engineering (Best Practices)
By
Steve C McConnell
thanks.

[shailesh sonavadekar]

andy , I feel Geniune pearls are more costly than rubbies. Any specific reason for having rubbies of wisdom ? this poor spul will enlightened with first lesson fron the great author .
YOur Friendly Bartender
Shailesh.

[shailesh sonavadekar]

After the Gold Rush : Creating a True Profession of Software Engineering (Best Practices)
By
Steve C McConnell

Avijit , As you know Steve McConnell is the great author of " Rapid Application development " , which is must read on many oops & XP guru's site. He is great author. I haven't read this one. I have read other book by him.
I think the book you have mentioned must be great.
Where the hell , in india you got hold of his book. Because his books are not available at indian price. Now Microsoft press has done great thing. His books are coming at indian price even RAD also.
Shailesh.

[Andy Hunt]

Sorry, that was just a joke expressing a preference for Ruby over Perl.
I used to use Perl for a huge number of sundry programming tasks, from Makefile assistance to code generation to test harnesses, etc. Now I use Ruby for all of that. I like to describe it as a cross between Smalltalk and Perl -- it has the handiness, the raw power of Perl, but the elegance of Smalltalk.
One of our suggestions in The Pragmatic Programmer is to learn a new programming language every year to stretch your neurons, and I think Ruby is a fine candidate. It will even improve your Java programming :-)
Do you remember that old electric shaver commercial where the guy says, "I liked it so much, I bought the company!" Well, we found Ruby on the net and liked it so much, we wrote the book!
/\ndy
[This message has been edited by Andy Hunt (edited May 22, 2001).]

[Mike Cunningham]

Does this book cover anything on UML Tool comparisons? I was wondering how the UML tools from Rational and Together compare? What is the best value for a small shop needing a UML tool?

[shailesh sonavadekar]

I was also joking.
Good point andy. great thing you said. You said something about ruby. it hammered me on neurons protected by my skull.


in last month I think , there was discussion on itworld.com & uncle bob " Robert C. Martin " was there.
He mentioned that the languages of the future : - Smalltalk of which I am greatest fan , no doubt ( great King , Dr. Alan Kay ) , Pyhton : - I have not touched this snake & Ruby : - of which my nuerons have got not a smallest inkling.
Can you please tell more about that ? Why you feel it is important ? Can you give your comment on Uncle Bob's Prediction ?
you are going for ruby becuase of mixture of perl + smalltalk.
No Python ? Any specific reasons. When you found about ruby ?
wrote the book also. Grea Internet Author.
Which Book you have written on Ruby ? is it out in market ? Where on net I can get good resources about Ruby ? your special sites ?
This disciple of yours is truely enlightened by your sermon. When i spoke about Ruby , giving reference of Uncle Bob , everbody asked what is Ruby ? Please go way you fool. Same was the case with Smalltalk. People not knowing about smalltalk can speak with authority that I am fool for saying Smalltalk as lanuage of future. HaHa. Today , I found none other than you great Andy to share the thoughts. Somebody who knows about Ruby & smalltalk. You made my day. I will rest in peace today.
Another thing about learning programming languages ? How many programming languages we have to learn , Andy ? I think we have more than 200 new programming languages ever year. I have read somewhere. Not sure. Correct me , Teacher. Whcih will work ? which will not ? which is good , whch is bad ? how to decide ? From where to get the entire info ? I feel It is herculean task.
Please give me more pointers on this topic & on ruby & about the book on Ruby By You.
I think you are not giving e-mail for some secrete reasons ? otherwise I would have pestered you via e-mail .

Your Disciple
Shailesh.

[This message has been edited by shailesh sonavadekar (edited May 22, 2001).]

[shailesh sonavadekar]

ooops , teacher. I asked you too many questions at one go ? please don't punish me.
I got a lot of answers about ruby from your site. can not download book ?
Why Japan is important from your perspective ? Why these people are using ruby more ? Are they better programmers ? What is your general observation about them & their approach for s/w dev?
Are they ahead of world ? As they are in robotics , game progamming , electronic & automobile industry , with telecom as latest foray.
please enlighten this disciple.

Shailesh.

[Pauline McNamara]

Does "The Pragmatic Programmer" have anything to offer people who are not yet journeywomen, but are still at the apprentice stage?

[Andy Hunt]

The Ruby book we wrote is entitled "Programming Ruby: The Pragmatic Programmer's Guide". Ruby itself was created in Japan, so all the doc was in Japanese. We wrote the first (and so far only) English-language book on Ruby. More are coming, I'm told.
Ruby is conceptually clean and elegant, unlike Perl or Python. It follows the Principle of Least Surprise -- once you know the basics of how it works, there are very few surprises. You can guess at things you've never tried and it usually works out just as you expect.
Ruby sites: www.rubycentral.com, www.ruby-lang.org, and www.pragmaticprogrammer.com.
I find that I can write a whole boatload of code in Ruby that not only compiles the first time, but runs correctly as well. I can't do that in any other language. Java usually takes a few tries, and C++ usually takes a few dozen tries :-) :-)
As to how many languages to learn, probably one or two new ones a year. I'm probably fluent in maybe a dozen or so.
The chief advantage is in learning different approaches to solving common problems. I've not tried Dylan or Self yet, but those would be worthy candidates simply because they are so different. So to cull down the list of possible languages to learn, don't learn one that's too similar to languages you already know.
As to Ruby, I find it fits in well with my mental processes and thought patterns -- a nice virtue in a language. It may not fit in well with everybody, and that's fine. I find it to be clean and elegant, which can hard to explain, and not always universally appreciated. The best advice I can give here is to simply try it.
/\ndy

[Andy Hunt]

As to the question about the Japanese: I have no special connection to Japan, that's just where Ruby was invented. We've gotten responses from readers internationally, especially from Germany, the UK, Australia, Italy, Japan, and various Scandanavian countries. In fact, Dave and I are speaking the Java and Object Oriented Conference in Aarhus, Denmark, this fall, and we'll be giving a few presentations at OOPSLA as well.
Also, the first international Ruby conference is this fall, just before OOPSLA (also in Tampa).
/\ndy

[Andy Hunt]

Originally posted by Pauline McNamara:
Does "The Pragmatic Programmer" have anything to offer people who are not yet journeywomen, but are still at the apprentice stage?

Yes, I think so.
The basics of a pragmatic approach are useful and effective even to a novice, and would probably spare a lot of people a lot of pain if more novices were taught this way to begin with :-)
Some of the techniques may not seem applicable, or may describe bits of computer science with which you are not yet familiar, but that's okay: one of the things we strongly recommend is to never let an unanswered question just sit there.
When you come across something with which you aren't familiar, chase it down! To the ends of the Earth, if need be :-) Never take "I don't know" as the final answer.
So yes, I think you will find the book helpful. And if there are areas where you think we could better serve the apprentice stage, please e-mail us and let us know.
/\ndy

[Pauline McNamara]

How about encapsulation? I just read in another forum here that entry level books don't cover this as much as they should, so one has to go look for more advanced sources.
Pauline

[shailesh sonavadekar]

thanks for the information. It was really great. you are typing too fast , andy. Beatine me in Speed.
Regarding learning new programming languages , your explaination burnt my neurons. I have to get to my senses & think more on this. Then , I will pester you on this.
Thanks for the conference info. I am india. No chance of going to any of these.
Thanks.
Your Friendly Bartender
Shailesh.

[Andy Hunt]

Originally posted by Pauline McNamara:
How about encapsulation? I just read in another forum here that entry level books don't cover this as much as they should, so one has to go look for more advanced sources.
Pauline

Encapsulation is critically important. What else do you want to know about it? :-)
We've found that most OO principles fall out of two very basic ideas: orthogonality and the DRY principle.
DRY stands for "Don't Repeat Yourself". It means that every piece of knowledge in a system has a single, authoratative source.
Orthogonality means that things that aren't related should stay unrelated. If A has nothing to do with B, then you should be able to change A and B willy-nilly without doing any harm to each other. Now, what happens of course is that a subtle dependancy creeps in, such that changes to A ripple through to B, C, etc.
This "creeping dependancy" phenomena will kill any project dead in its tracks, making the software brittle and unmaintainable.
So if everything minds it's own business, and everything is done in only one place, most of the other OO concepts (low coupling, high cohesion, encapsulation, etc.) fall out for free.
/\ndy

[Dave Thomas]

Originally posted by Mike Cunningham:
Does this book cover anything on UML Tool comparisons? I was wondering how the UML tools from Rational and Together compare? What is the best value for a small shop needing a UML tool?

No, we don't compare tools at all. Partly that's because we don't often come out in favor of tools such as Rose. This isn't a criticism of Rational or Together, but more a philosophical leaning on our part.
The full discussion would be too long for here, but I can perhaps go through the headlines.
Firstly, what are the diagrams for? Are they for communicating with the customers, the end users of the software? If so, how can you tell if they actually do communicate? Do customers want to see a wall full of stick figures and ovals, or would they rather play with a mock-up or prototype. Which communicates better?
Perhaps the diagrams are intended to communicate between designers and developers? That's probably reasonable up to a point. Some good activity diagrams are a great tool, as are some high-level class diagrams. Produce them in the simplest way possible, use them, and throw them away. Don't follow the lead of one company we worked with. Their designers spent a year producing what was probably the world's largest class diagram: it literally wallpapered the entire developent area. No one could ever hope to understand it all. In fact, they took so long doing this the project was canceled. (And of couse we also have a problem with designers handing designs to coders, but that's a seperate thread).
"You can't throw the diagrams away!" you cry. They're documentation. Uh huh. Are they guaranteed to be 100% up to date? Perhaps if you're using Together and you're careful. But to be honest we've rarely seen this happen in practice. Instead, the diagrams are a millstone: developers are told by their managers that they must maintain them, but in their hearts they know that they are increasingly innaccurate and misleading. Why not just use good browsing tools that extract the same kind of information from the authoritative source: the code?
So, that's a long (and probably the wrong) answer to a straightforward question.
Dave

[Dave Thomas]

Originally posted by shailesh sonavadekar:
I got a lot of answers about ruby from your site. can not download book?

You should be able to view and download the Ruby book from Ruby Central. There are also versions in French, and it's available as a Windows help file.
Dave

[This message has been edited by Dave Thomas (edited May 22, 2001).]

[Avijeet Dash]

Dave,
I read the posting where you have said about Design Paralysis.
Do you have some idea/solution to the genuine problems you have mentioned.
thanks

[Dave Thomas]

Originally posted by Avijeet Dash:
I read the posting where you have said about Design Paralysis. Do you have some idea/solution to the genuine problems you have mentioned.

Analysis Paralysis is common, and is easy to fall in to. In fact, I found myself in the state just yesterday. I'm writing a fairly complex database-driven scheduler, and I've spent a week writing down various schemes for getting the next entry from the database (a week? Well, it is pretty complex, and there are lots of factors that affect the decision. Anyway...) I suddenly noticed that I was in paralysis: I'd spent a long time, and had generated pages of notes, but hadn't really moved along any. I'd been going around in circles: if I do it this way it'll be efficient, but I'll have problems with concurrent access, so I'll do it this way instead, but then I'll have performance problems, so...
So, I decided to break the log jam. Today I'm writing code. It doesn't matter whether it's good code or bad code. I'm just going to write pieces of the solution and see what they say to me. It isn't going to be a prototype, as I don't particularly want to examine any particular behavior. Instead, it's going to be closer to what we call a tracer bullet solution, an end-to-end implementation that you write fast, and that illuminates the way to the target. I know that I'll end up throwing some parts away and keeping others. But I also know that I'll break the logjam by doing this.
In the book, we talk about choosing the moment to start something. At times, you be in the position where you feel uncomfortable starting: some tiny voice is saying "wait!". We suggest that you listen to this voice: often it's trying to tell you that you don't understand the thing you're about to start. But we also say that it would be a bad idea to use this as an excuse to put your feet up and play solitare. Instead, we recommend trying to find out what the problem is. Prototype, or brainstorm with colleagues, and try to discover what's troubling you. This will lead to greater understanding, and you'll find yourself being productive.
A different issue is when teams suffer from analysis paralysis. This is when a team gets hung up producing acres of class diagrams, and when entire weeks are spent in meetings. No code is written, and it's difficult to see any real forward progress. To break this pattern, you first have to find out what's causing it. Sometimes the answer is scary: no one wants to start coding because no one believes it will actually work. I've seen this happen at least twice. The only fix I know of for this is to cancel the project as it stands and restart it, this time using less ambitious goals and tigher deadlines. Rather than "rewrite the reservations system", have something like "write a subsystem that consolidates itineraries and have something to show in 4 months". If you design code properly, it's far easier to write something small and grow from it than it is to write something massive, all at once. XP has this right: look for small increments of business value and deliver them. -- Dave

[Avijeet Dash]

but again...
If you don't design the bigger picture and start coding looking at a small functionality, you may find its not scalable and may have to throw the whole code and hence wastage of billable time agian.
what is that we are trying to say here
1. Less design - start prototyping
2. Design but don't fall pray to the infinite loop
3. avoid [bigger] class digrams / sequence digrams
4. use light weight or heavy weight process depending business value context
I would think a good amount of design and brain stroming will help in coding. though we get bit frustrated after a long design session but we should be smart enough to see the positive side of it.
what do you say?

[Dave Thomas]

I think I'm saying that you design as much as you need to, and that you probably need less design than you think. Many XP projects succeed without ever having had a separate design phase. They have shown that it is possible to evolve a design with the code.
Having said that, I'd distinguish design from architecture (and here's where I break ranks with XP). I think a project benefits from having a clear architecture, something that helps people understand where all the components go. It's probably worth spending a day on this up front, and then reviewing it periodically as you go along. XP uses metaphor to replace architecture, and I find that too woolly an idea.
What I definitely do not believe in is the idea that you have to design the system before implementing it. Firstly, design at that low a level is implementation, but without having the benefit of running code to validate that its correct. Secondly, unless you're working in a totally stagnant domain, the world will change during implementation. You may as well code on the basis that things will be changing.
So, I'm thinking that design is something that grows and evolves in parallel with the other development activities, rather than a phase of the project. Martin Fowler's essay Is Design Dead? is a good read.

[Anonymous]

Welcome Andy and Dave!!
Does this qualify as a reply and register me for the book drawing? :-)
Sound like a great book!
------------------
Rudi Lopez
Web Developer
JPMorgan Chase
[e-mail]

[Nick Kellett]

Although I'm an entry-level Java web developer, I've been programming for many years. Between that experience and my new work, I've seen the miserable effects of lots of "DON'T DO"s. Your book sounds like a good way to learn more about the high-end (and less obvious) programming skills for project development and maintenance. I don't know much about refactoring except that it is originally a Martin Fowler concept?

[Dave Thomas]

Originally posted by Nick Kellett:
Although I'm an entry-level Java web developer, I've been programming for many years. Between that experience and my new work, I've seen the miserable effects of lots of "DON'T DO"s. Your book sounds like a good way to learn more about the high-end (and less obvious) programming skills for project development and maintenance. I don't know much about refactoring except that it is originally a Martin Fowler concept?

Thank you. I'd like to think so. All developers will recognize much of what they already do in the book, but possibly with a different twist. Most developers will also find stuff that's new. Me, I read it for the quotes at the start of most sections
Refactoring has been around for a while, and under a number of names. Martin wrote the book "Refactoring", and has probably done the most to spread the word. It has also helped that refactoring is at the core of eXtreme Programming.
Like many of the concepts we discuss, refactoring is all about courage and risk. Going in to some part of a development knowing that you'll not commiting yourself for all time is very liberating.
Dave

[vaibhav punekar]

i think there are lot of people expecting this very fantastic and useful book.Everybody is in que to get it.So who will be those lucky guys.If anybody of them is from Pune India I would reach to get it atleast xeroxed.I m praying to Almighty to let me be the lucky one this time.So anxiously waiting for the draw.............

[Sanjeev Arya]

Originally posted by Nick Kellett:
I don't know much about refactoring except that it is originally a Martin Fowler concept?

Nick,
I am sure (and Martin would probably second this if he's reading it ) that refactoring is not an "original" Martin Fowler concept. People were even working on Refactoring tools in their thesis (at Illinois I guess) before his book was even published. It is like saying "Columbus discovered America!"
He might be the first (and till now the best) person to have popularized it. Anyone who has programmed reasonably for a reasonable length of time and then read the book, is likely to have said: "Hey, I did that, ...just didn't know I was refactoring!"
Sanjeev