round.about.dev

I've read some articles in the past that discuss the importance and hence difference between some titles or roles which are involved in software development. Whether it's the discussion of 'Programmer vs. Developer', 'Developer vs. Designer' or 'Designer vs. Architect' - all those essays contain not more than hollow words to me, since they first of all argue about nifty titles.

In fact, when it comes down to the core of software development - it's the value we create for our customers that counts, no matter if we're called an architect or designer. questions like 'are you a programmer or developer' are completely irrelevant, as it doesn't matter if we don't take responsibility for what we're 'producing'.

given a sound technological background - compare an 'architect' who doesn't take care about the projects progress (i've seen some of them which seem to be interested in the more funny things - building a technical prototype and leaving the project prematurely without taking care about the shortcomings of their consigned 'architecture') and a 'developer' who's all in all interested in the quality of her results. which of those will give more value to the overall goals of a project?

do we really add value in respect to our customers needs at everyday work? do we take responsibility in your professional environment?
independent of a particular functioning within a project, the following attitudes are considered essential when we want to take care about the long term value of our work.

passion

passion drives us to the limit. we don't settle for a half baked solution.
for example, we don't want a solution (even in the small) not only to work as required, but also in conjunction with the projects goals, that may be code that's easy to refactor or readable and easy to maintain (as Martin Fowler said: 'any fool can write code that works ...').
accepting the surrounding forces, we want to get the job done in the best way that is satisfactory for all participants.

empathy

we not only produce artifacts. we also produce means that will help others to get their job done, too (be it the end user or our very next team mate, who's efforts are based on our products).
for example, we not only want to write code that is somehow well structured, but code that is comprehensable to other developers, giving them orientation, i.e. helping to maintain or evolve the code.
we not only think about getting a job done, but getting it done in a way that will provide meaning or at least support for others, helping the project to progress.

curiosity

we not only work with our brain turned of, but strive for knowledge that will help to produce solutions that are in conjunction with the needs of our clients.
for example we not only implement relayed requirements blindly, but want to give productive feedback when recognizing contradictions, inconsistencies or incomplete specifications.
we not only will produce only as much as mandated to accomplish a single task but also use our head and/or question until we understand in order to produce solutions that are truely essential to our customers.

communicative

we share our insights, giving others the chance to evolve or at least avoiding to make mistakes (may the ones that we've encountered the hard way).
for example, we not only want to give documentation but to ensure that others understand our results in the right way.
we not want to fight a one-man-show for others, but know that the whole team is essential to progress and hence help among each other by passing relevant knowledge.

courage

we adress problems, even if they are uncomfortable for us or the team in the short term, but to avoid greater damage in the long run when concealing it.
for example, if we encounter a design flaw that we can bypass in order to get our current task done, we even adress the problem officially, giving the chance for a decision towards a more expensive solution.
we aren't keeping quiet about problems, giving the customer the chance to react, even if such problems are unpleasant for all participants.

pride

we are proud about the products we create. those pride is expressed in the achievable quality of our products under the given circumstances.
for example we we're willingly 'sign' a class or component with our name, giving others the chance for feedback or questions. We stand to the code that we've produced.
we're not proud of the title we've received within a project. we're rather proud of what we're contributed to the overall goals of the project!

what's real important

so what's the bottom line?

the importance of our role in a software development project doesn't come with an official title. It's more about how much we'll take care about the projects goals, feeling responsible about what we are contributing to the project in the long term!

it's time to get 'titled' by the real value you'll produce for the project and your customer in the end, than by some official role names.

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)