• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Bear Bibeault
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Junilu Lacar
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Jj Roberts
  • Tim Holloway
  • Piet Souris
  • Himai Minh
  • Carey Brown
  • salvin francis

Clean code : "human factor question"

Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?

author & internet detective
Posts: 40283
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
Posts: 6920
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
    Bookmark Topic Watch Topic
  • New Topic