Category: Software Craftsmanship

  • SoCraTes 2015 - or how to be catmatic

    This year for the first time, I attended the SoCraTes (stands for Software Craftsmanship and Testing Conference) in Soltau, Germany.

    It is organized by the Softwerkskammer, the Software Craftsmanship Communities in Germany.

    I’m a member of this community since over 2 years now and heard a lot of good things about this conference. This year I finally had the time and was also lucky enough to grab a ticket (yes you have to hurry, as the number of participants is limited).

    So let me give you some impressions of this awesome event:

    TL;DR it was really (yeah REALLY) awesome

  • Temenos

    Yesterday at the last meeting of my local software craftsmanship group, Olaf Lewitz from Berlin held a short introduction to Temenos.

    This was as quite interesting experience, so here is a little braindump from me.

    Why

    In many companies a huge amount of time is wasted by fear and politics. That can range from fear about the own job, the position to things like “watermelon reporting” (all green on the outside, but don’t look inside). All this interferes an open communication.

    Effective teamwork needs trust and trust brings saftey which leads to a more open and therefore efficient communication, because if you trust each other, there is no more any need to question everything oneself or the others have to say, there is no need for politics and fear. This saves time, increases bandwith (by exchanging meaning and not just information). You also have more options in situations where you have to decide about things, because one knows about the otherwise hidden knowledge and skills of the other team members.

  • Screencast: FizzBuzz kata

    This week, at the meetup of my local software craftsmanship group, we did a mini code retreat with the FizzBuzz kata. In advance I had a discussion with Benjamin, that this Kata could be a bit to easy for a code retreat. My point was here, that IMHO is not done completely. Most people stop on a function like this:

    public string Translate(int value)
{
    var result = string.Empty;

    if (value % 3 == 0)
        result += "Fizz";

    if (value % 5 == 0)
        result += "Buzz";

    if (value % 3 != 0 && value % 5 != 0)
        result += value.ToString();

    return result;
}

    This is fine, as long you don’t want to extend the kata with different rules.

    Imagine you got up to this point and now you get a new requirement:

    Extend the Translation function so it prints

    • “Bang” for all values divisible by 7
    • “FizzBang” for values divisible by 3 and 7
    • “BuzzBang” for values divisible by 5 and 7 and
    • “FizzBuzzBang” for values divisible by 3, 5 and 7

    Surely you could just add another if statement but how ugly is that. This is the point, where the TDD-Part of the kata converts to a refactoring kata.

    Here you can see my take on this kata.

    It features a solution completely free of if statements and is quite good extendable. The resulting Translator class must never been touched anymore. All you have to do for different rules is to write a different RuleFactory. If you want to play you could even implement a RuleFactory which reads its rules from an XML file.

    The project for Xamarin Studio can be found here.

    You can get the music under http://www.jamendo.com/de/track/259936/scherzo-no.-4-in-e-major-op.-54-1843

    Have Fun

    YouTube Link for mobile viewers

  • The Monty Test - A revised Joel Test

    12 years ago, Joel Spolsky, Founder of Fog Creek Software developed the so called Joel Test.

    The purpose of these 12 questions is a test, if a company is able to create quality software. 12 years is a long time and as a Software Craftsman I dont’ agree with all of these questions anymore. So here is an updated proposal:

    1. Do you use (distributed) source control?
    2. Can you deploy your software in one step?
    3. Do you build on every commit?
    4. Do you have a bug tracker which is connected to your source control system?
    5. Do you fix bugs before writing new code?
    6. Do you have short release cycles?
    7. Do you have a runnable spec?
    8. Can your developers work easily together?
    9. Do you use the best tools money can buy?
    10. Do you have full time testers?
    11. Do new candidates write code during their interview?
    12. Do you do usability testing with end users?

  • Screencast: Video store refactoring kata

    This is the video store refactoring kata from the book “Refactoring: Improving the Design of Existing Code” by Martin Fowler, Kent Beck, John Brant and William Opdyke.

    The project file for IntelliJ IDEA resides on http://github.com/magicmonty/videostore

    You can get the music under http://www.jamendo.com/de/track/72960/w.-a.-mozart-1756-1791-sonata-in-c-major-k.-521-for-piano-four-hands

    Have Fun

    YouTube Link for mobile viewers

  • Introducing AutoTest for Delphi

    One of the main issues with doing TDD is the fact, that the cycle times between running the unit tests and the development of a feature has to be very short. In fact as short as possible.

    In other languages there are always tools like autotest for ruby or infinitest or JUnitMax for Java.

    I missed such a tool badly in Delphi, because it makes the development so much faster when the tests are running automatically in the background everytime the code has changed.

    So I created autotest4delphi. It uses Growl as notify engine and outputs all relevant command line output of the compiler / test appropriately colored to the console and it’s configured via a simple INI-file.

    The tool itself is written in Delphi 2006. I have not ported it yet to Delphi XE but this should not be a big problem.

    Feel free to fork an use it.

    Visit the archives!