Multimate Maniac

You surely already have realized that there’s no mutual exclusiveness for progressive and excessive schools. However, in practice I often find myself in a debate between both. That’s primary reasoned in the fact that practitioners of both strategies tend to go overboard with it.

The progressive language learners mostly pick a language or two and learn them for a given timebox, most often a year or so. They try to dive into the language concepts very fasts and practice their newly gained knowledge with pet projects, such as writing blog applications or other relatively small scaled software.

The excessive language learners usually do some up-front evaluation of languages and paradigms for a certain time, ranging from a couple of weeks up to years. After having made up their mind, they explicitly choose one language and stick with that language for years. Their goal clearly is to fully utilize the language as well as the ecosystem surrounding it.

Being Progcessive

I’m personally able to relate to both approaches. Nonetheless, I feel myself more comfortable with the progressive approach. I’m a firm believer of diversity and short feedback cycles. Hence, I like to pick a language and dive into it for a while (usually a couple of months). If I’m interested and find myself learning new perspectives – or if the language enables me to raise my productivity in some cases – I usually opt to stick with that language for a year or more.

The great benefit I was experiencing in learning new languages certainly was to find new perspectives. Like different approaches to common solutions because the language supports different features. Like different program design because different idioms of modularity, objects and data structure design exist.

In past years, I delved into ActionScript, PL/SQL, JavaScript, PHP, C#, C, Perl, BASIC, Java, Processing and Ruby. This year I’ll dig into Python and F#. However, there’s only a few where I safely would categorize my knowledge as profound, namely JavaScript and C#. That’s mainly because I was very excited about both languages in the beginning and the middle of the last decade (C# ~2003, Javascript ~2006). This mixed approach might well be entitled progcessive.

(BTW: I know, I’m not good at creating new words, but I wanted to give myself a try. That’s why I’m rather a computing linguist than a natural linguist ;-)).

One Language Rules All

Apart from all those programming languages in the field and the rise of language-orientation, I finally want to make a (personal) point on being a “polyglot programmer”. I believe that it’s a good thing for both your “resident” language skills and the languages you might explore and visit to be curious. Being a polyglot programmer not only broadens your “programming speech”, but enables you to reason better about your engineering tasks.

Even for non-developers like testers, business analysts, scrum masters, product owners and managers, I strongly recommend them to learn a new programming language from time to time. Not necessarily the language they might be in contact with through development colleagues. Just the language they happen to find interesting or useful for their particular needs.

However, from the past years of professional experience I had as developer, team lead, architect, scrum master and manager, I came to the conclusion a few years ago that there’s one single language (plus dialects) every professional in modern software engineering must learn.

Yes, right. Every Pro in Software Development has to learn this essential language, which effectively is the language to rule them all: the customer language.

WYSIWYT: What You Say Is What You Think

If you want to succeed in creating software, the customer language is indispensible. This perspective has been in software development since the very first beginning. It started out with requirements encompassed with a glossary, it continued on with use cases and scenarios, up to user stories and feature fares.

Even in a very technical sense, the customer language was always in focus. It started with business routines and business modules, was superceded then with the object-oriented domain model and there even has been improved with various principles such as the ubiquituous language from DDD.

The goal of all those principles and methods is simple: understand your customer. or user. or both. (Yes, there’s a difference between customer and user, but I won’t dig into that now). The thing is: if you want to understand your customer, you need to listen to your customer. But listening ist not all. You need to comprehend what you’re listening to, you need to ask questions to what you’re listening to, you even need to refine and improve to what you’re listening to.

Language and Translation

Admittedly, it’s not easy, often impossible, to learn the complete customer language and the underlying concepts and semantics of the domain in question. However, you don’t need to be a domain expert or customer whisperer to understand your customer. The key thing here is to constantly care about the communication between you and your customer.

That being said, the’re so many techniques and methods who can help you to understand your customer and let him understand you. As a longterm XP practitioner, the customer test specifications always were in customer language stripped down to keywords and actions. This has evolved to a number of key practices to learn the language of your customer:

• Behavior-Driven-Development
• Test-Driven-Development
• Specification By Example

Honestly, learn at least one of the practices mentioned above and I guarantee you: you will understand your customer better than before. Even better, learn all of them and you will understand your customer as never ever before. Now, if there’s really only one single thing you absolutely need to know in the field, then you’d better choose learn and practice the Gherkin language.

Be a polyglot. Learn new languages, new perspectives and new paradigms. Yet, first and foremost, learn the language of your customer and be sure to regularly practice it.

Values Need Actions

First of all, the principles are very tightly bound to the manifesto itself. While the manifesto communicates agile values, the principles communicates the means of actions (practices) to embrace the values of the manifesto.

Surprisingly, most people I’ve met in my career think that the principles were some “added sugar” to the manifesto, probably even have been added at a later stage. As far as I know, this was not the case. I’ve always had the principles present with the manifesto itself. Albeit the manifesto surely is being referenced a lot more.

All batteries included

The last few days I had a couple of discussions with colleagues, friends and other “agilists” around me. The topic was about engineering (programming) niveau. More precisely, it was about the culture of caring about your work and skills.

In almost all of those conversations, I was referring to the Agile Principles, especially one particular:

Continuous attention to technical excellence and good design enhances agility.

This principle puts a clear message: Skills Matter.

Excellent!

For me this principle is a clear indication that a skilled, continuously learning and passionate working person is required to make agility a success in a project or product engineering context. It clearly alerts us to maintain and extend our very core asset of skill, which in effect is the manifestation of capability through knowledge and experience.

The great Martin Fowler wrote about this principles a decade ago in an Article on SE Magazine:

When many people look at agile development, they see reminders of the “quick and dirty” RAD (Rapid Application Development) efforts of the last decade. But, while agile development is similar to RAD in terms of speed and flexibility, there’s a big difference when it comes to technical cleanliness. Agile approaches emphasize quality of design, because design quality is essential to maintaining agility.

Obviously, quality in design is easier achieved through technical cleanliness. Technical cleanliness is easier achieved with a steady motion to improve your technical capabilities and excellence.

Is “Skilfulness” Agile?

There’s one very important question being around in agile practitioners mind for years now: Does skill relate to the Agile Manifesto? Or rephrased: Is skilfulness agile?

Even the creators of the manifesto where rethinking this aspect over and over within the last years. I remember very well the thought-provoking article on dark spots of the manifesto form the great Brian Marick. Among other values he explicitly mentioned that Skill as a Value has been left out in Agile Manifesto.

I do agree with Brian in a sense that the requirement of skilfulness is being far undervalued in the whole agile universe. I’m a firm believer in continuous learning and improvement, especially when it comes to my very own capabilities and know-how.

Craftsmen Capability Care

You may recall now that this is essentially the same song played by the wonderful Uncle Bob as well for years now. A few years ago he was that much fed up with the underestimation of engineering skills in everyday agile projects that he draw a line and crafted the Software Craftsmanship Manifesto.

It basically alerts us to take care and responsibility for what we do. It reminds us to craft software with honor and pride. It pushes us to strive for the best possible result. It just raises the bar.

That’s what I’m doing in my job and life as well. Naturally, I signed the manifesto and I’m living and promoting these values whenever I can.

Uninterested Unwilling Underachievers

Consequently, it’s obvious to me, that skill is essential in agile engineering. Agreed, it’s essential anyway, not only limited to agile software development. Yet, for agile engineering, it’s even more a crucial factor to success. Being on an agile project requires you to constantly choose the path of improvement for your own skills.

That being said, it’s literally unacceptable for me to tolerate individuals or opinions in agile projects, who are uninspired and uninterested in what they do and what the team does. In my whole professional life, I always tried to help people to get over that. However, if they’re not interested in being professional and caring like a professional and acting like a professional – then they should better get out of the way and let the professionals do their job.

Being uninterested in ones own skills, in ones own work and in ones own perspective to creation is surely a sad thing. Whenever you happen to meet such individuals, please treat them like adults and take them for serious first. Talk with them, try to help them, try to engage them.

If all that doesn’t help, there’s nothing more left than concentrating your efforts for other things or individuals and leave the underachievers behind you. This is a very important thing to help yourself in being constantly motivated for your continuous effort to improvement in a sustainable, well-balanced pace.

There’s no Pill for Skill

Finally, I want you to remind that nobody says that your job is going to be easy. Nobody says you’ll earn money by fooling around. Nobody says that you’ll spend your life in kinder garden only. Keep in mind: your value is your values.

There’s no Pill for Skill. Stand up, get up. Fight for your values, learn for your skills, accept your challenges. STFU! Get Up!

A tool is just a tool

Everybody probably knows it already, but I wanted to re-iterate that: A Tool is just a tool. Tools are very important these days for software development. Literally every developer needs his own set of tools. Plus, in professional software development, tools are an indispensable means to get things done.

As for the developer perspective, it’s the IDE, the editor, the shell, the issuetracker, the CI-engine, the VCS and many more software making up the “tool chain”. However, even hardware can be counted a tool: It seems to be a big difference these days to use a MBP, a <insert brand name here> notebook, a desktop or even an IPad as primary development system.

Give me the tool, you fool

Lately, I got the impression that tools not only are important to us, but have become more important than they actually should be. Whenever a developer sets up a new box around me, he’s asking questions like

• what editor are you using?
• what shell is coolest?
• what plugins are shiny?
• what is hip, my hipster hippies?

On one hand, I understand that it’s important to look out for improvements and make some research on it. On the other hand, I don’t get it why those questions are being asked.

Even more, I don’t get that tool X and tool Y is being used “just because it gives you good geeky karma.” What’s that for an argument? Are you serious? Are you a developer cranking out some code or just a barbie doll looking out for fashion shoes? I don’t get it.

Tools to the rescue

I think it’s a very good thing to look around what’s happening and evaluate new methods and tools. Nonetheless, I personally prefer to actually use a tool only if I obviously need a tool and then value that tool and eventually compare that tool with others in the field. For a few developers around me, I have the impression that the tool chain is just being chosen because it’s kind of hip and geeky.

Take Resharper, VS Power Tools, Zsh, VIM, ST2, MBP, WebSharper, c9.io and whatever freaky tools might exist in this universe as an example. I personally use VIM for around 2 years now. I’m not even at 10% of what is possible with VIM. And this was and is a great lesson for me. Both positive and negative.

On the other hand, I can’t (and don’t want) to miss Visual Studio and Resharper when it comes to serious .NET development. That’s cool and fine for me. I love those tools (for specific tasks). However, I wouldn’t ever touch a CSS or HTML file with VS. YMMV.

Tool me under!

I’d like to encourage developers to first use what they have and look around if existing tools can help to improve, automate or simplify the task they’re actually need to get done. Once you see that your tool-chain limits you or leads you to inefficiency, the motivation for new tool evaluation is very well satisfied, Imho.

Don’t just follow the white rabbit and cry out to be equipped like a transformer just to edit a simple README file.

Top 5 reasons to leave .NET

Here’s my top 5 reasons why I look forward to look for alternative technologies.

Criticism and Correlation

As I already mentioned before, I’m well aware that most of the above arguments are not specific to .NET itself. It’s a valid criticism of mine to argue that there’s no concrete correlation between .NET as technology and the very “non-technology-related” statements I made. I do as well recognize .NET usage in indie game studios, movie and animation agencies and whatever ‘cool’ and ‘hipster’ startups and working environments there might be.

Nonetheless, this list reflects my experiences I had so far on the majority of my .NET projects. I mostly gained the impression that the delusive culture of “professional engineering” in .NET ecospace is being aided and supported by the technology and the companies around that technology. This especially was the case where .NET and other .NET related products like TFS, various OR/M or Win/Webform-Libraries are being used to follow the “spirit of RAD”.

On the other side, I had the chance to work on PHP, C, Java and JavaScript projects as well. For the vast majority of those non-.NET projects, I had a very different experience regarding the abovementioned perspectives. Especially my Nr. 1, 2 and 3 arguments were not as apparent and present as on almost all .NET projects I had so far.

That all being said, I still have great respect for all .NET enthusiasts and community members. In fact, I even do admire a few of them for their professionalism, for their passion and for their brave and powerful way of promoting the positive things of .NET as a technology as well as of the .NET community itself.

Moreover, I not only had a “perfect” .NET Project but also had a few .NET Projects where I met very smart people, learned a lot of things and had a great time building cool products with cool .NET technologies. I enjoyed .NET development very much and keep enjoying it.

Alternatives and Advantages

I’m not sure whether any other comparably large and affecting technology would have significant advantages over .NET in the abovementioned points. Lately, I’ve been around the Java and Ruby communities and both are very different from eachother as well as different to the .NET community.

Last year I learned Ruby. Not inside out, but fairly well. It was a great experience. Both from technical as well as from personal perspective. This year, I’ll most likely dig into Python, their related technologies and their communities. I’ll learn FSharp, a .NET-related language, as well.

The message I want give to you, my dear reader, can be summarized quite easily: Take the chance and look beyond your known area. It surely will be of advantage for you. If you are a rubyist, look how the .NET way of events and UI binding works. If you are a .NET guy, look what advantages you can take away by experiencing how Rubyists deal with database migrations and testing. Either way, you can turn alternatives to advantages. And that’s what I’ll look after as well.

Turn alternatives to advantages.

Top 5 reasons to stick with .NET

Here are my top 5 reasons why using and working with .NET is fairly cool.

A typical Brownie

It’s a regular, rainy Thursday morning, five past nine. As always, you’re a little late to work. You quickly pull of your coat while switching on your monitor and logging in with your left hand. It’s not that your password isn’t complex. It is fairly complex. It’s the virtuosity of your memorized typing of course that makes it possible to login single-handed.

Once you’re seated, you see bad news in your inbox. “Bug in Chronograph!” says the title of the mail. What? The chronograph? The legacy code you just have become the official maintainer for?

Justice has left this town. That’s for sure.

Ok. Ok, ok. While you concentrate to breathe in regular intervals again, your brain starts to send plausible signals: “Get me a coffee. Then we’ll fix this bitcrap, buddy”. Aight! You put in a Nespresso “Volluto” for starters and hit the button. While the coffee machine is at your command, you open the Chronograph files. You happen to recall that it’s using TimeServer, an almighty third-party DLL. It contains classes and methods to fetch a global standard time from internet and translate it to local time.

Bing! Coffee done! “A morning with bugs and coffee. The usual suspects in my ordinary life.” is the most original thing what you are able to tweet right now about your adventure. Ok. Social shit done as well. Start working. Now.

Sources refreshed, project opened in Visual Studio, table light dimmed. You’re just rereading the code of Chronograph, which has been written in “ancient times”. Obviously without any unit tests at all:

public class Chronograph {
  private CultureInfo _culture = CultureInfo.InvariantCulture;

  public bool IsDirty { get; set; }

  public LocalTime SyncWith(TimeServer ts) {
    var localTime = new LocalTime();

    if (IsDirty) {
      TimeEntry te = ts.GetTime();
      te.Apply(_culture);
      localTime = te.ToLocalTime();
    } else {
      TimeEntry te = new TimeEntry(localTime);
      te.Apply(_culture);
      localTime = te.ToLocalTime();
    }

    return localTime;
  }
}

Hmm. This code smells to have bugs. You’re staring at it and think “Oh my. Look at the dupes. Rookies.” If you wouldn’t just slurp your coffee while browsing code, your left hand would be ready to serve a generous face-palm. Your excellent nose didn’t mislead you, as you soon realize while reading the bug report in Bugzilla:

Bug Nr      : 0815
Title       : culture is not updated when clock is in sync with server
Component   : Time Sychronizer (Chronograph)
Description : While the local time is in sync with server, the culture needs to be "updated" regularly. It happens not to be the case. The time server API has a specific function to update a time entry with culture: TimeEntry.Ensure(CultureInfo). Use this function to keep culture up to date.

Good to know that a professional like you is taking care of this nifty bug. While browsing through TimeServer API, you realize that TimeServer, TimeEntry and LocalTime classes are all sealed. Without interfaces.

Your mouse pointer moves the scrollbar slow. Very slow. You try to cheer up yourself: “An API style I’ve seen a hundred times at least. Nothing shocking so far.” You know the truth is different. You wished to stay at home today. Now you’re here. Right in front of this artfully crafted code. Not.

Riiing! 10 AM! Stand-up time! “Come on, McFly, wake up!” is the flash of thought right after the alarm window popped up on your screen. Lock the box, put off the mug, off to 3rd floor! Since your department has moved last year from 3rd to 1st floor, these dailies happen to have the notion of helping the staff to burn calories. You hurry up to entrance. “Yeah. Right.” - all elevators blocked. Stairs, as always.

TDD is En Vogue

Arrived at 3rd floor you see all devs listening to the lead developer. You don’t like him, yeah. Nonetheless, this time it’s as if an important announcement is about to happen. “Will he retire?” is all what you can imagine to be a positive thing right now. However, surprise is ahead.

From now on, the management and the entire organization will support and encourage to develop literally everything with TDD. No code will be put in production which is not TDD’d, no bug will be resolved without proper tests using test-first method. Period.

It’s Christmas and Eastern altogether. Did he really say TDD? Yes, he did! Life is a roller-coaster. After having reached the grounds this morning, you’re now back on track. Finally TDD. All those arguments you had in kitchen, all those emails you wrote to colleagues with links to Uncle Bob and Kent Beck, all those code reviews and little wars about test frameworks and CI integration have come to an end. Whoohoo!

Ok, great stuff! Finally your company is on the right path. Right after daily you hurry down to your desk again. Now let’s do some bug hunting! You start to examine the class signatures involved in that nasty bug again:

public sealed class TimeServer {
  public TimeEntry GetTime();
}

public sealed class TimeEntry {
  public TimeEntry(LocalTime lt);
  public void Apply(CultureInfo ci);
  public void Ensure(CultureInfo ci);
  public LocalTime ToLocalTime();
}

public sealed class LocalTime {
}

Wow. Sealed. The Dev who wrote this must have got a Kiss from a Rose. Looking back at the original Chronograph class, it’s crystal-clear that the else branch needs to call Ensure instead of Apply. Pretty easy. But wait! How to write a test for this tiny typo? You look back into your digital toolbox: Only NUnit and Moq available. Hmm. You stop for a minute and rephrase the question in your mind: “How to write a sensible unit test beforehand to ensure that the bug is fixed right after you have just replaced a single word?”

The Quest Of The Test

You wouldn’t be a geek if you wouldn’t consider it as a duty to find an answer to this question. With years being in this business, you very surely know: There’s coders, there’s hero coders, and - there’s you. The metaphorical ant of all coders. You’ll sit here, with your coffee mug on your left, and take the quest. Duty is calling, comrade.

First, you just do the regular easy stuff. That is, get NUnit referenced, build up a skeleton of the test class and write up your environment to be “ready to assert”. No minute later, you’re staring at this code fragment:

[TestFixture]
public class When_chrono_is_in_sync {
  [Test]
  public void Then_culture_is_ensured_with_time_entry() {
    var ensureWasCalled = false;

    var ts = new TimeServer();
    var chrono = new Chronograph();

    chrono.IsDirty = false;
    chrono.SyncWith(ts);

    Assert.IsTrue(ensureWasCalled);
  }
}

So far, so good. Now the kindergarten is over. Right now is the time to separate real men from boys. You need to find a plausible and sensible way to express the expectation, that te.Ensure() is being called instead of te.Apply().

It’s time for another coffee. Volluto doesn’t do any more. This exceptional situation cries for exceptional coffee. You put in the “Roma” tab into the machine and let the mug do its job: awesome coffee storage. No milk. No sugar. Outlook off, Browser off, Tweetdeck off. You literally feel the scientific aura now.

“Wait a minute…” you think. “… scientific? Science. Yes, science is a good catch right now. I need to express a function in order to put it under assertion.”. Express. A. Function.

Eureka!

That’s the key! You’ll go for a lambda expression. You need to define the function which actually calls the Ensure method and then assert its proper usage simply by checking whether this function has been called. That’s like implanting a lambda into the existing code. You quickly smash in some prototypical code to verify your solution path:

public static class TimeEntryImplant {
  public delegate void Ensure(CultureInfo culture);
}

That’s the delegate. Let’s weave that into Chronograph in order to be able to utilize it:

public class Chronograph {
  private CultureInfo _culture = CultureInfo.InvariantCulture;
  private TimeEntryImplant.Ensure _implant;

  internal Chronograph(TimeEntryImplant.Ensure implant) {
    _implant = implant;
  }

  // ...
}

And finally heading on to extend the test:

[TestFixture]
public class When_chrono_is_in_sync {
  [Test]
  public void Then_culture_is_ensured_with_time_entry() {
    var ensureWasCalled = false;

    TimeEntryImplant.Ensure implant =
      culture
        => ensureWasCalled = true;

    var ts = new TimeServer();
    var chrono = new Chronograph(implant);

    chrono.IsDirty = false;
    chrono.SyncWith(ts);

    Assert.IsTrue(ensureWasCalled);
  }
}

“Yeah, right.” Looks good so far. The strategy now is hacked in. You feel good, you feel confident. Nonetheless, you still feel the need to reiterate your solution path again. The pro is working here. Swiftly, almost gracefully, you stand up from your seat, followed by two elegant sidesteps towards the whiteboard. On a small space on the upper left corner you rewrite the essentials steps again:

1. Declare & define expression containing the new functionality.
2. Use the expression within assertion to get the test red.
3. Implant the expression within class under test to get the test green.

Freddy Fredpecker

“Hey, hey, heeeeeeey!” you hear a dark, arrogant and unemotional voice on your back saying with low voice. It’s Fred, your “colleague”. No. Collegue is not the right word. Fred is an arrogant Egomaniac, who coincidentally happen to work at the same company as you do. To make it even worse, Fred is the self-proclaimed “Testing Expert” in your department. He actually hasn’t heard anything about MSpec, he writes “Unit Tests” with database usage and he is very keen to rigorously punish every developer with irony and sarcasm who is not obeying the almighty AAA-rule. Testing Expert, you know.

You turn your back slowly and see him sitting on your desk. “What an ignorant, low-life piece of crap he is” you think as you see him tipping with his dirty fingers on your beloved Octocat Mug while swinging around in lay-back mode on your swivel-chair.

“You seem to have a faible for testing, aren’t you? Buddy, realize testing is not about colors or expressions. I see…” Fred continues while having a glimpse at your test code, “… you’re trying to test something with lambda. Man, I knew you’re crazy. Like ‘Adam Sandler-Crazy’. But I didn’t knew you’re dumb as well. Like ‘Jim Carrey-Dumb’, y’know?” He harshly puts your mug back on your desk while moving his butt off your chair.

“Fred,” you reply, “ehh… eh… well… em, you’re right. I’m just trying out something, y‘know? It’s wrong shit anyway, so don’t care about it. Well, y’know it’s hard for me as an ’average’ coder to get into this testing stuff. I’m experimenting a bit, that’s all.”.

You know you need to get rid of him. Now. You put that ordinary, demotivated Looser-Look on your face and stare at Fred. Deranged. - “You better get a life, kid.” mouns Fred and slowly moves out of the door. You follow him, with a little, respectful distance, grab the knob of the door and close it silently.

Two Strikes To Green

“Phew… at least I got rid of this low life looser”. You quickly move back to your desk and grab the keyboard. You’re so close to the solution, only a few keystrokes away. The test is red. You know you could go green by just invoking _ensure function you injected through Chronographs constructor.

However, that’s not the idea of this game. The Idea is to ensure that the real Ensure method of TimeEntry has been called. You lean back for a minute, then decide to slowly hack in an extension method to TimeEntryImplant:

public static class TimeEntryImplant {
  public static void EnsureImplant(this TimeEntry entry, CultureInfo culture, Ensure implant) {
    (implant ?? entry.Ensure)(culture);
  }
}

Yep. You pause. Just staring at your code. It’s these little moments, these little seconds in your poor hacker life you’re loving to have. You made it. And it looks beautiful. You just got your very first test implant.

Grande Finale

Now let’s head on to the finishing move! It somehow amazes you that you’re able to switch back into rapid fire mode so easily after being in the ‘code monkey stares at code’-position. Rolling back with yout chair to your desk, you almost spilled your coffee on your beloved keyboard. Almost.

Ok. Concentration. You already know it. Victory is only one single line away. With the heart of a winner, a generous and confident smile in your face, you open the Chronograph class and change the line you knew you needed to change from the beginning. You locate your enemy:

      te.Apply(_culture);

Squash this buggy line away and place in your implant:

      te.EnsureImplant(_culture, _implant);

Save. Run test. This is the moment. You stare with eager into test results window while your stuff compiles. You’re sweating, altough you haven’t moved your ass even an inch away from your computer.

Ok, runner starting… testing… green!

Victory!

You lean back, grab your mug, sip a little bit, switch back to code to see the beauty of the complete Chronograph class:

public class Chronograph {
  private CultureInfo _culture = CultureInfo.InvariantCulture;
  private TimeEntryImplant.Ensure _implant;

  internal Chronograph(TimeEntryImplant.Ensure implant) {
    _implant = implant;
  }

  public bool IsDirty { get; set; }

  public LocalTime SyncWith(TimeServer ts) {
    var localTime = new LocalTime();

    if (IsDirty) {
      TimeEntry te = ts.GetTime();
      te.Apply(_culture);
      localTime = te.ToLocalTime();
    } else {
      TimeEntry te = new TimeEntry(localTime);
      te.EnsureImplant(_culture, _implant);
      localTime = te.ToLocalTime();
    }

    return localTime;
  }
}

You did it. You squashed the bug. TDD. Test-First. Brownfield. What a victory.

After this tremendous win, you surely got excited enough from your test implant to tell all your mates about it. In your office, though IM, Facebook, Twitter and whatever medium you have ready. For hours and hours, you reiterate your journey.

Through all this excitement, you even get your hands on other, similar pieces of code and try using the implant technique. It’s easy, it’s expressive, it just works.

After all these exciting hours, you literally didn’t notice how fast time flew away. It’s 9 P.M and you’re still in office. “Oh shit, I’m supposed to meet with my honey at 10!”. You grab your jacket, lock your box, switch off lights and slowly move stairs down to basement. Time to leave with pride. With the ‘test implant’ feather in your cap you walk out of the office and step into the bus.

An hour later you’re finally at the bar to meet your sweetheart. She steps in, beautiful as ever, smiles and quickly skirrs into your arms. This day can’t get better. She gives you a long, affectionate kiss - willing to stop at nothing.

All of a sudden you stop the kiss, smile at her at your best and whisper: “I love you, hon…” while thinking… “OMG, I forgot to check-in!”

Global Type Alias

First off, let me define what a global alias is for me. A global type alias is best described with the current aliasing feature in C#:

using System;
using Dump = System.Diagnostics.Debug;

public class Writer {
  public Writer() {
    Dump.WriteLine("Writer!");
  }
}

The second line is a using alias. It’s quite handy to avoid name clashes in your source file. And that’s the downside (for me) as well. In C#, it’s only possible to define type aliases on source code file level. While it’s perfectly ok for resolving name clashes, it’s yet not enough for me in terms of sensible alias usage.

From my perspective, a broader - even declarable - scope of a type alias would be very helpful. As a starting point, I’ll define a “global” type alias as an alias valid on assembly level.

Global type aliasing can be very helpful. I miss it most for generic types, since they’re not only tend to be verbose but can be misleading as well. I mean, how often did you ask your inner self the famous three letters (WTF?) when seeing something like ServiceResponse<Dictionary<long, List<string>>>? Yes, sure you can alias it with using RoadServiceResponse = ServiceResponse<Dictionary<long, List<string>>>.

Now would you want to define this alias in every single file where you process this mighty response object? Surely not. Redundancy is boring. However, if you’re using C#, you just have to. A widely scoped type alias is surely possible if you were using VB.NET with its Imports feature.

Alias Open Types

Lengthy and complicated naming is one reason. A second, even more demanding reason for global type aliases are the use of generic implementations or generic interface definitions. It may sound weird in first instance, so let’s see an example here:

/* Assembly A: My 'cool' API :-) */
using System;
using System.Collections.Generic;

public interface IMetaData<T> {
  string Id { get; }
  T Data { get; }
}

public interface IRelationMap<T, TKey, TValue> 
  : IDictionary<TKey, TValue> {
  TValue GetRelated(T obj, TKey key);
  T RelateTo<T>(TKey key);
}

public interface IMetaInfo<TSource, TData> {
  IRelationMap<TSource, string, IMetaData<TData>> Properties { get; }
  TSource Object { get; }
  int ChannelId { get; }
}

A little unreadable for the generic types, but quite straight forward so far. Let’s implement IMetaInfo:

/* Assembly B: My 'cool' Service :-) */
public class TextMetaInfo<T> 
  : IMetaInfo<T, string> {
  public IRelationMap<T, string, IMetaData<string>> Properties { get; set; }
  public T Object { get; set; }
  public int ChannelId { get; set; }
}

Doesn’t this look weird? Wouldn’t this one be a little more readable:

using System;
using System.Collections.Generic;

using IMetaMap<T> = IRelationMap<T, IDictionary<string, IMetaData<string>>;

public class TextMetaInfo<T> 
  : IMetaInfo<T, string> {
  public IMetaMap<T> Properties { get; set; }
  public T Object { get; set; }
  public int ChannelId { get; set; }
}

Sad enough that above code won’t compile. C# only accepts aliases for closed types.

Yeah, you might think now that this is just nitpicking, since you surely might just derive to have naming done right:

public interface IMetaMap<T> : IRelationMap<T, IDictionary<string, IMetaData<string>> {}

Sorry to disappoint you here. “Fixing naming” by subclassing is just wrong. Despite of the bad smell you simply made it even worse since you now made it a lot harder to implement IMetaInfo<T, string>. If you were the consumer of Assembly A without any source code access, you lost anyway. If you actually have access to the sources of Assembly A, you end up in deciding whether to change the type signature of IMetaInfo<TSource, TData> just for naming. In consequence, other implementors need to change their implementations. Even callers need to recompile. For the sake of readability?

Sorry, C#. You are doing a good job being a multi-paradigm (yet OO-colored) language. However, when it comes to aliasing, you could do better.

Titel: Amigo Agilo: Alles Agil, Nichts Stabil

Beschreibung: Agil. Agil. Agil. Agil. Agil. Agil. Agil. Agil. Agil. Agil. Agil. Agil. Stabil. Agil. Agil. Agil. Agil. Agil. Agil. Agil. Agil. Agil. Stabil. Agil. Agil. Agil. Agil. Agil. Agil. Agil. Agil. Agil. Stabil. Agil. Agil. Agil. Agil. Agil. Agil. Agil. Agil. Agil. Stabil. Agil. Agil. Agil. Agil. Agil. Agil.

Interesse? Interesse!

Ich möchte hiermit jeden, der Interesse an meinem Beitrag “Amigo Agilo: Alles Agil, Nichts Stabil” hat, um einen Gefallen bitten:

Bitte schreibt mir hier einen Kommentar, twittert an @ilkerde oder @amigoagilo, schlagt meinen Vortrag auf Konferenzen, Barcamps und User-Groups im Software-Entwicklungs- und Software-Management-Umfeld vor. Ich würde mich sehr freuen, diesen Beitrag einem breiten und interessierten Publikum vorzustellen.

Jede aufrichtige und realistische Möglichkeit nehme ich dankend an. Ganz besonders würde es mich freuen, diesen Vortrag im Rahmen einer Konferenz oder eines UG-Treffens für Agile Methoden halten zu können. Das ist ja bei dem Thema ja recht naheliegend, oder?

Bevor es zu irgendwelchen Mißverständnissen oder Rückfragen kommt: Der o.g. Titel sowie die ungewöhnliche Beschreibung dazu sind alles, was ich zum Beitrag schriftlich mitgeben kann und will. Die Beschreibung trifft den Vortragsinhalt ziemlich genau, denn es geht um das Wort “Agil” und dessen Bedeutung im Software-Entwicklungs- bzw. -Management-Umfeld.

Die Dauer des Vortrages ist ca. 60 Minuten, es sind keine Voraussetzungen notwendig, außer ein gesundes Interesse zum Thema. In diesem Sinne:

Alles Agil, Nichts Stabil.

Ich freue mich auf Feedback, Meinungen und Anregungen. Danke.

Notizen eines Nerds

• UX: Progressbar vs. Waitcursor
• Code Analysis Notes
• Hardcore Software
• ALE MUC Brainstorming
• XP Secrets Notes
• TDD Talk Notes
• Die Modellverantwortung des Architekten
• Castle Of Variability & Estimation
• Branching Patterns
• Context In Model Is Evil
• Menu State Analysis
• Posh 4 Devs Notes