The day started like any other day working as a solutions architect for a healthcare invoice processing system. When I came into the office I didn’t anticipate that this was going to be a special day. I only realized it when a customer called in and asked for a specific invoice that should have been processed in our system. We couldn’t find it! It just wasn’t there at all. Sweat was dripping down my neck. Did we just lose an invoice — and therefore money?!
If you want to know how this story goes on, I suggest you read the full blog post originally posted on the particular blog.
In my last post we lost billions of dollars from a VIP customer. Let’s not do that again, shall we? In the meantime you should have bought a bigger wallet, I hope you did your homework as well. So the question is how can we improve the situation? Let do a quick recap what went wrong last time:
We were using async void to fire & forget the send operation inside the enlistment implementation. This allowed us to asynchronously dispatch the send operation without blocking the client code. The major drawback of this approach was that because of the nature of fire & forget we would not get any exceptions captured and “marshalled” back to the client. So in the case something goes wrong inside the send operation the whole operation would be lost without us getting notified.
We can address the same way unit testing frameworks are supporting async void methods. Continue reading
In my last post I showed you how to enable asynchronous transaction flow in .NET 4.5.1 and how you can write an enlistment which participates in the transaction scope. But something went terribly wrong. I’m sure you already spotted it. Let us have a quick look at the test execution from my previous post.
The test execution time clearly shows that the red test took less than a second to process and then failed. How can that be when our simulated send operation asynchronously delays its execution for 1000 milliseconds and we are effectively doing three of those sends? Continue reading
Urs’ comment: A short, simple book about what makes software complex, how to prevent that and therefore keep software simple. This book contains rules and facts about software regarding code simplicity. The problem of the book is that either you probably know most of its content or you think that it doesn’t work anyway (I got this impression while reading through the reviews on Amazon). Anyway, I think it is worth the time and helps to reflect on one’s own way of coding.
Urs’ comment: This book explains Dependency Inject very well: from concepts over patterns and anti-pattern to specific libraries. Read it when you use any kind of Dependency Injection in your .NET project.
The only sad thing is that Ninject is not part of the book 😉
Urs’ comment: This book claims a lot, and delivers little. There are several good tips in this book, but overall I simply don’t like it. I don’t like the “tone” it is written in.
There are only few books about Agile and Lean software architecture, therefore I cannot really give a better alternative covering the same topic.
Ultimately, that means you have to read it in case you are in any kind responsible for the architecture in an Lean/Agile set-up.
Urs’ comment: I heard and read a lot about lean during the last years. I heard about eliminating waste, Toyota, lean architecture and much more. This book helped me understand what lean actually is, and what it’s not. I like the samples and stories and the clear distinction of values, principles, methods, tools and activities.
It’s a quick and nice read, so there is no excuse to not read it – in case you want to use the term lean yourself.
For a little more than seven years bbv Software Services AG has been my first employer after my studies at the University of Applied Sciences in Horw, Lucerne. Today it’s time to say goodbye. But before I talk about my new future allow me to take a step back and reflect on my bbv Software Services experience. Continue reading