Event Sourced Aggregates Part 4: Smart command handlers

In this fourth post in my series about event sourced aggregates I will continue work on the command handlers. In the 3rd post I did some cleaning up of the command handlers, cutting them down to very little code. In this post I will make the command handlers smart by moving domain logic from the aggregate to the command handlers.

Motivation

In the first and second posts of the series I outlined a typical C# implementation of event sourced aggregates and how that style of implementation leads to ever growing aggregates - every added features adds (at least) two methods to the aggregate: 

• One for the domain logic. E.g. a 'ChangeUsername' method, that has whatever business logic there is around changing the username. If and when these methods decide a change to the aggregate state is needed they emit a domain event.
• A 'When' method for any new events. The `When` methods perform all state changes on the aggregate.

The patterns I see in the implementations I come across is that there is a one-to-one correspondence between commands, command handlers and public domain logic methods on the aggregate. For example the pattern is that for a 'ChangeUsernameCommand' there is a 'ChangeUsernameCommandHandler' class and a 'ChangeUsername' method on the aggregate. I took almost all the plumbing out of the command handler in the last post and essentially left it at this:

which invokes the 'helper.Handle' method to get all the plumbing done and then calls the 'ChangeUsername' method to get the domain logic done. So in essence the command handler just delegates to the aggregate, but isn't the responsibility of the command handler to ... handle the command? I think it is. And handling the command means running the domain logic, so let's move that logic from the aggregate to the command handler.

Smart command handlers

In the second post I introduced the 'ChangeUsernameCommand` and the associated command handler and methods on the aggregate. In particular this `ChangeUsername` method on the aggregate:



which implements the domain logic for changing username. That is the logic I want to move to the command handler.
Moving the domain logic straight over the command handler, changes the `Handle` method on the command handler to this:



Now the command handler contains the logic for handling the command. Note that now the command handler also emits domain events - on line 7. This makes sense since this is still event sourced, so changes to the aggregate state are still done through events. The rest of the mechanics around events remain unchanged: The `Emit` method on the base aggregate still calls the 'When' method for the event and stores the event to the list of new events on the aggregate. Saving the aggregate still means appending the list of new events to the event store, and getting the aggregate from the 'AggregateRepository' still means reading all the aggregates events from the event store and replaying each one.

Having moved the domain logic out of the aggregate I have a slimmer aggregate, that only has the state of the aggregate and the 'When' methods. In the next two post I slim down the aggregate even further by moving the 'When' methods out.

The complete code for this post in this branch.

Event Sourced Aggregates Part 3: Clean up command handlers

This is the 3rd part of my series about event sourced aggregates. In the first post I outlined a typical implementation of event sourced aggregates, and in the second post I showed how that implementation leads to aggregates that grow bigger and bigger as features are added to the system. In this post I will clean up the command handlers from the previous post by moving some repeated code out them to a new abstraction. In the coming posts I will refactor between the command handlers, aggregates and event handlers to arrive at a design where the aggregate does not grow.

Repeated code in command handlers

In the last post we looked briefly at this implementation of a command handler:

Looking at the above the code at line 20 is - in a sense - where the ChangeUsernameCommand the is handled, because that is the only line that is about changing a username. All the other code in the command handler is about infrastructure; loading the aggregate, saving the aggregate and dispatching events. Moreover the code for loading and saving aggregates as well as the code for dispatching will be repeated in every command handler

Introducing a helper

To get past that repetitiveness and to cut back on the amount of infrastructure code in the command handler, we introduce this helper, where the loading of the aggregate, the saving of the aggregate and the dispatching of events is done:

The idea behind the CommandHandlerHelper is that the concrete command handler calls the Handle method with a handlerFunc, that does the business logic bit of the command handler. The handlerFunc is called at line 18, so the helper makes sure the infrastructure code is done in right order in relation to the business logic.

Cleaner command handlers

With the CommandHandlerHelper in place the ChangeUsernameCommand can be rewritten to use it like this:

This is a good deal simpler than the command handler code at the start of the post.

That's it for now. With this clean up in place we set for the next steps:

• Make the command handlers smarter
• Make the aggregate anemic in a naive way, leaving a stable aggregate, but introducing a new Open/Closed violation
• Make the aggregate anemic, events (a little) smart, and solve the Open/Closed violation

Event Sourced Aggregates Part 2: Where the mess starts

In the first post in this series I outlined a typical C# implmentation of  event sourced aggregates. In this post we add a second feature to the example from the first post. In doing so I wish to illustrate how that typical implmentation leads to violation of Open/Closed principle and ever growing aggregates.

The second feature

Once we have the code from the first post in place - that is: The infrastructure for sending commands to aggregates, raising events from aggregates, saving events and replaying events - and need to add a second feature, the way to do it is (to some extent) as outline in the first post: 

1. Send a new type of command
2. Implement a command handler for the new command
3. Implement a new method on the aggregate with the new domain logic
4. Emit any new events needed
5. Implement new When methods for any new event types

Let's say we want to be able change a users username.

The command and the sending of of that command looks like this:



That's pretty straight forward and not too interesting, so let's move on to the command handler:



That's also pretty straight forward, but a little more interesting: Most of the the command handler code is something that will be repeated in all commands handlers. We will deal with this in the next post, where that repetition is pulled out into a helper class.
The next step is changes to the aggregate, where this is added:



This is still pretty straight forward. In fact everything needed to add this new feature was straight forward, so that is a good thing. The problem lies in the last two methods, the ones added to the aggregate.

Problem: An Open/Closed Principle violation

The aggregate just grew. In order to support changing the username we added 2 methods to the aggregate. That violates the Open/Closed principle, which indicates that it is a potential problem. In my experience, it quickly becomes a real problem because the aggregate grows relatively quickly and eventually becomes big and complicated, just like any other class that grows monotonically.

That's it for now. The next posts will:

1. Make the command handlers smarter and clean up some repetitiveness
2. Make the aggregate anemic in a naive way, leaving a stable aggregate, but introducing a new Open/Closed violation
3. Make the aggregate anemic, events (a little) smart, and solve the Open/Closed violation

Event Sourced Aggregates Part 1: Outline of a typical implementation

This is the first post in a series of posts that takes its offset in a design problem I've encountered repeatedly with event sourced aggregates: They grow every time a feature is added. Nothing (almost) is removed from them, so over time they grow very big and gnarly. Why does this happen? Because typical implementations of event sourced aggregates violate the Open/Closed principle.
Through this series of post, I will show how event sourced aggregates violate Open/Closed and - as a consequence - tend to grow monotonically, and then show how we can address that by re-factoring away from the big aggregate towards a small and manageable one. Cliffhanger and spoiler: The aggregate will become anemic and I think that is a good thing.

The complete code from the series is on GitHub, where there is a branch with the code for the first two posts.

Event sourced aggregates

The context of what I am exploring in this series of posts is systems based on Domain Driven Design, where some or all of the aggregates are stored using event sourcing. Often these systems also use CQRS - very much inspired by Greg Youngs talks and writings.
Using event sourcing for storing the aggregates, means that the aggregate code does not change the state of the aggregate directly, instead it emits an event. The event is applied to the aggregate which is where changes to the state of the aggregate happens, but the event is also stored to a data store. Since aggregate state is only changed when an event is applied, the current aggregate state can be recreated by reading all the events for a given aggregate up form the data store and applying each one to the aggregate. The benefits of this approach are many (when applied to a suitable domain) and described elsewhere, so I wont go into them here.

A typical C# implementation

Typically implementations of all this follow a structure where requests coming in from the outside - be it though a client making a request to an HTTP endpoint, a message on a queue from some other service or something else - result in a chain that goes like this:

1. A command is sent, asking the domain to perform a certain task 
2. A command handler picks up that command, fetches the appropriate aggregate and triggers appropriate domain behavior. Fetching the aggregate involves replaying all the aggregates events (event sourcing!)
3. A method on an aggregate is called, and that is where the actual domain logic is implemented
4. Whenever the domain logic needs to change some state it emits an event (event sourcing, again) of a specific type
5. A 'when' method for the specific event type on the aggregate is called and updates the state of the aggregate
6. After the aggregate is done, all the events emitted during execution of the domain logic is dispatched to any number of event handlers that cause side effects like updating view models, or sending messages to other services.

To put this whole process into code, let's think of an example: Creating a user in some imaginary system. The first step is to send the create user command:

Next step is the event handler for the create user command. Note that in this example I use the MediatR library to connect the sending of a command to the handler for the command.

Note that most of what is going on here is the same as for other handlers for other commands: Pick the right aggregate and, after executing domain logic, save that aggregate and then dispatch whatever events were emitted.

On line 19 of the handler we call into the aggregate. The code in the aggregate looks like this:

At line 11 we call the Emit method. This is how most implementations I've seen work, and typically that Emit method is part of the Aggregate base class and looks something like this:

Notice how Emit calls Play which uses reflection to find a When method on the aggregate itself, and to call that When method. The When method is supposed to update the state of the aggregate and is also the method that gets called during event replay. More on that below. For now let's see the when method:

That's pretty much it, though there a few things I have skipped over a bit quickly: How the aggregate is fetched, how it is saved and how events are dispatched. I will not go into the event dispatching, since it is not relevant to the point I am making in this series, but the code is on Github, if you want to look. As for the other two bits - fetching and saving aggregates - lets start with how aggregates are saved:

As you can see saving the aggregate essentially means saving a list of events. The list should contain all the events that has ever been emitted by the aggregate. That is the essence of event sourcing. When it comes to fetching the aggregate, the list of events is read, and each one is replayed on a new clean aggregate object - that is the When methods for each event is called in turn. Since only the When methods update the state of the aggregate the result is an aggregate object in the right state. The Get method on the aggregate repository (which does the fetching) looks like this:

And the Replay method called in line 14 just runs through the list of events and plays each on them in turn, like this:

That pretty much outline the implementations of event sourced aggregates I seem to come across. 

That's it for now. The next posts will:

1. Add a second feature and see how the aggregate starts to violate Open/Closed principle
2. Make the command handlers smarter and clean up some repetitiveness
3. Make the aggregate anemic in a naive way, leaving a stable aggregate, but introducing a new Open/Closed violation
4. Make the aggregate anemic, events (a little) smart, and solve the Open/Closed violation

A First Look at C# 6 - Nameof operator

This is the fourth post about the C# 6 features I used when moving Nancy.Linker over to C# 6. The first part was about primary constructors. The second part was about auto properties. The third was about expression bodied members. This one in about the new nameof operator.

The nameof operator

The new nameof operator is a unary operator that takes, as its argument, a type, an identifier or a method and returns the name of the argument. That is, if you pass in the type Uri, you get back the string "System.Uri", if you pass in a variable you get back the name of the variable as a string.

In Nancy.Linker there was one opportunity for using nameof, which I coincidentally think represents a usage of nameof that will become widespread.
In one the private methods in Nancy.Linker there is a null check followed by a possible ArgumentException:


Notice how I am repeating the name of the res variable in a string in order to tell the ArgumentException which argument is in error. With the nameof operator I avoid this duplication and potential source of inconsistency as follows:


Note that in case I rename res and forget to update the usage inside nameof I get a compile error.

Do I Like This?

Yes. It lets me have fewer magic strings.

A First Look at Using C# 6 - Expression Bodied Members

This is the third post about the C# 6 features I used when moving Nancy.Linker over to C# 6. The first part was about primary constructors. The second part was about auto properties. This one is about the new expression bodied members feature.

Expression Bodied Methods

I like to break down my code down to short methods. Quite short. So I often have one-liner methods. In Nancy.Linker I had this for instance:


With C# 6 I can make this even shorter because methods that consist of just one expression, can be implemented as just that - one expression .... with a fat arrow in front of it. Like so:

Expression Bodied Properties

I didn't have an opportunity to use any expression bodies properties in Nancy.Linker, but I want to mention them anyway.

Just as single expression methods can be changed to be a fat arrow followed by the expression so can getter only properties that have just one expression in the getter. Note what I said there: Getter only properties can be expression bodied. Properties with setters cannot ... but ... think about it ... what would it mean to set a property consisting of only an expression? There is nothing there to assign to.

Seeing that expression bodied properties are getter only, it stands to reason that you don't have to state the 'get'.
As an example an expression bodied property looks like this:

Do I Like These?

Yes :-)
I like them because they cut down on boilerplate.

The 'Unit' in a Unit Test

How much should a unit test cover? What is the 'unit' which it should test? This seems to be a recurring discussion among developers. And rightly so - I am not going to claim to have the ultimate answer to those questions, but I will address one misconception that I hear repeated time and again, namely that the 'unit' of a unit test is a class in the production code. In this post I will show why this leads to bad testing practices and how thinking of the 'unit' as a unit of functionality leads to a better place.

Example

To illustrate my point I'll play around with the following Employee class from an imagined resource allocation system. The system handles work assignments and can only assign them to employees that

• do not have overlapping assignments
• have the necessary skills
• cost less per hour than the assignment pays

Instances of Employee have a number of work assignments each of which start at a certain date and likewise ends at a certain date. Employees also have a skill set and a minimum hourly cost. Employee instances use these properties to implement the business rules around work assignments, like so:


The implementation of Employee shown here is simplistic. Real business rules would no doubt be more involved. Nevertheless this class serves to illustrate the point.
If we follow the notion that the 'unit' of a unit test is a production class it is reasonable to assume that there is a test class corresponding to Employee and that it could look something like this:

Refactoring Production Code

Even though the employee class is simplistic it still has several reasons to change:

• Changes to the business rules around matching employee skill set and assignment requirements
• Changes to the business rules for employee availability, for instance introduction of part time assignments
• Changes to the business rules around employee cost ans assignment rate

In other words the Employee class violates the Single Repsonsibility Principle.
As a first refactoring lets introduce a SkillSet class capable of comparing a set of skills held by an employee and a set skill needed by a task:



which would change the Employe class to this (hint: The changes are in line 12 and 19):



At this point the existing tests need just one follow one change in its constructor:


After that the tests will pass again and - importantly - they will still cover all our code including the SkillSet class.

Refactoring the Test Code?

The Employee_should class now tests not only the Employee class but also the SkillSet class. If we assume that the 'unit' of a unit test is a production class Employee_should is no longer a unit test. Following this line of thought leads towards two changes to the test code:

• Mock out the SkillSet in the Employee_should. Typically this involves first introducing an interface on top of SkillSet and then using a mocked version of that in the Employee_should
• Create a new test class for the SkillSet - Skillset_should

I'm not going to write that code, but I'm sure you can imagine it.

Test Code Smell

If we went ahead and did the refactorings to our test code it would be becoming quite smelly:

• We would have lost all testing of the collaboration between Employee and SkillSet. This is pretty serious since that is in fact where part of the business rules are upheld. These parts of the rules would effectively become untested.
• The Employee_should test class would become more complicated by the extra setup of the mocked SkillSet - this might not seem too bad at this point, but quickly becomes unwieldy when dealing with more complicated scenarios
• The Skillset_should test would not add much - it almost just checks that the framework method IsSubsetOf works.

If we, on the other hand, follow the line of thought that the 'unit' of a unit test is a unit of behavior, we would just keep the unit tests as the are after the introduction of the SkillSet class. This is better because the tests are not hampering the freedom to refactor the production code.

Conclusion

I find it much more helpful to think about the 'unit' in unit test as a unit of behavior. Whether that unit of behavior is implemented in one or more production classes is an implementation detail of the production code.

A First Look at Using C# 6 - Auto Properties

This is the second post about the C# 6 features I used when moving Nancy.Linker over to C# 6. The first part was about primary constructors. This one in about the new auto-property features.

Auto-Property Initializers and Getter-Only Auto-Properties

Just like fields can be initialized from primary constructor arguments in C# 6 so can auto properties. In Nancy.Linker this is used in the Registration class where cuts out a good deal of ceremony.

Furthermore auto properties do not need to a setter anymore. This is very different from autoproperties with a private setter, because an auto-property without a setter is immutable, where as an auto-property with a private setter only protected against code outside of the class mutating it.

The Registration class in Nancy.Linker implements the IRegistrations interace from Nancy, which looks like this:



Notice that this is 3 getter-only properties. Until now you would have implement these either with explicit getters, or as auto-properties with setters. In C# 6 their implementation can follow the interface more closely and as an added bonus the whole class becomes immutable. The code for the Registration class becomes:



I like these 2 features because:

1. They make creating immutable types in C# a lot easier, which I think we will see a whole lot more of in C# code in the near future.
2. The cut down on the amount of ceremony needed to implement interfaces like IRegistrations

A First Look at Using C# 6 - Primary Constructors

Update 2nd October 2014: Yesterdaty primary constructors was pulled from the planned features of C# 6, rendering this post somewhat irrelevant. Sorry, but that's the kind of thing that happens in open development processes.

---

The other night I moved Nancy.Linker to C# 6 - this is the first part of a summary of what I changed along with quick introductions to the C# 6 features I used. Nancy.Linker is a small library (1 interfaces, 2 production classes, 2 test class), so not everything comes into play there - but the 3 C# 6 features I'm most eager to get, namely primary constructors, auto-property initializers and getter-only auto-properties, all did. For the full overview of C# 6 features visit the language features status page on the Roslyn codeplex site.

Before diving in I will note that this is based on code written using the 'experimental' flag for the compiler that comes with Visual Studio 14 CTP 3. Since this is a pre-release of the compiler things may change, but judging from the language features status page linked above the features described here are fairly stable.

Primary constructors

The first feature I used was primary constructors. In Nancy.Linker only 1 of the production classes and 1 of the test classes have non-default constructors, and they only have 1 constructor each. Classes with 1 explicit constructor are prime candidates for primary constructors, so i gave both a primary constructor.

Primary constructors add new C# syntax for declaring a constructor. While multiple constructors are still allowed only one of them can be the primary one. From the outside a primary constructor is no different than any other constructor; its primary-ness is only visible inside the class. The declaration of a primary constructor is part of the class declaration where an argument list is added:



which is equivalent the old ResourceLinker constructor:



Once a primary constructor is declared the variables in the argument list are available for initializing fields and properties in the class. In the ResourceLinker class the old constructor assigned the two constructor arguments directly to private fields. With primary constructor syntax this becomes:



I like this for two reasons.

1. By pulling the constructor argument list all the way up to the line declaring the class primary constructors place more emphasis on this list. I find that the constructor argument list is quite important, because it shows what is needed to create an instance of the class. Particularly so if you use DI and prefer constructor injection.
2. It saves a few lines of trivial initializtion code.

Primary Constructor Bodies

My previous experience with primary constructors is from Scala in which everything between the open curly brace at the start of the class and the closing one at the end is the body of the primary constructor. You can put arbitrary code into the class definition and it will run when instances are created. In my experience this is done fairly often in Scala code, and it is a feature I've been happy with in Scala. In C# 6 adding is a body to a primary constructor is - in my opinion - somewhat less elegant because it requires you to add a scope somewhere in the class where all the primary constructor body code is placed.

The tests for Nancy.Linker uses a small NancyModule called test module, which sets up a few routes, that the tests then use. Before that class looked like this:



Take line 8 as an example. This is not simlpy an assignment to a field or a property. Therefore it has to be part of the primary constructor body, so moving this class over to having a primary constructor means turning it into:



See that pair of curly braces around the constructor body? That is that extra scope delimiting the body of the primary constructor.

I still like the changes to this class for the same reasons as stated above, but I don't like the necessity of putting all the primary constructor body code into a scope because:

1. It is less flexible than the Scala counterpart, because all the code has to be together.
2. Aestetics: The code is at an extra level of indentation and has to be surrounded by a pair of somewhat dangling braces.

Video of My ØreDev Talk is Up

I'm still at the ØreDev 2013 conference were I did a talk called "Layers Considered Harmful" 2 days ago, and already the video is up. So without further ado; enjoy :-)

Layers Considered Harmful from Øredev Conference on Vimeo.

Why Not Use Custom Visual Studio Project Templates?

I got this question about the Nancy book the other day on twitter:

@chr_horsdal Hi Christian, in the book you don't seem to use the Nancy Visual Studio project templates (so far at least) just curious why?
— Richard Dalton (@richardadalton) October 6, 2013

The answer I gave was just a bit of hand waving in the general direction of the question:

@richardadalton in general I dont like using project templates a whole lot. I prefer using empty projects plus nuget packages.
— Christian Horsdal (@chr_horsdal) October 7, 2013

While it is true that, that is my preference, there is not much by way of explanation in that answer, so I'll try to explain a little more here.

Pre-baked project templates are there to help developers out. They are a way to get quickly up and running with a fully setup project. With some of the heftier templates everything is there from dependent assemblies, configuration files, and folder structures to skeleton code. Basically some template provide a full wlaking skeleton. Just like that. Click, click, click, and you're done.
I don't like that as a starting point for a code base. It's too much and the odds of such complete templates fitting just right to the project at hand are in my experience minuscule. So you end up changing the setup that came with the template. This is a battle I don't want to be fighting. Firstly because it will quickly off set any initial gain won by getting quickly up and running using the template, but secondly and more importantly because it is battle against accidental complexity that should never have been there in the first place. This is the wrong way around. We want to start out small and then only build up more stuff as it becomes needed. Not before, and definitely not from the get go. I saw a nice talk on the benefits of this at GOTO last week, the gist of which was how keeping it simple enabled evolving from a very simple - almost simplistic - initial system to a full blown system without loosing speed or ending up with a mess. In fact although not about agile that was the best talk on agile I've seen in a while.

How about smaller templates then? I like them a little better, but only a little. At the end of the day they suffer from the same problems.

How about really small focused templates? Those I can live with because there is so little left that there is a chance that it actually fits my situation, and if not the battle to overcome the template is small.

How do I prefer it then? In fact I'd prefer it if Visual Studio did not require project and solution files, but was able to just run off the build files I wrote - be it rake, psake, nant or even MSBuild. Since this is not the case the next best thing is starting off with an empty project template. That is the minimal amount of initial complexity. Then after that I can add the packages I need. With each of them I add some complexity too, but it is the complexity I've deemed worth while.

Of course there is a lot of gray scale here: When is a template close enough to empty? When does a NuGet package become a complete project template? These are case-by-case judgements that you will have to make for yourself.

XAML or JavaFx?

This a quick, subjective, unauthorative and very non-scientific comparison of building applications with XAML and with JavaFx. The comparison is based on my personal experience working with each. On the XAML side this means WPF and Win8 store apps. On the JavaFx side this means a Windows 7 application.

JavaFx
JavaFx is touted by Oracle (and Sun back in the day) as new and modern way to build UIs. It's focused on supporting the flexibility and graphical niceness that modern UIs demand. JavaFx can run in and out of browser, and on various OSs.

My experience with JavaFx is building a good looking and quite modern desktop application targeting only Windows 7. We opted for writting the view code in ScalaFx, a declarative JavaFx DSL in Scala. This works fine: The application looks good, performs fine, and the code base is pretty clean. But there are few things bothering me:

• The UI code is just not as declarative as I would have liked. In general we've found that the built-in controls do not suit our needs, so most of the UI is build from .pngs, that have mouse events attached to them. These events change the .pngs around for hover, clicked and so on. While this works just fine, it means that there is more logic in the views than I'd have liked.
• In part as a consequence of the above, it's hard to create something like a XAML datatemplate and then bind the data into it. Again this results in more imperative logic in the views.

The things I really like are:

• The fact that we can use Scala in the views really cuts down on the amount of noise in the view code, compared to Java counterparts, in my opinion. For instance attaching the mouse event handlers is a lot easier with a language where functions are first class citizens.
• It's fairly easy to run the view code in headless mode from tests. This enables a decent albeit slightly slow TDD workflow for the view code.

XAML

XAML is used in a range of Microsofts UI technologies including WPF and the Win8 store app (formerly Metro) and Silverlight. The XAML UI frameworks are also focused on supporting the needs of moderns UIs, and also runs both in and out of browser.

My experience with XAML is from WPF and Win8 store apps, where we've followed the MVVM approach without any particular framework, but with some homegrown conventions inspired by Caliburn.Micro to ease some of the repetition in XAML - particularly around binding.

This has also worked out well, resulting in nice applications, but again there are some things that bother me:

• First and foremost I detest writing code in XML. So I'm not a fan of the XAML language at all. You might, at this point, say that XAML is meant to be generated by tools, not written by humans. And you may be right. Nonetheless, my experience is that you do write most of your XAML by hand. I find doing that to be much quicker and more maintainable than using Blend or Visual Studio to edit XAML.
• I don't like the code behinds. We've kept them quite small in the projects I've worked on, but they are still there tempting developers at weak moments to hide untestable code.

The things I really like are:

• As with JavaFx it's fairly simple to run the views headlessly for testing. Again this enables an acceptable TDD workflow. Again albeit somewhat slow.
• Databinding works very well. Especially with some conventions in place to cut down on boilerplate code.
• Datatemplates in particular enable keeping the views declarative.

Conclusion?
Hmm, I don't think I have enough data here to conclude much. What I will conclude though is that for building Windows applications my experience is that both JavaFx and XAML will get the job done, but it's faster to work with XAML, because the databinding is easier, the datatemplates help a lot and there seems to be less hand rolling controls.
Beware though: The projects I'm comparing are not the same, so there is a certain level of comparing apples and oragnes going on. Also this very subjective. So YMMV.

Update - 2012-12-21
Based on feedback I've decided the conclusion above is too vague. To clarify: In my experience both technologies work, but XAML is faster (and thus cheaper, and faster to market) to work with.

Code and Lean

I've been toying around with an idea for a while. It's sort of half baked, but inspired by some good conversations about it at AAOSConf and GOTO I'm going to go out on a limb and sketch it out below.

Lean
Lean software development (LSD) has been around for a while. The Poppendiecks book took the teachings of Lean Manufacturing and turned them into a set of principles and tools for thought that made sense for software development processes. In contrast to most writings on software development processes the "LSD" book does not prescribe (or even describe) a particular process. Rather it describes a number of principles and a number tools, that can be used to analyse your current process in order to find out where it can be improved. LSD provides a framework for developing your own process that is efficient in your particular situation. The point is to continuously optimize the process towards faster delivery and shorter cycle times.

Software Architecture
What is a good software architecture? That's a hard question to answer. The following is an answer I've used for a few years now in connection with an architecture training course:

"A good architecture shortens the time between understanding user needs and delivering a solution. It does this by eliminating rework and by providing a de-facto standard framework based on the end user domain model." --James O. Coplien.

It's from Cope's Lean Architecture book, and it's about optimizing for cycle time and for fast delivery. But how? How does a software architecture help optimize for fast delivery? I think some of those tools for thought from LSD can help us out not only if we apply them to process, but also to the software architecture and to the code.

Value Stream Mapping in Code
First and foremost I think we can learn a lot about what makes a good software architecture by applying value stream mapping to our code bases. What I mean by this is: Map out what needs to be done in the code for a typical feature/user story/use cases - whichever is your unit of work - to be implemented. Then take a look at which steps takes about which amount of effort.
Note that when I say code here I include config-files, tests, deployment scripts, migration scripts and so on. Mapping this out gives us insights into which parts of the architecture needs to become better: Is most of the time spent dealing with a particularly hairy integration? Maybe that needs to be better isolated. Is a lot of time spent writing and rewriting data migration scripts? Maybe we aren't using the right persistence solution. Is it very time consuming to build out the GUI? Maybe that part of the code isn't testable enough. These are just made up examples. The point is that I think value stream mapping is a good tool to find those hot spots within the software architecture.

Seeing Waste
Another tool I think we can apply to the code is seeing waste: Basically this just says that we should be on the look out for anything that creates waste - in terms of effort or in terms of resources. Applying this to software architecture means asking questions like: Do we have methods or even whole classes or layers that just delegate to other parts the code without any additional logic? 'coz that's just wasteful. It takes time to write, it takes time to debug through, and it's takes (a little bit of) time to execute. All of that is waste. We then need to ask ourselves if that waste is justified by some other goal fulfilled by those delegations. If not they need to go.
Another useful question is if there are parts of the architecture that are only really warranted for a few features in the systems but impact all features. E.g. if 80% of the features in an application is basic CRUD, but we do all data access through repositories because there are 20% of cases where more than CRUD is needed. Then isn't it wasteful to funnel everything through those repositories? -Even simple code takes time to write and test. Any code that isn't clearly justified is wasteful.

Options Thinking
Options thinking - in my mind - applies pretty directly to code. Options thinking is about keeping options open while not just stalling. It's about finding ways to postpone decisions until more information is available without slowing down progress. This - in code - is done pretty directly with well designed abstractions. That's the obvious one. I also think techniques like feature toggles and a/b testing along with looking for minimal viable implementations support options thinking. These techniques can help with trying out more than one direction in parallel and getting real world feedback. If this is done quickly - e.g. by focusing on only doing minimal implementations - this allows us to postpone deciding between the different directions a little while and gather more information in mean time.

Pull Systems
Coding pull style: TDD. That's it.

Summing up these are not fully formed ideas. But now they are out there. Any feedback will be much appreciated.

Why Commit Comments Matter

Lets look at something pretty basic: Commit comments. Why are they important? -Good commit comments should summarize the context and intent of the commit. Writing good commit comments gives you a better version history and gives you better individual commits. Lets look at each of these claims in turn.

Better Version History
Good commit comments makes the version history better in a number of ways:

• Having commit comments that summarize intent turns the commit history of the previous day into a quick way for team members to check what happened in the code base yesterday - and they can readily drill down into the code diffs if they want.
• Having commit comments that summarizes the context of the commit - e.g. by including a bug report number or a user story id - is a very simple and flexible way to introduce traceability from code to requirements.  
• Having commit comments that summarize the context and the intent is an excellent tool for understanding code later on: When something seems to work, but also seems a bit odd, it is great to be able do an svn blame or git blame and get an idea of the context and intent behind that code.

Better Individual Commits
Writing good commit comments requires just a little bit more thought than writing no comment or writing a non-comment like "checking in code" or "bugfixes" or "I'm going home now". That little bit of extra thought is quite often just enough to make you realize if your commit could break that other part over there, or that you haven't run all the relevant tests, or that it just isn't one cohesive whole and should be split into two or three individual commits. That last point can also lead you to committing more often, and as a result synching and integrating with the rest of the team more often. Good cycle.

But I'm In a Hurry
Yeah, well we all are. So don't waste teammates time by breaking the build or having them read through the version history diff by diff just so you save a commit comment. Besides writing good commit comments really doesn't take long. Seriously we're talking 10 seconds. Just pick a format and stick to it. I like

<task id>: <Main intent>. <Important technicalities>

 That's quick to write, right?

Don't Stay Stuck

If you write code professionally, you will have days where you find yourself utterly stuck on a problem. In fact, some days coding feels like trying to wade through quicksand: The harder you struggle to get out the more stuck you find yourself. Getting into one of those situations where you are stuck and can't find a way out is perfectly normal. And it is perfectly acceptable for a professional programmer as well. Every programmer finds themselves in those situations from time to time. Getting stuck is a natural part of creative work like programming, and as such we must simply accept that we get utterly stuck now and then. The important part is what you do about it. As with quicksand the trick is to relax a bit, sit back, and realize that you need to seek help. Not all programmers realize this, but the best ones do.

When faced with an insurmountable problem some programmers just press on and try to work through it. That usually means they start thrashing; they run around in circles without getting anywhere. While this might keep them warm, and even make them seem really busy and hard working it doesn't help the project. Some programmers sort of lose interest and start surfing the web or drinking inordinate amounts of coffee. That doesn't help the project either. To get out the situation you're stuck in, you probably need help - I know, I always do. So seek help.

Seeking help can mean a number of things depending on the problem you're facing. If the problem is on the code level try asking a teammate to come and pair with you - or if you're already pairing, ask to switch pairing partner - that extra set of eyes usually helps. If the problem is a design issue, again ask a teammate to help you out, but get up from the keyboard and go to the white board. Again the extra set of eyes - or even just the process of explaining the problem - usually helps. If the problem isn't technical but has to do with say access to the right tools, the right level of support from third parties, or unrealistic deadlines, ask your project manager for help. And if he or she is not able or willing to help, don't be afraid to escalate the problem to his or her boss - it's the professional thing to do. As I said: Seeking help can mean a number of different things.

But whatever you do, don't just stay stuck. Do something about it.

Immediately Functional? -Really?

Following up on my last post I want to focus one point in the second decision diagram in that post. The diagram is a rule of thumb for deciding what you want a framework to implement for you, and it looks like this:

I want to focus on the "immediately functional" box. It says that you only want to use features in a framework that work in your context as they are. What does that mean? What if the feature needs to be configured just right to work in your context? Or needs to be extended through some extension point? Or needs to be modified slightly by cracking open the framework code? Or will work in the next release according to the frameworks roadmap? Lets look a these in turn.
Is configuration OK? Yes. Of course it is...But only to a certain point beyond which you drown, then you're usually better off building the whole feature by yourself. And keep in mind that frameworks that dont ask you to do a lot of configuration, while still implementing enough are (or course) preferable. Conventions are good at that.
Is extending through extension points OK? Yes. Of course it is. Iff its done through supported extension points. If you extend through something that isn't meant to be an extension point, you will probably have a hard time maintaining that extension, and would usually be better off building the whole feature specifically for your purpose.
Is tweaking the framework code itself OK? No, and not even if you're in a position to merge your changes back into the framework. Because even if in that case, you're now the maintainer of part of the framework, which is not what you set out to be, when you chose to use a framework. In this case you're better off building your own and maintaining that at your own pace, and according to your own needs.
Is waiting for a feature in the next release OK? It depends...as they say :-). It depends on when you absolutely need the feature, and on when you need to start developing on the feature. In other words it depends on whether you have reached the last responsible moment or not. The last responsible moment is the moment at which you have to make a decision.It not just any moment at which you can make a decision. That's likely too early. It's not simply the last minute, because at that point you dont necessarily have a choice anymore. It's the when you reach the point where you need to start developing the feature but still have time to think your choices through and make a decision. If you dont really need the feature yet, postpone to a later iteration, and decide on whether to use the framework for that feature or not, at that time. Maybe you can postpone long a enough for that new release of the framework to come out. At that point deciding whether to use the implementation in the framework or to build your own is probably easy. If you can't wait that long before starting developing the feature, you might still be able to postpone the framework vs DYI decision: Create a clear interface to what you expect the framework to implement in the next release, and then - when you have to - either use the framework to implement the interface or roll your own implementation. You might even hedge the your bets by defining the interface and simultaneously develop against the interface and rolling your own implementation of the interface. If the framework should be released with a suitable feature while your still working on your own implementation, you have the option to switch without throwing too much away, on the other hand if the framework doesn't release anything suitable you're well underway too.

It's about making the decision at right moment - which is at the last responsible moment because that is when you have the most, and best, information to base the decision on, while still maintaining the freedom to actually decide for yourself.

What Should a Framework Implement?

In my last post I wrote how you want a framework to give you a way out, when parts of the framework turns out to be too constraining. In this post I want to talk a bit about what you actually want a framework to cover in the first place. But first a little detour.

Build or Buy?
When an organisation needs a new software system, should it build the system (possibly using contractors/consultants) og buy the system (as in find a suitable COTS solution)? That's one of those questions being asked all the time, and it's one those questions that - in general - can only be answered with "it depends...". It's also a question I'm faced with from time to time in my work, and the first answer is always "it depends..".
I watched this talk by Neal Ford on emergent design recently and about 3/4 through the talk he adresses the build og buy question using this diagram:

The diagram says the new system should only be bought if it is not strategic (i.e. not part of what differentiates the organization), if there is a fully functional candidate COTS solution readily available, and that candidate is extensible (i.e. provides ways out, when the solution is too constraining). Especially the first clause I find interesting. Everything that is strategic, and thus everything that is part of what differentiates the organization should be purpose build in order get all the details exactly right, so as to support and further the differentiation.

So in a build situation, then what? Well, often one of the early things done is to choose a framework to build on.

What Should a Framework Implement?
In choosing a framework the first thing to consider IMO is what you actually want the framework to cover. If you've already decided not to buy a COTS solution, then there must be some part of the system you think should be purpose build. On the other hand you dont want to build everything from scratch (e.g. if you're building a web app for renting cars you dont want to start by building a web server). You want to concentrate your efforts on the really value adding parts of the system. Those parts are the bits that set this system aside from all others (in the car rental example that would be the parts for selecting cars, handling special offers, making reservation and so on). These are the differentiating parts. So you want a framework that implements all (or most of) the things that are not differentiating the system. But only if it is fully funcitonal and readily available, and only if it provides ways out.

So I end up with this diagram for deciding whether a given part of the system should be implmented by a framework or purpose build:

Looks familiar?

Frameworks and Way Out

Frameworks are a very big part of software today. Framworks often provide much of the architecture of a system because a framework comes with a large number of design decisions alreay made. E.g. a Grails project uses MVC and active record patterns, it runs on java infrastructure, and so on.

In this essay in design by Len Bass, three sources of initial design hypothesis for a future system are listed: Existing similar systems, frameworks, and patterns. The essay points out that existing similar systems probably provide most guidance for the new systems, frameworks a bit less guidance and patterns least guidance. This makes frameworks a more desirable source of initial design/architecture than patterns.

While I agree with this overall, I want to point out a particular caveat in this post: Frameworks should always provide a way out. E.g. a Grails project might start out being served well by active record, but at some point active record may turn out to be too constrained for a few parts of the system. It is crucial to be able to bypass the framework in those few parts while still using the framework in the rest of the system. To continue the example Grails opens the possibility to drop down to Hibernate if active record is too constrained, and Hibernate in turn opens the possibily to drop down to SQL if so needed. Not all frameworks open these ways out, which means that you have to work against and around the framework when the framework becomes too constraining. Doing so invariably results in something quite unmaintainable, because those workarounds are weird and hard to understand, and because new versions of the framework likely will invalidate the workarounds.

Lastly, in my experienc projects always run into a few of those cases where the chosen framework is too constaining. So my advice here is to remember to consider what the frameworks you conisder allows in thoses cases where you want a way out.

Why Do I Like Spec-Style Unit Tests?

As I've written about earlier I've been spending some time lately learning Scala. A side effect has been learning and using two test frameworks I haven't used before; ScalaTest and Scala Specs. Both offer what I think of as a spec style of writting tests. That is, tests along the lines of:

"A unit under test" should {
  "be tested by specs like this" in {
     // Code  for the first actual case
  }
 
  "and like this one" in {
    // Code for the second test case
  }
}

where a string is used to tell what's under test, and strings are also used to give each test case a name. In contrast "traditional" [J|N]Unit tests use method names to give each test case a name, and either don't point out the unit under test or use a class name for that.

The spec style of testing, I find, makes a test first workflow feel more natural, and makes my red/green cycles shorter, leading to more interaction between tests and code, and to better coverage. Very nice :-). I noticed this after using ScalaTest for a while, and found the same later when I started using Specs. Somehow both these frameworks gently nudge me towards a more clean TDD workflow.

I think the reason is that the unit under test is very explicitly named and that the test cases are named with strings rather than method names. Using a strings rather than method names makes me write longer names, and makes me write names that form full sentences when combined with the unit under test and the 'should' from the 'should' method. As in the example above which reads as "A unit under test should be tested by specs like this and like this one". The full sentences turn the tests into something a bit closer to specs, or rather, for me, the full sentences turn the tests into the place where I think about what exactly I want my classes to do, which makes it natural to write them first. On the other hand the natural language of full sentences makes me a little more aware of details, and therefore makes each test smaller and more focused which is what makes my red/green cycles shorter when using the spec style.

Smaller red/green cycles and a more test first approach has the usual benefits of turning the test into a design tool that leads to low coupling and high cohesion in the code under test, of creating high test coverage, and of catching coding bugs very early on.

That's why I like the spec style approach to unit testing.

Four Bits Worth of Dev Advice: Last Half a Bit

This the 5th and final post in my series about my 16 pieces of developer advice. In the previous post I listed the 16 pieces in headline form ([1]), and briefly explained the first 12 pieces ([2], [3], [4]). In this post I go through the last four pieces. Enjoy!

1100: Write change friendly code

This piece of advice is about a mind set: Keep in mind that the code your writing will most likely be changed a lot of times in the future. Therefore you need to write code that can be changed without too much pain. This mind set leads to a lot of the common coding best practices like using symbolic constant, like avoid unnecessary dependencies, like keeping functions short and the list goes on and on. These things brings readability to the code, and they enable changing the code later on. On the other hand you should (of course) avoid over-designing software, so this nugget is really mainly about the small code level things. And those small code level things make a huge difference when it comes to the modifiability of software.

1101: Dry
Don't repeat yourself. Or DRY. This piece of advice has been re-iterated so much, that I will leave at a reference for you to follow, the C2 wiki entry on DRY.

1110: Don’t stay stuck
You sometimes get stuck when coding, in fact some days coding feels like this:

Getting into situation where you are stuck and can't see what the next step is, is normal and something you need to accept as part what it's like to write code. The important part is what you do about it. Some developers start thrashing; they run around in circles without really getting anywhere. Others start surfing for cartoons (or ... well, you get the idea). That doesn't help. To get out the situation your stuck in you probably need help - I know, I usually do - so seek help. Ask a team mate to pair with you. Ask your project manager for that tool you need. Ask a senior colleague to take a look at your problem. Read up on the relevant literature. Just don't stay stuck.

1111: Be curious

The final piece of advice on the list is simply to be curious in your work. And use that curiosity to gain technical insight. For instance ask yourself how the frameworks or libraries you use are implemented. Maybe read some of the code, step through it in a debugger, or read the documentation (yes, it said read the documentation :-) ). Or take a look at the code your compile generates, be assembler, bytecode, MSIL or something else. That generated code can tell you a lot about how the platform and language you're in actually works. Just try to stay curious about how things actually works, and spend a bit of time and then satisfying that curiosity.

So that was my list of 16 pieces of developer advice. I had fun compiling the list. I started out with a much longer list, but it was fun to boil it down to 16. What do you think is missing from the list, and do you think should be taken out?