Did you really get Behaviour Driven Development?

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?

Yet another Book Recommendation List – Software development

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 …

Test Driven Development and Design By Contract – friend or foe?

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.

is it about fancy titles in software development? no! it’s about your attitudes!

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’.

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.