As a kid, i loved to play with Lego bricks, especially to build freaky spacecrafts.

At that time it was easy to let my phantasy go (where noone has gone before) and build completely new models simply by composing some standard bricks. Those bricks weren’t too specialized, meaning that there weren’t too many constraints on how to combine them. On the other side you always had to compose a new spacecraft from the very ground up as there weren’t some more higher organized units like engines or control cabins.

Nowadays, you’ll find such units. There are engines, control cabins or a whole commando bridge, Wings, Field Generators and so on – a whole set of higher organized units whithin a single domain. On the other side, you can’t combine every unit with an arbitrary other unit within that domain since there are some ‘constraints’  that will prohibit some unsound combinations.

Now you may ask how that cute childhood story relates to Scala?
You may have seen already some similarities to the field of software development where you also want to compose some higher organized building blocks within a certain domain, enforcing that they are only combined in a proper way. It turns out, that Scala’s concept of traits provide some mechanisms of ‘mixin’ them together while enforcing the compliance of some constraints. This may sound too abstract at that point, but hold on – we’ll build some spacecrafts in the above mentioned way and things will get clearer.

Look, it’s a spacecraft

Let’s start with a hull for our spacecraft. To keep things simple and to focus on the core idea of constrained
composition, the spacecraft’s hull will only provide one abstract method engange to start the craft:

abstract class Spacecraft{

    def engage
}

As you can see, method engage and therefore the whole class is abstract, so you can’t instantiate a pure hull
of a spacecaft. So whenever we want to build a full fledged craft, we may have to ‘add’ (or mix in) a component
that knows how to engage that craft.

Captains place

Typically, a spacecraft possess a kind of ‘control center’ which is normally well suited for initiating the
start of a craft, hence should provide an implementation for method engage. There may be different kinds of
control centers that could be used for building your own, customized spacecraft – e.g. a whole commando bridge for
those big deep space crafts or a small control cabin for those little crafts mainly maneuvering near the orbit.

 trait CommandoBridge{

def engage { for( _ <- 1 to 3 ){ speedUp } }

    def speedUp
}

Now we see what it means to engage (a Spacecraft) if composing a commando Bridge to the hull. We simply speed up that craft 3 times.
But hold on – although we know what it means to engage that craft, speeding up that craft is not in the responsibility of the commando bridge, since speedUp is left abstract (speeding down is omitted since it follows the same mechanism – you get the idea).

Re-calibrating all Dilithium crystals

So the spacecraft seems to be incomplete without a unit to speed it up – let’s call such a unit ‘engine’.  Again, there may be different kinds of engines we could select from to assemble our craft.
Let’s say there is a Pulse-Engine that directly supports the command of speeding up:

trait PulseEngine{

    val maxPulse: Int

    var currentPulse = 0;

    def speedUp { if( currentPulse < maxPulse ) currentPulse += 1  }
}

As you can see, a PulseEngine is able to speed up until a maximum pulse rate. In order to ‘produce’ different pulse engines (supporting different maximum pulse rates for different types of crafts), the field is again left abstract.
Now we could create our first spacecraft, using a commando bridge and a pulse engine (let’s say that’s all you need for building a full fledged spacecraft).

class StarCruiser extends Spacecraft with CommandoBridge with PulseEngine{

    val maxPulse = 200
}

As you can see, we’ve created a new (Sub-)Type of a spacecraft and mixed in both Traits, obtaining a commando bridge (that knows how to engage the whole craft) and an engine (that knows how to get the craft into speed when engaging the craft).
The only thing left is to define the maximum pulse rate our StarCruiser is able to achieve.

Wiring

In the above case, all units fitted together smoothly. For example, a pulse engine provided exactly the ‘interface’ (speedUp) that was needed by a commando bridge, so you could compose both without additional work. Let’s take a look at another control center, that we could apply to our craft, that may offer an incompatible ‘interface’ :

trait ControlCabin{

    def engage = increaseSpeed

    def increaseSpeed
}

This time we need to do some additional wiring, if we want to compose a new type of craft using a control cabin and a pulse engine, since both units don’t fit together directly (the dependency needed by ControlCabin (increaseSpeed) isn’t directly fulfilled by PulseEngine)

class Shuttle extends Spacecraft with ControlCabin with PulseEngine{

    val maxPulse = 10

    def increaseSpeed = speedUp
}

As you can see, we have to wire together the control cabin with the pulse engine in order to let them cooperate.
In the same way, we could think of another kind of engine which offers a completely different ‘interface’:

trait WarpEngine extends Engine{

    val maxWarp: Int

    var currentWarp = 0;

    def toWarp( x: Int ) { if( x < maxWarp ) currentWarp = x }
}

Again, we need to wire together the concrete control center with the WarpEngine, depending on their incompatible ‘interfaces’.

Let’s compose a craft, using a commando bridge and a warp engine.
Firstly, we are forced to define a maximum warp level, since it’s an abstract field of WarpEngine. Secondly we have to wire together the commando bridge with the warp engine, that is to ‘route’ the commando bridge’s method speedUp to the warp engines ‘interface’ toWarp with an appropriate implementation:

class Explorer extends Spacecraft with CommandoBridge with WarpEngine{

    val maxWarp = 10

    def speedUp = toWarp( currentWarp + 1 )
}

Alternatively, we could also use a simple control cabin for another type of spacecraft. Again we have to link the contol cabins commands (increaseSpeed) to the warp engines ‘interface’:

object Defiant extends Spacecraft with ControlCabin with WarpEngine{

    val maxWarp = 20 // claimed by WarpEngine

    def increaseSpeed = toWarp( 10 ) // claimed by ControlCabin
}

Restricted Access

Until now, we only applied a control center or engines to spacecrafts. But nothing would restrict us to use those units in other domains so far. Say we want to build a certain airplane and apply a warp engine.

class Jet extends Airplane with WarpEngine{

    val maxWarp = 5
}

It’s propably not the best idea to equip a Jet with a warp engine, since this seems to be a bit oversized for an airplane. We need a way to restrict the usage of warp engines – they should be only applied to spacecrafts. Fortunately we can express this kind of constraint, using Scala’s self type annotation. Included within a trait, it’s like saying ‘this trait is only allowed to be mixed into a type of x‘ (in our case ‘Spacecraft‘):

trait WarpEngine extends Engine{

    this: Spacecraft =>
    ...
}

As you can see, we used the WarpEngines self type to restrict its appliance only to spacecrafts. In all other cases, Scala’s compiler will complain about an unsound mixin.

What makes a spacecraft a spacecaft ?

With selftypes, we now have an instrument to restrict the usage of a trait to be mixed in only to a certain Type.
On the other side, we aren’t forced to use a control center or an engine at all if creating a new spacecraft, since we could provide an implementation of the spacecrafts abstract methods directly within a subtype. That may be fine in some cases, but what if we want to state that a spacecraft has to be composed of at least a certain type of control center and a certain type of engine? Again, we can use the service of the self type annotation, this time applied to our abstract class spacecraft, stating that a spacecraft should at least be compound of a control center and an engine:

abstract class Spacecraft{

    this: ControlCenter with Engine =>
    ...
}

The only thing left is to provide an appropriate type ControlCenter resp. Engine and the correct classification of those concrete units (e.g. ‘CommandoBridge is a ControlCenter‘)

 trait ControlCenter

 trait CommandoBridge extends ControlCenter{ ... }

 trait ControlCabin extends ControlCenter{ ... }

 trait Engine

 trait PulseEngine extends Engine{ ... }

 trait WarpEngine extends Engine{ ... }

Summary

Abstract methods and self type annotations are two powerful tools which help to guide or constrain the composition of traits.
You may use abstract methods and abstract fields to enforce a kind of ‘wiring’ between multiple units or at least to force the definition of some concrete information.
You may use a self type annotation to restrict the appliance of a trait, so that it can only be mixed in to a certain type (or subtypes). On the other side, you’re able to enforce that a certain trait (or subtype) have to be mixed in to a certain type, again by using a self type annotation.
In all cases, the ‘composer’ of those units will be guided by the compiler – you can’t forget to give a definition for an abstract method or arrange an unsound composition, since all those ‘constraints’ are based on Scala’s statically typed Type system.

You maybe have noticed some new articles and product announcements recently, that turn themself in the ‘tradition’ of Behaviour Driven Development (BDD).
Most of them mainly concentrate on the introduction of a new vocabulary in order to get rid of the test centric terminology. Some of them even suggest to stick with the well known xUnit test frameworks and mainly kind of change their test method names (if only they contain the now famous word ’should’) and think they’re done … really?

Language is not THE Key

Well, of course BDD is also about using the right Language (according to the linguistic theory of Sapir-Whorf), but this is only ‘one’ legitimate instrument leveraging BDD, not the final goal! Furthermore, you won’t do BDD only by changing your vocabulary and continue to test the correctness of your traditional units (like classes or methods), only using another weapon.

So even you’ll use no test centric terms any longer, as long as you still use any kind of Language in order to verify that your code works appropriate (in the sense of ‘i got some piece of code here and now have to find out if it works properly‘), we do not talk about BDD!

Documentation is not THE Goal

Yes, BDD emphasizes the value of comprehensible documentation. And yes, having an appropriate Language that makes it easy to produce readable ‘verifications’ is of great value (at least if you want to learn something about the code that get’s verified or in case a verification fails and you have to identify the cause respectively the intended behaviour of the code)!

But that’s only a side effect, since it can also be achived with ‘ordinary’ unit tests that act as so called documentation tests!So under the view of achieving communicating verifications, BDD doesn’t really differ from the usual way of TDD. It’s considered important for supporting the main Goal, but it isn’t THE Goal of BDD.

Still testing units ?

Most of those new tools still stick to the idea to center their ‘verifications’ around the traditional units, like classes or methods. That said, the structure of your verification code mostly reflects the technical structure of your production code (this will often result in very brittle tests, where your verification implementation is tightly coupled to the implementation of the code being verified. This fact will increasingly set a constraint on refactoring code rather than enabling it, because it requires altering the tightly coupled verification logic as well and so becomes both time-consuming and error-prone).

In effect, instead of looking at a piece of behaviour under a certain context (no matter if this is achieved by a single class or a group of collaborators) you still look at a certain method and verify that it behaves correctly under a range of conditions. So the focus is still mainly on methods on single classes instead of pieces of behaviour.

Still testing state ?

If you are looking at a single unit (e.g. looking at a single class) you are really tempted to mainly make assertions about the state of that unit (for example before and after a method was called), mainly that’s because it’s more or less the only area you can make assertions about when looking at a single class. While a class may be a valid building block for some behaviour you’re interested in, it might prevents you from looking at behaviour that’s only achieved by a set of collaborators.

In addition to that, since you’re mainly focussed to some state of a single unit, you won’t be looking about the collaboration between multiple ‘units’. So the behaviour, that manifests in the interaction between those units is mostly disregarded.

No emphasis on Interactions

As said, some tools don’t regard most of the behaviour by not looking at interactions. In BDD, Mock objects are considered as an appropriate way to look at interactions, so a tool in the sense of BDD should offer a smooth inegration of a mocking framework or at least provide some mechanics to express expected behaviour in form of interactions. Having the focus on interactions i could really start looking at behaviour in the sense of what a building block does instead of how it does some functionality (like with state based testing).

It’s NOT about verification

Granted, using a test centric Language might head to some misconceptions and mistakes because we might think it’s about testing. Admitted, the current TDD vocabulary shapes a mindset that might takes us in a (wrong) direction, but as mentioned above, Language alone is not the Key to BDD, as long as you still think about verifying the state of single units at the core in a comprehensible way.

Not thinking about testing is a major statement of BDD: TDD is not a verification method but a design process – and BDD tries to highlight this fact, not by introducing a completely new method but by readjusting the focus – away from making assertions (proofing the correctnes of our code) towards expressing expectations about the behaviour of our code!

It’s about Specification

So if you write down expectations of what your code will have to do, your mindset will (hopefully) change slightly: You no longer write (unit) tests, but specifications of expected behaviour.
So what’s the difference you may ask. Verification (aka testing) is all about making sure (i.e. proofing)
that your code functions correctly while a specification is all about defining what it means for your code to function correctly’ (Uncle Bob)!

So what we need is in fact a specification framework (instead of a test framework) that may provide a specification oriented language. But that’s not enough. As long as we stick to some ideas (like units or looking at state instead of interactions aka behaviour) that easily lead to proofing code instead of looking at expected behaviour, we won’t do TDD in the sense of BDD.

Far more important than any framework is the change of your mindset! It’s about a design process centered around readable (and as a side effect executable) specifications that will drive the design of your system. And any Article or tool that will guide you in this direction is of great help and truely in the tradition of BDD.

So think about Specification, not Verification – that’s what it’s all about.

There were surely a couple of books along your way as a software developer that influenced your mindset the most. That may be those books, that you’ve read quite some times ago but you still refer to those books in one or the other way (discussions, documentation, presentations, …) or at least still have effect on how you see the world of software development and act within it, influencing a good part of your decisions and overall thinking in your every day job – those books that may be at the top of your shelf, because it’s always a good feeling to grab some of them every now and then again and re-read …

The following section presents some books that influenced the shaping of my mindset very strongly (and therefore is surely not representative for others or THE ONLY List of books for effectively shaping your way of thinking, nor is it complete in respect to any kind of criteria), along with a short reasoning about it’s impacts on me (means, it may not have the same impacts on you).

Please note, that the books are presented in no specific order – they were all important for me, getting new insights, each emphasizing quite different aspects. While those books provide a far wider range of knwowledge and insights than mentioned below, i’m only focussing on those main aspects that formed my overall understanding in the general field of software development.

The Pragmatic Programmer

Regrettably, i read this book very late in my present career. It was recommended by a good friend of mine (THANK YOU SO MUCH Bastiaan !!!) and it hit me like a bomb when i first read it. This book was and still is one of the biggest sources of motivation for me, encouraging to invest in yourself, invest in your knowledge and staying curious, all written in a way that’s very fun to read (i had to think back to some of my previous projects with a big smile on my face more than once).
If you would ask me about one single, recapitulatory advice, that stick the most to my mind, than it should be: don’t turn of your brain !!!
At least, it’s the overall philosophy (a kind of zen) of that book that had and still have a great impact on me – and the title couldn’t be selected better. It’s truely a guide for becoming a pragmatic programmer.

An Introduction to General Systems Thinking

Once a prof at my university said, that every student should have deep knowledge in systems theory. I didn’t understand the importance of his words until i read this book! It showed me in a very funny way the obstacles of human thinking, especially related to complex systems. It’s a guide to ‘organize’ your own thinking when it comes to problem analysis and problem solving (not only related to the field of software development).
For me it opened my mind to a more sensible view of how we think and how we make decisions. It sharpened my cognition to a more holistic approach for looking at systems of any kind.
This classic is truely one of the books that can make you see the world with different eyes after reading it.

Domain Driven Design

I stumbled upon this book by chance, but it affects the way how i think about designing enterprise systems up to this day.
I think the mentioned ideas and concepts from within this book are one of the most i refer to in discussions or design sessions. If you think that the underlying technology isn’t the problem (or at least shouldn’t be the main problem, oftentimes responsible for bringing complexity into a system) and that’s the business that matters, even to the bones of your software, than this is the book for you!
Beside that, it’s an easy agreeable advocator for bringing back the emphasis to the good old school of pure object oriented design.

J2EE Design and Development

I remember that i read this book while being on a project that heavily relied on the usage of EJB – Session AND Entity Beans (i think it was in the beginning of 2.0). I thought to get some more tips on how to apply the J2EE stack to my project the right way (yes, we had some ‘issues’, especially with Entity beans …).
Instead, this book teached me not too much about a specific technology but rather about alternative forms of building enterprise systems. In a way, it opened my eyes for not to be too focussed on a certain stack of hyped technologies and dogmas but instead to stay curious and not to blindly belief any marketing statements.
Don’t read this book if you search for excuses not to build your own opinion and looking behind the surface.

Agile Software Development, Principles, Patterns, and Practices

Well, i simply like the way ‘Uncle Bob’ demonstrates the cornerstones and obstacles of designing and structuring a software system in an object oriented way.
The ‘Agility’ he refers to is mainly related to a more ‘technical’ view (not commiting to a certain agile process model) in order to end up with a system that quickly responds to a set of specific needs (depending on the given environment). Along the way, you learn a lot about the core principles of Object Orientation (like Dependency Inversion Principle, Open Closed Priciple, …) – a sound foundation for building systems in an OO style. If you deeply wan’t to learn about the what i would call ‘common sense of OO’ and the reasons that directly leads to the background of many well known Design Patterns, then this book might be for you.

My Job Went to India

This book teached me in a very amusing way, that technical knowledge isn’t everything you need in your career.
More than that, this book teached me humility – after reading, you know that you aren’t the best (not even one of the best in my case), but that there are many chances to improve every day, not only in the technical area of your profession to stay up to date.
For example, even if you gained some experiance and knowledge, nobody will take notice, until you market yourself – this demands for a completely different set of skills and an appropriate volition.
It’s a big motivation to look beyond one’s own nose (going beyond the skills of core software development).

Peopleware

I think this is one of the classics. If you haven’t participated in some bigger projects so far, you start to become a clue of how difficult it might be to collaborate within a software development project by reading this book. It’s still the people that participate to the success of a project and it’s essential to understand their motivations and interactions (who said ‘it’s the people, stupid’ again?).
This book highly emphasises the value of every single person in a project and of course the value of real teams (along with all its difficulties) – it deeply teached me respect and the right sensibility for collaboration and open mindedness, when trying to become a better team player.
If you want to know more about the background of the agile principle ‘Individuals and interactions over processes and tools’, than you may find many of the pioneering groundwork in this book.

Programming Ruby (the ‘Pickaxe’)

This book acts as a kind of representative (i also could have mentioned ‘Groovy in Action’ or some other books). For this was one of the first language books i bought within a very long period not being related to my ‘home language’, i chose this one. For me, reading this book made up my mind, showing you that there’s not only one language in the world. By learning another language you may get inspired by concepts and new solutions to some old problems. You may get a completely new viewpoint to a certain problem space and might carry new ideas over to your every day work.
Beside the main fact that it widens your mind for new ideas and maybe other useful paradigms, it’s a good motivation or starting point for engaging in functional programming, dynamic languages, metaprogramming, …

I’ve surely forgotten some of the books that influenced me on my way. And of course we all know, that reading books alone isn’t enough. It won’t replace the experiance you’ll gain from ‘practicing software development’ on an every day basis. At the end, i think it’s a good mix of both – you only have to find the right balance …

And you? What’s on top of your book shelf?

in this post i’ll try to answer a legitimate question, relating to a comment due to my last statement that interfaces are poor contracts: why do we need contracts (in the sense of invariants, pre- and postconditions) when we’ve got unit tests right at hand, that could also test the stated conditions?

in fact, it’s very tempting to see unit tests as an all-embracing instrument to check and show that a class will behave correctly, making contracts kind of unnecessary.
i’ll try to show you that unit tests (as an instrument for test driven development) and contracts (as an instrument for Design By Contract) indeed share the same goals but aren’t competing techniques, rather than methods that could complement each other.

it’s not about verification – it’s about specification

first of all, we have to clarify a potential misconception: unit tests as an instrument in the sense of Test Driven Development (TDD) aren’t that much about verification of a correct implementation rather than about a specification of how a unit should behave. in fact, it’s the specification (not the verification), that will drive development. you can see the comeback of this core idea in the rise of Behaviour Driven Development (BDD) that mainly tries to find an adequate vocabulary to write down specifications (that of course can be verified automatically) in an easy natural way, refocussing on how a component should behave under certain conditions.

on the other side, Design by Contract is also about specifying the design, in terms of the behaviour of your components. a contract asserts truths about the design of your code in the form of runtime tests placed within the contracted units itself. these assertions will be checked as the thread of execution passes through the parts of those components, and will fire if they don’t hold.

that said, both methods share the same main incitement – the specification of a system that will drive its design.

don’t bear away

as said, the goal of bdd is to reconcentrate on the specification of a component. the other way around, it means that it might be easy to loose direction within tdd, risking to set focus on testing and verification. i have to admit, that i walked into this trap more than one time in the past. of course the whole vocabulary (test, testcase, testsuite, …) makes you believe that it’s about testing. it’s easy to become addicted to this idea, so even writing tests after implementation seems pretty ok in this sense. that’s no longer possible if you see tests as specification: you firstly have to have a specification on what a component is intented to do – you can’t start with an implemenation until that specification exist.
is the same true for Design by Contract? is the contract metaphor misleading? of course you could also define your contract afterwards, so again development of a component isn’t driven by it’s specification. but the contract metaphor uses a more appropriate vocabulary. with invariants, pre- and postconditions it’s clearly about the specification of the intended behaviour – the risk of seeing a contract as tool for verification might be much lesser.

collaboration includes clients and supplier

there’s a special area, where contracts are able to provide real benefits in regard to unit tests: oftentimes unit tests specify only the behaviour of a component as a supplier, that means the test asserts mostly the stated effects (the postconditions of a method). that’s perfectly legal: most of the prospective clients may be unknown to the designer of the component or doesn’t exist yet. since the client is responsible for the adherence of preconditions it even should not be the in the job of the supplier.
a contract on the other side also specifies the constraints under which it’s legal to call a method (the precoditions). since contracts act on runtime, those preconditions will also be regarded when it comes to collaboration between an arbitrary client and the supplier component. the following points show some aspects of this holistic view:

reliance on a proper context

most developers (including me) tend to insert guard clauses in their code despite having unit tests. they don’t seem to trust about the context in which the method get’s called (that’s of course a good idea if the context can’t be foreseen). but you’ll even find this fact in environments, where the whole context is controlled by the same team. that may be also because of the before mentioned lack of knowledge about all clients that may call your component, especially in teams with limited communication. another one might be the local (specification / test in a different file than the component) and the temporal (tests at design time – collaboration at runtime) ‘distance’ between the code and the test.
having contracts aside the code (as part of the public interface of a component) you can rely on at runtime, seems to increase trustability in the running context. This may be because of …

support of defensive programming

with Design by Contract, contrats automatically protect methods from inproper usage, like illegal arguments (in the simplest case) in the real hard world, checking potentially a wider range of collaborations than a test ever can do (tests cannot show the absence of defects, it can only show that defects are present). like Bertrand Meyer said: a test checks one (or a limited set of) cases. a contract describes the abstract specification for all cases.
that said, preconditions that will work at runtime, making guard clauses in a way redundant, because the method can rely that it’s called in a proper way. that’s a runtime feature you can’t achive with unit tests. they could only check or specify how a component should behave if it’s called in an inproper way (for example by expecting to throw an exception, which becomes a postcondition). but this one wouldn’t free you to write additional guard clauses.

clear reliable documentation

while tests can be seen as an additional artifact that specifies the expected behaviour of a component, contracts form part of the public (client-) view of a class – they are part of the public interface. personally, i’m lazy – i want to recognize the core behaviour of a building block by looking at its interface / signature, not studying an amount of code be it the building block itself or a test – but of course there are also other preferences that prefer a split between specification and implementation.
of course those contracts are more than documentation, since assertions are checked at runtime, thereby testing that the stated contracts are consistent with what the routines actually do.

integration ‘tests’ for free

this one follows directly from the initial point, when regarding collaboration between clients and suppliers: having contracts that can be turned on and off makes it very easy to test and retest parts of a program. it allows you for instance to continue to test class A while you are working on class B, in case there are any interactions you did not foresee. of course, this is kind of integration ‘testing’ – it’s not about the specification of the behaviour of a single component but more about collaboration between a set of components and most of time not in the scope of unit tests.

clear Design

a contracts condition is an equivalent description of the algorithm used in a function, but written in an orthogonal manner, so thinking about such matters as pre-, postconditions and invariants help to make the concept of a class more explicit. it might encourage you to think about the conceptional model of a building block. that might lead to a clear design: obligations and benefits are shared between client and supplier and are clearly stated.
the limitations on the use of a method are clearly expressed and the consequences of calling it illegally are clear, so programmers are encouraged not to build routines that are too general, but to design classes with small single-purpose routines. while TDD guides you more towards loosely coupled building blocks (because it hurts when trying to test a tightly coupled component in isolation), DBC guides you more towards smaller building blocks with a clear resoponsibility (because it hurts to write invariants of classes with more than one responsibility or write pre- and postconditions for methods with more than one task).

‘debugging’

contracts can take part in ‘real life’, that means under real runtime conditions, maybe during development and user acceptance test – they take effect under real circumstances while ‘real’ clients (no mocks) and real collaborators (maybe also contracted) interoperate with each other. so contracts also guarding the collaboration of muliple building blocks forcing to fulfill a collective adduced goal due to a specification. having clear sound messages that state the cause of a contract violation, helps locating where the fault lies semantically: it’s very easy to find the reason of a misbehaviour within a specific interaction, pointing directly to it’s origin (if a precondition is violated, than it’s the fault of the client, if an invariant or a postcondition is violated, than it’s the fault of the supplier)

reuse

for library users (where tests may not be accessible), contracts clearly explain what library classes do and what constraints there are on using them. they provide feedback to someone learning to use other peoples classes: sometimes you only know the interface to operate with – the implementing class is unknown. having contracts on that interface gives you a clear, sound concept of the limitations and relevant effects in programming against that interface in a proper way.

open close principle compliance

while tests usually test a single unit, DBC handles inheritance in a broader way, supporting also inheritance of contracts to subclasses and therefore forcing to adhere to the claimed behaviour, stated in contracts of a superclass or interface. this goes hand in hand with the Liskov Substitution Principle.

conclusion

as you might have seen – Design by Contract is contributing some mind alluring features and ‘drivers’ when it comes to the specification of the intented behaviour of a component or even a whole system of interacting objects. as seen, contracts also regard the proper collaboration between clients and suppliers – a feature that’s mostly not in the scope of unit tests.
those new drivers fit very nicely with the strengths of unit tests (not all mentioned here), making them a perfect team for a ’specification driven development’.

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)