Product Description

Want to be a better developer? This books collects the personal habits, ideas, and approaches of successful agile software developers and presents them in a series of short, easy-to-digest tips. This isn't academic fluff; follow these ideas and you'll show yourself, your teammates, and your managers real results. These are the proven and effective agile practices that will make you a better developer.

This book will help you improve five areas of your career:

• The Development Process
• What to Do While Coding
• Developer Attitudes
• Project and Team Management
• Iterative and Incremental Learning

These practices provide guidelines that will help you succeed in delivering and meeting your user's expectations, even if the domain is unfamiliar. You'll be able to keep normal project pressure from turning into disastrous stress while writing code, and see how to effectively coordinate mentors, team leads, and developers in harmony.

You can learn all this stuff the hard way, but this book can save you time and pain. Read it, and you'll be a better developer.

Product Details

• Amazon Sales Rank: #22798 in Books
• Published on: 2006-04-04
• Original language: English
• Number of items: 1
• Binding: Paperback
• 189 pages

From the Publisher
These are the proven, effective agile practices that will make you a better developer. You'll learn pragmatic ways of approaching the development process and your personal coding techniques. You'll learn about your own attitudes, issues with working on a team, and how to best manage your learning, all in an iterative, incremental, agile style. You'll see how to apply each practice, and what benefits you can expect. Bottom line: This book will make you a better developer.

About the Author
Venkat Subramaniam, founder of Agile Developer, Inc., has trained and mentored more than 3,000 software developers in the US and Europe. He has significant experience in architecture, design, and development of software applications. Venkat helps his clients effectively apply and succeed with agile practices on their software projects, and speaks frequently at software development conferences. Venkat is also an adjunct professor for the practice of computer scient at University of Houston and teaches at Rice University School for Continuing Studies. He holds a BS in Computer Engineering, MS in Electrical Engineering and Ph.D. in Computer Science. He is a recipient of the 2004 UH Computer Science Department Teaching Excellence award.

Excerpted from Practices of an Agile Developer: Working in the Real World by Venkat Subramaniam. Copyright © 2006. Reprinted by permission. All rights reserved.
31 Tell, Don’t Ask

"Don’t trust other objects. After all, they were written by other people, or even by you last month when you weren’t as smart. Get the information you need from others, and then do your own calculations and make your own decisions. Don’t give up control to others!"

"Procedural code gets information and then makes decisions. Object-oriented code tells objects to do things." Alec Sharp [Sha97]hit the nail on the head with that observation. But it’s not limited to the object-oriented paradigm; any agile code should follow this same path.

As the caller, you should not make decisions based on the state of the called object and then change the state of that object. The logic you are implementing should be the called object’s responsibility, not yours. For you to make decisions outside the object violates its encapsulation and provides a fertile breeding ground for bugs.

David Bock illustrates this well with the tale of the paperboy and the wallet.9 Suppose the paperboy comes to your door, requesting his payment for the week. You turn around and let the paperboy pull your wallet out of your back pocket, take the two bucks (you hope), and put the wallet back. The paper boy then drives off in his shiny new Jaguar.

The paperboy, as the "caller" in this transaction, should simply tell the customer to pay $2. There’s no inquiry into the customer’s financial state, or the condition of the wallet, and no decision on the paperboy’s part. All of that is the customer’s responsibility, not the paperboy’s. Agile code should work the same way.

A helpful side technique related to Tell, Don’t Ask is known as command-query separation [Mey97]. The idea is to categorize each of your functions and methods as either a command or a query and document them as such in the source code (it helps if all the commands are grouped together and all the queries are grouped together).

A routine acting as a command will likely change the state of the object and might also return some useful value as a convenience. A query just gives you information about the state of the object and does not modify the externally visible state of the object.

That is, queries should be side effect free as seen from the outside world (you may want to do some pre-calculation or caching behind the scenes as needed, but fetching the value of X in the object should not change the value of Y).

Mentally framing methods as commands helps reinforce the idea of Tell, Don’t Ask. Additionally, keeping queries as side effect free is just good practice anyway, because you can use them freely in unit tests, call them from assertions, or from the debugger, all without changing the state of the application.

Explicitly considering queries separately from commands also gives you the opportunity to ask yourself why you’re exposing a particular piece of data. Do you really need to do so? What would a caller do with it? Perhaps there should be a related command instead.

Tell, don’t ask. Don’t take on another object’s or component’s job. Tell it what to do, and stick to your own job.

What It Feels Like

Smalltalk uses the concept of "message passing" instead of method calls. Tell, Don’t Ask feels like you’re sending messages, not calling functions.

Keeping Your Balance

• Objects that are just giant data holders are suspect. Sometimes you need such things, but maybe not as often as you think.
• It’s OK for a command to return data as a convenience (it’d be nice to be able to retrieve that data separately, too, if that’s needed).
• It’s not OK for an innocent-looking query to change the state of an object.

Customer Reviews

Intelligent and Informative
I've worked as a web developer for 10 years and in that time I've worked for numerous companies. I wish every one of them had read this book and taken lessons from it.

If you've been in the position where processes aren't working, projects are a nightmare race to deadline, the team isn't cohesive. If you're thinking surely theres a better way to run projects than this, then this is the book for you.

Intelligently written and well argued, it covers many concepts you may well already be familiar with and gives them some foundation and practical ways in which they can be adopted.

If you wish to be a better developer in a better team buy this book.

More useful for inexperienced developers
I had read a few reviews on this book, all positive so I was really looking forward to reading it.

While the book encourages some very worthwhile and useful techniques I did find that many of the tips were practices that any reasonable software developer should be considering as a matter of course, not just to be agile.

I would say that this is an excellent read for developers with only a few years of experience with some great tips on how to be more productive.

However for more experienced people it should just be memory jogger and give you a chance to become enthused and really try to do the 'right' things again. Get through the 'software is alot like surfing' analogies and some of the more ivory tower comments (try telling you boss that a late fix cannot go in because as a developer you do not have authority to degrade company assets i.e. the source code) and focus on the real points of the text, often seemingly obvious but its surprising how few developers and projects follow the any sort of methodology at all.