The Productive Programmer By Neal Ford

Just now i completed reading The Productive Programmer By Neal Ford.

Nice book written by Neal Ford.

Below are few quotations i found from this book.

1) USING A COMPUTER REQUIRES A FAIR AMOUNT OF RITUAL AND CEREMONY.

You have to boot it up, you have to know how to launch applications, and you must understand the interaction model, which can differ between applications. The less you interact with your computer, the faster you can go. In other words, eliminating ceremony allows you more time to get to the essence of the problem. Time you spend digging through a long filesystem hierarchy to find something is time you could be using to be more productive. Computers are tools, and the more time you spend on the care and feeding of the tool, the less work you get done. The science fiction author Douglas Adams had a great quote: “We are stuck with technology when what we really want is just stuff that works.”

Hence

Concentrate on essence, not ceremony.

2) The usefulness of an application list is inversely proportional to its length.

3) Typing is faster than navigation.

4) When coding, always prefer the keyboard to the mouse.

5) Spend a little time each day to make every day more productive.

6) The higher the level of concentration, the denser the ideas.

7) No matter what you are copying and pasting, resuse by copy and paste is evil.

8) Out-of-date documentation is worse than none because it is actively misleading.

9) DRY Documentation
Out-of-date documentation is worse than none because it is actively misleading.

Documentation is a classic battleground between management and developers: managers want more and developers want to create less. It is also a battleground in the war against noncanonical representations. Developers should be able to make changes to code aggressively, to improve its structure and allow it to evolve. If you must have documentation for all your code, it must evolve at the same time. But most of the time, they get out of sync because of schedule pressure, lack of motivation (because, let’s face it, writing code is more fun than writing documentation), and other factors.

For managers, documentation is about risk mitigation.

Out-of-date documentation creates the risk of spreading misinformation (which is ironic, given that part of its purpose is to reduce risk). The best way to prevent documentation from getting out-of-date is to generate as much of it as possible.

10) Repetition is the single most diminishing force in software development.

11) Duplication is evil.

Getting really maniacal about DRY has several positive effects:

a) You get good at refactoring.

b) You end up with a pretty decent design—usually not the best, but much better than what teams usually come up with.

c) You end up rediscovering some of the more common patterns, so you actually understand them.

d) The experienced people on the team have plenty of opportunities to teach about various encapsulation mechanisms, design tactics, etc., because the junior people often can’t figure out how to eliminate duplication and have to ask for help. (And when you explain these things in context, they tend to stick a little better.)

12) Testing is the engineering rigor of software development.

13) Refactor comments to methods.

14) Static analysis tools represent cheap verification.

15) Source Analysis

As the name implies, source analysis tools look at your source code, searching for bug patterns.The tool I used in the following code is PMD, an open source tool for Java. PMD offers a command-line version, Ant support, and plug-ins for all major development environments. It looks for problems in the following categories:

Possible bugs
For example, empty try...catch blocks

Dead code
Unused local variables, parameters, and private variables

Suboptimal code
Wasteful string usage

Overcomplicated expressions
"Reuse" via copy and paste

Duplicate code (supported by an ancillary tool called CPD)
"Reuse" via copy and paste

16) Don’t create global variables, even the object kind.

17) YAGNI STANDS FOR “YOU AIN’T GONNA NEED IT.” It is the battle cry of agile project development to help prevent speculative development. Speculative development occurs when developers tell themselves, “I’m sure I’m going to need some additional functionality later, so I’ll go ahead and write it now.” This is a slippery slope. The better approach is to build only what you need right now.

18) The Law of Demeter

The Law of Demeter was developed at Northwestern University in the late ’80s. It is best summarized by the phrase, "Only talk to your closest friends." The idea is that any given object shouldn’t know anything about the internal details of the objects with which it interacts. The name of the law comes from the Roman goddess Demeter, the goddess of agriculture (and therefore of food distribution). Although she was not technically an ancient philosopher, her name makes her sound like one!

More formally, the Law of Demeter says that for any object and method, the only methods that should be invoked are the following:

• The methods of the object itself
• Parameters of the method
• Any objects created within the method

19) Let’s say you have a Person class with two fields: a name and Job. Job also has two fields: title and salary. The Law of Demeter says that it is not acceptable to call through Job within Person to get to the position field, like this:

Job job = new Job("Safety Engineer", 50000.00);
Person homer = new Person("Homer", job);
homer.getJob().setPosition("Janitor");

So, to make this adhere to the Law of Demeter, you can create a method on Person to change the job, and then ask the Job class to perform the work for you:

public PersonDemo() {
Job job = new Job("Safety Engineer", 50000.00);
Person homer = new Person("Homer", job);
homer.changeJobPositionTo("Janitor");
}

public void changeJobPositionTo(String newPosition) {
job.changePositionTo(newPosition);
}

What benefit has this change created? First, notice that we’re no longer calling the setPosition method on the Job class, we’re using a more descriptive method named changePositionTo. This emphasizes the fact that nothing outside the Job class has any idea of how position is implemented internally to Job. Although it looks like a String now, internally it might be an enumeration. This information-hiding is the main point: you don’t want dependent objects knowing about implementation details of the internal workings of a class. The Law of Demeter prevents this by forcing you to write methods on classes that specifically hide those details.


About the Author

Neal Ford is an Application Architect at ThoughtWorks, a global IT consultancy with an exclusive focus on end-to-end software development and delivery. Before joining ThoughtWorks, Neal was the Chief Technology Officer at The DSW Group, Ltd., a nationally recognized training and development firm. Neal has a degree in Computer Science from Georgia State University specializing in languages and compilers and a minor in mathematics specializing in statistical analysis. He is also the designer and developer of applications, instructional materials, magazine articles, video presentations, and author of the books Developing with Delphi: Object-Oriented Techniques (Prentice-Hall, 1996), JBuilder 3 Unleashed (Sams, 1999) (as the lead author), Art of Java Web Development (Manning, 2003), and No Fluff, Just Stuff Anthology: The 2006 Edition (editor and contributor). His language proficiencies include Java, C#/.NET, Ruby, Object Pascal, C++, and C. His primary consulting focus is the design and construction of large-scale enterprise applications. Neal has taught on-site classes nationally and internationally to all phases of the military and to many Fortune 500 companies. He is also an internationally acclaimed speaker, having spoken at numerous developer conferences worldwide.If you have an insatiable curiosity about Neal, visit his web site at http://www.nealford.com. He welcomes feedback and can be reached at nford@thoughtworks.com.