clipboard considered harmful – a funny look at developers ‘laziness’

software developers are lazy … by nature.
well, not all of them are lazy. but most of us are tempted to avoid unnecessary efforts (this seems to be a good attitude, normally). for example, we all don’t want to write boilerplate code – just stuff, no fluff …

one of the most dangerous challenges in this regard (because of its easy adoption and therefore such attractive) is the usage of the clipboard. clipboard enables us to comply to our laziness in a ‘wrong’ way. it’s easy to duplicate code via copy n paste, to often only to alter the copied code marginally afterwarts in order to adapt it’s behaviour to the new specific area.

for what reasons?
is it because we don’t have enough confidence in the existing code so we don’t dare refactoring? don’t we have a sufficient test base so we dont dare refactoring? do we have to little knowledge about the domain in order to be able to abstract and therefore don’t dare refactoring? beside of the violation of DRY you should ask yourself if it could be because of what we may call a smell of uncertainty (that would be an issue for a post of its own).

back to the clipboard. maybe we should deactivate clipboard in our IDE generally? … don’t offer clipboard to a developer in principle, never … ever.
if we could’nt fall back to the clipboard, we would be forced to … copy the code by hand (of course we have no alternative to duplicate code, have we? time is short and who cares about DRY anyway … ;o)).
but now we are in a situation, where it will come to a natural selection:

the evil developer maybe would in fact copy the code by hand! this developer would take an unreasonable amount of time completing his task and therefore have to live with a higher risk to get the push (this very seldom occuring scenario would also be worth another post). a special kind of darwin award, developers only.

the good developer would be (hopefully) again to lazy to copy manually and maybe would start to reflect how to avoid this boring activity to type the code by hand. that is our chance to eliminate code duplication and instead searching for alternatives. maybe we could factor out the needed code and reuse it in different areas. maybe we have to abstract from one conrete context and look behind the curtains to recognize the core intention – object orientation offers some options, such as template method, strategy, polymorphism, …
perhaps we have to deal with foreign code or – even worse – with some concepts of the domain. don’t worry … this is a chance to get over the smell of uncertainty (otherwise it’s maybe someone other who smells … ;o))!

now lets get philosophical. lets ask why everyone of us has used clipboard in the past (me too, i have to admit – what’s about you?) but maybe we should better ask instead why we sometimes consciously violate DRY?

apart from the harmless cases where we slothfully use the clipboard to virtually transport data from one place to another, what’s about the real risky cases where we are temped to copy and vary methods or whole classes?
it seems that most of us are anthropological influenced. we like to keep control over situations (in the good old subject-object-relationship, we want to be the subject), more than ever when we act in an uncertainty context.

whenever we act in such an partly unfamiliar context, it seems that control slips away, because we don’t know all influencing factors (now subject – object – relationship has turned. it looks like the context is driving us and thats a situation we are a little concerned of). if we have not captured the whole situation mentally, we tend to reinvent the wheel again. starting over from scratch lets us keep control because it seems that we know how things work from ground up. building my own class bottom up reduces the risk to destroy the behaviour of these other class which seems to be pretty similar … lets simply copy most of’em and adapt to my own needs. hello broken window …

so how to escape from this state of fear?
simply dismissing clipboard is probably not the best pill in this case.
most of time the root of all evil is very clear: immoderate code complexity, as Eric Evans (domain driven design) says: ‘when complexity goes out of hand, developers can no longer understand the software well enough to change or extend it easily and safely. there comes most of the uncertainty. if you don’t understand it, you don’t want to touch it … and once again: don’t be lazy – but this time on a different level: try to understand the domain you are designing for and write expressive code that reflects the core of the business domain. if you’re in the code – you’re in the business …
key to refactoring is trusting your code. trusting your code is recognizing the functionality in your code. recognizing the right functionality is knowing the business. knowledge of the business is best expressed in code itself and tests that checks the code.

modeling the code as a rich source of business knowledge brings other advantages. because developers like best to deal with code rather than external documentation, this kind of laziness is no problem since the code documents the domain in a clear, significant way. it’s also easier to share common concepts and design decisions when the code represents this one to one. you can transfer the meaning of new code in a really plain way … but please not via clipboard ;o)


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: