File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Agile and Other Processes and the fly likes Clean code : Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Clean code : "human factor question"" Watch "Clean code : "human factor question"" New topic

Clean code : "human factor question"

pascal gehl

Joined: Jun 17, 2002
Posts: 14
Hi all,

First: congratulations for the book, I love it, it's my new bible after "Working effectively with legacy code" and "refactoring".

Here is my question.
I really enjoyed/still enjoy reading this book, but I'm an easy target, I believe in elegance in code, I like it, I feel good and proud when my code is easy to read.understand.

I work in a team where some guys (please sit down and take a Xanax) like "copy and paste" because "every class is independent" and hate my code because "There are too much classes and interfaces it's too complicated" and like "to put everything in one class because we exactly know where everything is".

How can I convince/turn them (like vampires) without loosing my calm and alienate them to me?

Jeanne Boyarsky
author & internet detective

Joined: May 26, 2003
Posts: 33102

Slowly! Seriously, I would look for something small - like showing how reuse can reduce risk and provide only one place where bugs need to be fixed.

The clean code promo is over, but I'm sure you'll still get interesting discussion on this question.

[OCA 8 book] [Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
Frank Carver

Joined: Jan 07, 1999
Posts: 6920
This is always an interesting conversation. I have had similar discussions in several jobs.

My personal style is to refactor everything within an inch of its life, and ruthlessly remove duplication. I have found, however, that this approach can occasionally increase rather than decrease future maintenance work. The key point for me is not to simply assume that the benefits of separating and factoring everything are always obvious. Or even always valid.

For example. One part of our product has a core section, common to all customers, but each customer also has a "skin", comprising both customer-specific behaviour and look-and-feel templates. A common way to set up for a new customer is to copy the "skin" from an existing customer, then modify it as we learn and agree what the new customer needs. Experience has shown that customer "skins" are usually different enough that attempting to eliminate every duplication and share common aspects between them only ends up costing more development effort to split them apart again when they inevitably differ.

So, here's a strategy to sort this out in your case:

First, find out about the usual development tasks performed by the "copy-n-paste" people. Is their work part of a single growing "core" codebase, or is each piece a separate chunk, perhaps for a separate customer?

Then find out about the people, skills, management and hiring process. Are such developers expected to work together on a core product, or do they work alone on their own bits? Are developers moved about, hired and fired at will, and expected to pick up each small task without understanding the rest of the system? Is the system understandable and self-documenting or is it a ball of confusion?

All of these factors can influence whether refactoring to remove duplication, or duplicating to increase independent clarity is a "survival skill".

Eventually you should find yourself in a position where you can help the organisation realise that duplication suits a small range of circumstances, but refactoring to eliminate duplication (in my experience, at least) suits a much wider range. With that understanding in place, choosing whether to duplicate or refactor can begin to be done based on parts of the system, rather than individual preference.

Does that help at all?

Read about me at ~ Raspberry Alpha Omega ~ Frank's Punchbarrel Blog
I agree. Here's the link:
subject: Clean code : "human factor question"
It's not a secret anymore!