Quotes of the Week: Writing Software

We value code that is easy to maintain over code that is easy to write.

- Growing Object
Oriented Software

 

There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.

- Tony Hoare

Git Quick Tip: Bash completion

Git comes with a script that provides tab-completion for the bash shell.

The script is called git-completion.bash and should be in your git installation directory under contrib/completion/.

On my OS X/MacPort installation of Git it is here: /opt/local/share/doc/git-core/contrib/completion/git-completion.bash

Just include this script in your bash environment with the following line added to your ~/.profile:

source /opt/local/share/doc/git-core/contrib/completion/git-completion.bash

Have fun with Git!

Things that can't be solved by any programming methodology

Below is a great quote from the thread What can't be solved by TDD? on StackOverflow. It is true to any programming methodology, technique or tool.

In my opinion this perfectly highlights what the real problems are in most software projects today (at least in my 10 years experience as a developer/contractor). But usually those are not the problems teams are trying to solve.

 

There are a number of things it can't solve:

1. Can't address poor or incomplete requirements.
2. Can't work as a silver bullet for unrealistic project deadlines.
3. Can't fix poor architecture choices.
4. Can't guarantee a robust development environment, it's only a technique.
5. Won't solve writers/coders block. You'll get stuck on what test to write next.
6. Doesn't fix a poor understanding of the problem domain. It will, however, show that the person doesn't know what to test to someone who is knowledgeable.
7. Won't show you the answer to what algorithm is the "best" to use.
8. Isn't a guarantee that you can push to production from development. It has to go to test unless you're willing to accept the possibility of bugs.

That's all I can think of. About the only way around the things that TDD doesn't address is to have a competent, team-oriented group who want to make good software rather than clocking in/out from 9 to 5.

follow me on twitter, I need some friends :-)

Acceptance- vs. Integration-Tests

One of the funny things as a consultant in the IT industry is, that you see that everybody is fighting with the same questions and problems.
One of those discussions I encounter everywhere is: How many representations of an entity are needed to get data from the DB to the client (sending domain objects to the client? using DTOs? Are mapped classes the domain model? ...)

Another famous discussion is the classifications of automated tests: What are unit-tests, what are integration-tests, what is the difference to end-to-end tests? What are acceptance-tests? What do we need? What is the responsibility of the developers, where do the testers come in? What kind of tests do we write first?

A recent instance of this discussion has popped up on Ted Neward's Blog: Integration testing and unit testing.
Based on the Agile Testing Quadrants I drew a diagram, that explains my understanding of the classification of unit-, integration-, end-to-end tests and acceptance tests:


Unit-, integration- and end-to-end are a classification concerning the scope/granularity of the test. It described how "large" the unit under test is.

Acceptance is a classification that is orthogonal to the scope/granularity of a test. It describes the fact, that the test gives relevant feedback about the specified functionality of the system.
Acceptance tests can be set on on different levels of granularity. This means an acceptance test can be a unit-, integration or end-to-end test.
For instance the implementation of a core calculation logic in an insurance application can be tested on unit level. For this core business logic this can be an acceptance test.

Acceptance tests are usually accessible for the stakeholders in some form. This can be achieved by binding a business readable specification to the test, or by printing a business readable test-trace (see BDD tools: business readable input vs. business readable output).

In real projects acceptance test usually tend to be on the end-to-end scope. In most cases it is necessary to exercises a lot of components to get a reliable impression about a certain functionality of a system.
However if possible, we should prefer smaller scopes also for acceptance tests, since smaller tests are faster, provide more specific feedback, are more stable and better understandable. If we get valuable feedback concerning acceptance from a test on unit scope, we should be happy.

As in many scenarios, trust is the key: If all your acceptance tests are green and the system does not work anyway. This is an argument to go for full end-to-end testing for acceptance tests.

follow me on twitter, I need some friends :-)

An alle Kunden von Cablecom Schweiz: Finger weg vom neuen HD Mediabox Recorder!

Usually I don't blog about non-IT related topics. But I just could not keep quiet about my disappointment with the HD mediabox recorder from Cablecom Switzerland...

Kurzfassung: Die Cablecom HD Mediabox Recorder ist ein immenser Rückschritt im Vergleich zum Vorgänger Cablecom Digital TV Recorder! Das Produkt als Upgrade zu deklarieren ist eine Frechheit. Ich rate allen Cablecom Kunden, welche noch einen "alten" Cablecom Digital TV Receiver benutzen, nicht zu wechseln und darauf zu achten, dass sie nicht ungewollt von Cablecom "upgegraded" werden.

Ich beziehe Telefon, Internet und digitales Fernsehen von Cablecom. Bis vor zwei Monaten war ich ein glücklicher Kunde. Ich war sehr zufrieden mit dem Cablecom Digital TV Recorder:

Vor zwei Monaten habe ich bei Cablecom angefragt, ob ich in das Vergünstigungsprogramm "3 für 2" wechseln kann: Die drei Produkte Fernsehen, Internet und Telefon beziehen und nur zwei bezahlen. Tönt gut. Da ich ja schon alle Produkte beziehe, sollte das ja auch kein Problem sein ... dachte ich ... leider kam es anders.

Ein paar Tage nach meiner telefonischen Anfrage bekam ich ein grosses Paket von der Cablecom. Darin befand sich ein neues Modem und ein neuer HD Mediabox Recorder:

Hmm, das hatte ich nicht bestellt... aber eigentlich egal ...

Nur leider ist der neue HD Mediabox Recorder eine völlige Katastrophe im vergleich zum alten Digital TV Recorder.
Hier die mühsamsten Nachteile im Vergleich:

• Anzeigen des TV-Guides dauert ca. 10 Sekunden, während der Zeit wird das laufende Programm nicht angezeigt, weder Ton noch Bild. Faktisch macht das den TV-Guide unbenutzbar! Beim alten Gerät wurde der TV-Guide sofort angezeigt und das laufende Programm hat nicht im geringsten gestockt.
• Es können keine eigenen Senderlisten definiert werden! Das ist besonders mühsam. Die Reiehnfolge der Kanäle kann nicht meiner Vorliebe angepasst werden. Ausserdem werden im TV-Guide immer alle Sender angezeigt inkl. Sender, welche man gar nicht anschauen kann, weil sie in einem Aufpreis-Paket sind (d.h wenn ich das Programm französischen Schweiz anschauen will, muss ich mich immer zuerst an den ganzen Porno-Kanälen vorbei-pagen :-)). Das alte Gerät erlaubte das freie Zusammenstellen und Anordnen mehrere Kanal-Listen.
• Wenn zwei Aufnahmen gleichzeitig laufen, so kann man keine bereits vorhandene Aufnahme von der Harddisk abspielen. Beim alten Gerät war das kein Problem.
• Das neue Gerät zeigt weniger EPG-Daten an: Jahr und Schauspieler werden nicht angezeigt. Das alte Gerät hat diese Daten angezeigt.
• Das neue Gerät ist lauter und wird wird heisser als das alte Gerät.
• Das neue Gerät gibt ab und zu kein Bild-Signal mehr aus. Die einzige Hilfe ist es vom Strom zu trennen und wieder anzuschliessen.

Dem gegenüber hat das neue Gerät nur einen einzigen Vorteil:

• HD Sender können empfangen werden.

Zu Beginn waren mir die immensen Nachteile der neuen Mediabox egal. Ich hatte ja noch die alte Box und benutzte weiterhin diese. Aber nach etwa einem Monat wurde jedoch die alte Box (resp. die Empfängerkarte) leider deaktiviert ...

Telefonische Anfrage bei Cablecom ergab, dass ich nicht mehr auf die alte Box zurückwechseln kann, da dieses Produkt nicht mehr angeboten werde. Ausserdem war mein Wechsel in das "3 für 2"-Angebot einem neuen Vertragsabschluss gleichzusetzten, so dass meine Kündigung erst in einem Jahr wieder möglich ist. Bei meiner telefonischen Wechsel-Anfrage wurde dies nie erwähnt, ich frage mich ob dies rechtlich haltbar ist ... allerdings ist der Wechsel auch dann sehr mühsam ...

Mein Rat an alle glücklichen Benutzer eines "alten" Cablecom Digital TV Recorder: Nicht auf die HD Mediabox upgraden! Die HD-Kanäle sind es nicht wert! Fernsehen macht einfach weniger Spass mit der neuen Box. Und gebt gut acht, dass Cabelcom euch nicht zwangs-upgraded!

Und ich bin nicht der einzige der enttäuscht ist:
http://www.digi-tv.ch/cablecom/5533-der-cisco-hd-mediabox-recorder-thread.html

http://www.hifi-forum.de/viewthread-160-2166-2.html

http://www.englishforum.ch/tv-internet-telephone/74362-cablecom-hd-mediabox-total-rubbish-3.html

Quotes of the Week: Business Assumptions

The reason why business people use the word 'risk' is because they don't want to use the word 'fear'.

- Dan North, Keynote Oredev

 

Corporate Ping-Pong [...] it is driven by the wrong believe that working in batches and specialized silos makes us more efficient. 100% workload equals to 100% productivity. This is plainly wrong.

- Ralph Jocham, Things ought to be simple

 

BDD – Catching On, Moving On?

Lately there seems to be more and more discussion about how to do effective BDD. Examples:

• Imperative vs. Declarative Scenarios (Ben Mabey)
• The Truth about BDD (Uncle Bob)
• You're Cuking It Wrong (Elabs blog)
• You’re almost cuking it… (Antony Marcano)
• Refactoring Given/When/Then (David Peterson)
• Let’s change the tune (Gojko Adzic)

This is an interesting tendency. BDD as a concept seems to become accepted, the topics are not “What is BDD?”, “Why BDD?“ or “Which Tool to use for BDD?” but “How to do BDD more effectively?”.

Does this mean BDD is catching on? … or is this just my ego-centric projection as I get deeper into the topic?

If you are interested in learning more about how to apply BDD successfully, watch out for Gojkos next book: Specification By Example.

follow me on twitter, I need some friends :-)

Presentation Patterns: MVC vs. MVP (once again)

Presentation Patterns are one of my classical examples how unsophisticated we still are in our industry. MVC, MVP, PresentationModel, M-V-VM... everybody is supposedly using them but everybody has another concept how those patterns are realized.

This is like the different revolutionary groups in Life of Brian: Judean People's Front, People's Front of Judea, Popular Front of Judea ... they all look the same, they all have the same purpose, sometimes they are even the same people ... but the difference is still more important than everything else!

I blogged about this before: The same but different and Sophisticated Vocabulary: MVC

Today in the .Net web world there is basically ASP.NET Webforms and ASP.NET MVC.

ASP.NET MVC is a clean and opinionated implementation of the MVC pattern.

ASP.NET Webforms does not really imply a presentation pattern. Some people are claiming to do MVC with it, but basically Webforms leave you unguided (if not impeded) with realizing your separation of concerns.

However there is the Web Forms MVP project that presents a Webforms based framework realizing the MVP pattern.

Now we are back to the question what is the difference between MVC and MVP?

In Hansleminutes #202 Tatham Oddie, one of the creators of Web Forms MVP gives a simple explanation for web scenarios:

In MVC the request is handled first by the controller, which then consults/delegates to the model and the view.
In TekPub's ASP.NET 4 series this is called Controller First Execution:

In MVP the request is first going through the view, which signals events/actions that are handled by the presenter. The presenter then consults/delegates to the model:

Back when I was programming Java, I had numerous disputes whether JSF is MVC or not. Now when we look at the above definition, JSF is clearly MVP.
It is often claimed that JSF is MVC, because it is based on Servlets, which were initially a technical realization of MVC (that would mean that any relevant Java based web framework would be MVC).
But in my opinion JSF is clearly not MVC, because in the JSF programming model there is no controller artifact exposed.

follow me on twitter, I need some friends :-)

Quotes of the Week: Overtime

Working weekends to save a project is like torturing people to save a country. As soon as you do it, there's so much less worth saving.

- lunivore on twitter 

Time does not magically convert to work.

- Rework

Workaholics are not heroes. They don't save the day, they just use it up.

- Rework