Buy it - just buy it.

The best thing about Christmas is the days off from work. You get to spend a lot of time with your family and that's great. You also get to see a lot of movies in the TV - which is nice because I like to see a good movie. I don't see a lot of TV basicly because I choose otherwise - my life probably goes on even though I don't know who got voted off the island during the last episode of Survivor / American Idol / Big Brother / (insert any mediocre TV-show here)...

You also get to read a lot so I've finished the book I blogged about three days ago - Michael Feathers Working effectively with legacy code. The short story is: Buy it - I was completely sold on his final appendix where he goes through all the various ways of decoupling dependencies - each example is followed by a codeexample and each example and explanation covers about two to four pages. Extremely nice setup and well thought.

One of his examples is the "Extend and subclass" refactoring. I never thought of that one but it is so obvious and offers lots of advantages with only a few minor disadvanteges so I'll share it with you here:

...(and 15 minutes passed...)

No excuses: I have failed to come up with a decent coding example on my own - the code just turned against me once I looked at the time and found out that one of the three "Lord of the Rings" are beginning in 5 minutes... Not that I haven't seen all of them at least 3-4 times but this is Christmas and about the first vacation this year which doesn't include a lot of work on our house or trips to far-far-away family - so watching a movie I've seen before and NOT get up from the couch and get some work done is really a new sensational feeling..... I could probably learn something by doing a bit of coding on the issue I'll just find a perfectly good example written by Jimmy Bogard for you  :o)

I'm off to see some orc bashing. Happy New Year to all of you - see you in 2009  :o)

Regards K.

TDD on untested code - why does the first test take so long?

Most software developers have at some point in time been assigned a task with the following description: "We need to extend report X with a new column which sums up all the other columns in each row" - or something like that. Even if you don't know anything about the codebase tasks like this one in most cases don't cause too much trouble because you extend already something which is already working and in production. Even if you like to deliver this new functionality with shiny tests with 100% coverage of the new functionality it isn't a big deal because you don't have to touch the existing armageddon of untested code.

Worse - much worse is the task assigned to you the next day which says "Well - we have this bug in our invoicing system which causes all sales on the 1. of January to never show up in our reports. We need you to fix it". Even if you know that the invoicing system is a pretty decent working piece of software without a lot of maintenance - you also know that it has a mere code coverage of about 2%... When asked "How long will it take" what do you respond?

If you and your team are on the TDD side of things I have always been astonished how long it takes for someone to take the first step towards TDD-enabling untested software. However after having read the first 10-or-some chapters of Michael Feathers Working effectively with legacy code I am beginning to put words to my gutfeeling of "This will probably take a while..." when I see a change request to a system I know doesn't have a decent testsuite attached.

You've been assigned the task and you need to write your first test - why does it take forever to write it? Michael Feathers goes deep with numerous code examples but from a birdseye view it all sums up to the fact that before you refactor the dependencies in your untested code you can't write a suite of good unittests. Unittests must be kept as short as possible - I've heard the "No test should be longer than 15 lines of code" and it is a good best-practise to follow. Of course it doesn't always happen but if you have to write 20 lines of code to set up your test you need to look for design smells - most notably violations of the Single Responsibility Principle on the class or classes you are testing.

What I've recognized after reading these chapters are that code which have been developed without testing in mind have lots of dependencies to other classes. I've whupped up quite a few of myself - no doubt about it. When all you do is write code and never actually use your own code in a test you'll never get to see how your code "looks" from the outside. You basicly just make things work - and whoever is left to use your code after you have signed off on a task are pretty much on their own. This is how i.e constructors and methods with 10+ parameters are being born - I've seen them in my entire professional career wherever I've been - if you are "coding away" and need an extra parameter, you change the signature of your method, change the caller to use your new signature and everything is fine - from your perspective. What happens is that the more parameters you pass into a method the more state you will have to set up in your "Arrange" section of a unittest. Given that the more parameters a method or constructor takes the more state is injected your tests of that method will also be bigger in terms of lines of code - and long "arrange" sections in your tests are as much of a codesmell as any other codesmell you can think of.

The first test you write on untested code will have to take into account the time spent refactoring all the intertangled dependencies you dig up trying to get to those precious three lines of code you want to test on. It's a fact of life - get used to it. You might have to split up large classes, move object creation to constructors, extract interfaces to be able to mock dependant libraries etc. before you can actually make the single test that solves your problem turn green... The next time somebody has to write a test on your refactored code it will be easier - but the first test takes the longest - and the first test is also the one people fear the most because there is no other tests around to back you up when you begin to alter working code.

I agree with him on most of his writings - not everything though. He actually promotes writing "characterization tests" for already existing code "to be able to test for the existing behaviour". I disagree with him. The time you spend writing tests on existing code could be better used focusing on solving the problem you have before you. It's a mere waste of time in my opinion - when do you know enough and have written enough tests to conclude that the core existing behaviour is covered and documented in your tests? No sir - Keep It Simple Stupid, just get the job done. Use some of the many useful techniques he has documented but please - don't write tests for existing code. He means it well but honestly - it's just not valuable work to write code for existing functionality.

Even though I'm not finished with the book I can highly recommend it to anyone who just wants to be able to navigate through untested code without causing too big waves in the pond. It's a good book with quality stuff in it - definately one I will use to plan my attack on codebases that I've never touched before

Regards K.

Silverlight - the pros and cons

Some time ago the team I work with decided to go to a one-day Silverlight seminar at Microsoft Copenhagen. Today we went and with an openminded heart (read: I didn't know anything about Silverlight except that I know I at some point downloaded a plugin to be able to access a beta version on MSDN (I think it was...).  I admit it: All I knew about Silverlight in advance can be told as "It must be some sort of Flash something-something from Microsoft".

So I went - and here's the sum of my notes and the people I talked to during lunch etc. Let's start with the "What": 

Silverlight is a cross-browser plugin which enables you to write light-weight Windows Presentation Foundation (WPF) applications and embed them into a website. It doesn't require the full .NET framework  on your machine but instead the plugin you download contains a smaller, compressed version of the .NET framework which enables you to run compiled Silverlight IL code. Silverlight uses XAML which enables you to write markup language using an XML syntax to express a UI.

That's the short story. There's much more to it (please leave a comment if the above needs to be corrected) but that's the basics as I know them of tonight. However - I talked a little and reflected a little during the rest of the presentations today and finally home again I have come up with this list of pro's and con's from my notes and my memories of the conversations I had:

Pros:

• The Silverlight Toolkit on Codeplex is a good thing and it reminds me that someone at Microsoft is beginning to "get it". The toolkit is released frequently and doesn't require the client to download an updated version of the browser's Silverlight rendering engine. Any additional usercontrols except the standard set of controls (which only covers the most basic textboxes etc)  are embedded in your specific Silverlight application.
• If you are a WPF developer writing desktop apps the switch to writing Silverlight website apps is easy to overcome because the context (XAML, .NET) are very similar. This isn't exactly the case with any other existing Flash technology where the learning curve is steeper no matter what you have tried before Flash
• Expression Blend is a working environment aimed at designers. How much you tweak and turn Visual Studio I have never heard anyone say that it is a good working environment if you aren't committed to reading code. Designers have had more luck with products from i.e. Macromedia and I think that Expression Blend is trying to please other roles than the "system developer" - which is good  :o)

Cons:

• I was told that if you i.e. copy/paste XAML from one file to another without also copying the codebehind, the target XAML file (with an empty code-behind) would only fail runtime - the compiler wouldn't let you know that you were missing method stubs in your codebehind to match the various events you had set up in the XAML markup. Error messages could be pure nonsense and debugging XAML is impossible. Of course you don't get to succesfully build a broken XAML document missing i.e. and end tag but checking for something as simple as method stubs should be a no-brainer. What am I missing here - we're at version 2.0, not some 0.8 beta release.
• It appears that there is a Silverlight unittesting framework available - but it sounds a bit disturbing in my ears that the suite of unittests runs in the context of a browser? In order for me to adapt to Silverlight I need to have a good testing framework around when adopting a new technology - definately something I need to check up upon.
• Styling in XAML means no inheritance - and your styles must be explicitly set on every element... That means that you can't have a general style for i.e. all your buttons which styles every single button on your site the same way. Oh no - you explicitly have to tell each and every button how it should be styled using an attribute on the button....... The guy from Microsoft breaking the news to us tried to be diplomatic about it. I can only imagine why this problem hasn't been solved when releasing version 1.1 - I wouldn't expect such stupidity to survive much beyond a version 1.0 of any product
• Silverlight applications on the web can't be indexed by Google. Microsoft is working on this issue which should be solved in version 3.0 (due in Spring of 2009). Google is a cornerstone in any marketing strategy so the lack of searchengine compatibility shouldn't be neglected when qualifying Silverlight as a mature product.

Bottom line is: I think it could be fun to work with Silverlight (I'm nothing but a programming scarecrow who likes to bring home new and shiny technology to my computer) and I think that Silverlight has the potential to be "big". I also think that right now I wouldn't use Silverlight for much more than menues, banners and other non-critical stuff which requires the user to have a decent visual experience but I couldn't recommend anyone using Silverlight for building fullscale websites based on what I've seen today. However this technology has come to stay and the web is increasingly getting focused on rich clients and UI so this isn't my last encounter to the Silverlight technology.

Regards Kristian

 

Links:

www.silverlight.net

Microsoft Silverlight: 10 reasons to love it, 10 reasons to hate it

Thoughts on a revised Agile Manifesto

Today I became aware that there is a movement in the Agile community which has been born out of concern that the Agile Manifesto basicly needs to be updated. The argument goes that core values was forgotten when the manifesto was announced and the manifesto needs to be updated or revised to fit the world of today.

I got curious - so I found an article by Brian Marick, one of the people who is one of the original signatories of the Agile Manifesto. He believes that there are several values such as "skill", "discipline" and "joy" are missing and needs to be clarified as core Agile values. A paragraph from the article explains why "joy" should be a core value:

"Now, I could say that a joyful employee is a productive employee, and that lack of joy on a project is like a canary keeling over in a coal mine: a sign that something big is wrong and you better pay attention. Maybe that’s true. I’d certainly like to believe it. But, fundamentally, I don’t care. I think joy is its own excuse. We deserve it. More to the point, those people around us deserve it. Their work shouldn’t suck any more than yours does, and you have it easily within your power to remove some suckitude."

I agree with him in every word - but the consequences of having the Agile Manifesto updated with terms that requires or expects joy from you in order for you and your team to be agile is a paradox. Agreeing that you are only doing things right when you are enjoying working on a project is like saying that you are failing Agile principles if you don't always have a good time earning your payroll - and that's where my warning signs kick in.

In another article James Shore expresses similar concerns - he calls it the decline of Agile. His concerns are clearly expressed in the following:

"The good Agile--the real Agile--it really works. I've seen it. My colleagues have seen it. It's been repeated hundreds of times, and some of those projects have succeeded for years. But those hundreds of successes will be drowned out by the thousands of failures"

Agile is hard. The rewards you get for being agile isn't something you earn just because it works well for your neighbour. You have to put in a lot of effort and be prepared to fail a lot before you "get it". This is by far the hardest part - to fall on your nose a lot in the beginning without loosing faith. The reason you do it anyway is because you believe in certain values. Agile is a set of values you basicly either can commit to or can’t commit to. The discussions in the community often circles around how organizations are implementing the values of Agile - the ”how to do Agile”. The ”what is Agile” is another discussion which should not be confused with the ”how do we succeed with Agile where I work”.

Why do you and I get out of bed and go to work every day? Ask yourself why - what is the core value that make you set your alarm clock to wake you up before you awake by yourself every morning? It's a simple question, but the answer isn't obvious and requires you to reflect upon your everyday life. The vision for me as a person to go to work every day is that I need to feel independant in order for me to function as a social, human being - so I have an education and go to work because the money I earn there helps me to get closer to that vision. I also believe in love and trust so when I found the one we got married because that was the way for us to make a vision we both share come true. What we do we do because we believe in something – we believe in visions and ideas and everything we do, how we react, the choices we make every day should be connected to core values which we believe in.

The Agile Manifesto is a vision - it describes a set of values, nothing more, nothing less. Discipline, joy etc. are not values as such - adressing discipline and joy when implementing Agile however helps you in making the vision of Agile come true in your work. We don't need to update the Agile Manifesto - we need better skilled, better trained, better educated evangelists who can communicate to the world how Agile is implemented because the values and principles behind Agile are generally accepted, I believe. The decline of Agile that James Shore is blogging about is a matter of people who made the choice of going Agile but don’t ask for help or are not being pushed in the right direction by experienced Agilists when they attempt to implement Agile for the first time. We should address those implementation details in terms of "how to do Agile", not "what is Agile". We don't need to devalue the current principles and guidelines of Agile by upgrading best-practices such as discipline and joy to something they are not – that would indeed be a clear violation of the Single Responsibility Principle, I believe ;o)

/ Regards K.

To TDD or not to TDD

I sat down today and reflected a little on SCRUM and TDD. The two are very alike in many ways and I have strong feelings for both of them because I think they work for me. They are "right" in a way.

Lots of blogs have lists of how you become better at SCRUM. The Nokia test for instance. I haven't however seen a list of how to become better at TDD. TDD is in the community more a "write your tests first and voila - your'e now a TDD developer"... Ehmm.... No, couldn't be farther from the truth. So I sat down and wrote for an hour and came up with the following considering the headline: How do you become better at "to TDD":

• Get the basics right. Spend at least an hour or two and read about TDD. How do you do it? What is the AAA syntax? Testdriven development means that you write your test first. If you don't know why that's crucial to your success as a TDD developer you should read some more before going on a TDD deathmarch.
• Want it. If you want to TDD you want to write your test first. No more "I'll write code and test if afterwards" - if you think like that you don't want to TDD yet.
• Know you will fail when you begin. You will definately suck at it when you first attempt to write tests. You will forget to write your test first - many times. Your code will look different and not "feel" right. Even the smallest problems will be hard to solve because you have to think on writing tests, tests, tests. It feels like the TDD approach hinders you from thinking on the three lines of code that will solve your problem and enable you to close the damn support ticket... Relax. This is perfectly normal. Ask for help and tell that you can't come up with a decent test for this specific problem. If a test is hard to write it is often because the code itself is flawed and has design issues which makes the code hard to test - and you are not able to recognize those code smells at first. Know you will fail - you also fell the first time you rode a bicycle, didn't you?
• Do it even when it's hard. It is easy to fall into the mental trap of "this code is 3 years old and un-tested so writing tests on this crap is overkill for this bugfix". No! You are not being paid to always jump over the fence at the lowest point - and just claiming that a codeblock is too hard to test without having asked for help or considered what it would actually require for you to make it testable ranges somewhere between stupidity and ignorance.
• Do it where it matters the most. If you have a piece of code which is central to your applications or is being called upon everywhere (i.e. that little string utility thingy which is shared across all your VS projects around) and it is untested - test it at all costs.
• Don't do it everywhere. If you have a piece of code which is used for generating reports once or twice a month for one person in the company and a test requires 4 hours of boilerplate work - don't do it, just make the code work.
• Get help. When you fail or things won't work your way - ask for help. It is the second-most crucial thing next to wanting it: Ask for help if you're stuck. Get people who knows how to do things to push you in the right direction. Read books, subscribe to blogs to get more info on how to TDD.

I believe that you will have to want to TDD the same way you will have to "want" to SCRUM because both SCRUM and TDD are basicly a mindset you must adapt to in order to make it work for you. If you want to loose weight you will have to want to not eat so much or you will have to want to exercise some more. Your mother or girlfriend can't make you loose weight nor can any of your teammates or collegues make you want to go TDD on your code. They can and will encourage you just like your family and girlfriend will encourage you to loose weight but it won't work permanently if you don't want it.

When do you know that you're on the right track? You know you want it. Ask yourself that question and if you know you still want to TDD deep inside everything is A-OK. If you don't then focus on getting your motivation back or decide to not to want to TDD. That is perfectly OK as well because why do something that you don't want to do? You can become a very competent coder without ever writing a single unittest. Just be honest with yourself and don't go TDD on your work if you don't believe in it.

To TDD or not to TDD - that really is the question :o)

/ K.

How agile are you?

I always had this sort of weird feeling towards "Take this test to know how lovable / sexy / fat / lucky / suicidal / etc. etc. you are" - however I found myself taking one today and right now I'm advertising for it... So much for standing up to your principles I guess.

Here it is - I got a steady 39 (brag, brag, brag). How agile are you?

/ Kristian

God Object

We've had problems lately in our Domain Model - it just isn't very easy to test and maintain so I researched a bit on the subject and found myself reading about God Object... Guess what I realized? We haven't followed the very basic principles of good OO design so we've ended up with a 1200+ lines of code long single class with 50+ methods which is responsible for everything happening in the M in our MVP triangle for some 20+ user stories implemented... High cohesion? I think not. Low coupling? I think not.

I've read a little further and found www.antipatterns.com/briefing also to be very informative about antipatterns in OO development. Right now I've got the hots for NDepend - my idea is that we need some kind of continuous feedback on our design and NDepend can give you feedback about cyclomatic complexity, lines of codes in your classes, number of methods in classes, the dependencies and relationships between classes and assemblies etc. etc. - and NDepend reports can be fully integrated in CruiseControl.NET which already is a cornerstone in our daily development cycle. I don't think a fullscale report on every piece of our current , non-tested, 5 year old code will do us any good - I actually don't think I dare doing it at all ;o) - but in our new projects to come I think NDepend could help us by flashing a warning sign when and where software entropy begins in our software. This feedback will enable us to reevaluate our design based on reports on the current state of our code and hopefully we'll be able to see antipatterns emerge in our design sooner.

Regards Kristian

Signs of having a dysfunctional team - great article on www.scrumalliance.org

I just read a great article on www.scrumalliance.org about team dysfunction in a Scrum environment. It's the first article on www.scrumalliance.org I've read and I think it is high quality stuff.

"Agreement isn't the same as harmony" is a quote I came by a few months ago. I try to remember this every time we've had a heated argument within my own team because as long as we respect each others opinions disagreement isn't bad in itself. It can merely be a catalyst for a later team commitment to i.e. design changes.

You have to distinguish between disagreement and disharmony - and of course you will have to have experienced both on your own body to be able to know the differences between the two ;o)

/ K.

OO - how hard can it be to explain?

We have hired a new teammember who started yesterday - very good news since our UI skills lack a bit and this should be a lesser problem once our new co-worker is up to speed.

However - our new teammember is fresh out of school and haven't learned a lot of the core concepts which we (the rest of the team) use on an everyday basis and take for given that we all know at heart - so having to explain what a source control system is, what the difference between "=" and "==" is in C# and questions like "What is object orientation"... That was one of the questions I got and off I went to see what Wikipedia had to offer on the subject

The intro is quite nice but I stopped after a few pages because GoF patterns aren't what you should throw at somebody 15 minutes after being presented to the OO paradigm for the first time. So we talked a little and I said I would go find some tutorial which could explain the fundamentals of OO in a 1-1 manner.

And I searched. And searched. And tried another search. And finally, after having spent nearly one hour on Google I have given up. I am simply unable to find a single webpage which explains the fundamental concepts of OO with a reasonable amount of C# code used to make the abstract concepts just a little more concrete. I see myself as being quite good at finding the stuff I need on Google so this doesn't exactly boost my selfconfidence a lot... Sure there are a lot of tutorials and I managed to find what I was looking for on java.sun.com but the sourcecode provided is Java and concepts like "What is a package" doesn't make sense to a newbie in C#.

I regret to have given up (I blame Google of course for not providing me with the answer to my prayers) but I will give www.stackoverflow.com a try on this one. And I wonder how spoiled we have become because of Google - I actually got angry with myself for not being able to input the 3-4 simple keywords into Google which would reveal the webpage I was looking for. Searching for various combinations and phrasings of "oo", "object orientation", "msdn", "tutorial", "explained", "c#", "fundamentals" etc. etc. etc. didn't do the trick this time.

I remember once upon a time (pre-Google that is) where you remembered each and every time you managed to find something valuable on various searchengines - a time when Hotbot and AltaVista were my favourite amongst lots of searchengines. Such a long time ago - 5-6 years I believe... :o)

Regards K.

Perception test

While researching a little this night (read: surfing Youtube clips to kill half an hour) I found myself watching this video:

http://www.youtube.com/watch?v=WSgE-7mP6Sk

Considering my post from yesterday about the art of testing nonfunctional requirements: We should first thing tomorrow stop asking people in the business "Does this piece of software work?" because they will look at the things they can see and filter out what they can't see! Damn..... We might just have to ask differently: "Did we miss out anything on this page?" and if the theory is correct they would be filtering away all the visible stuff and focusing their mind on what should be working but isn't....

Interesting thought, I think :o)

Regards K.

Testing for what you can't see

So - we delivered a product by the end of last sprint. October 1. was the deadline and we made it fine. Or to be precise: The code that we delivered worked fine. Nothing crashed, for instance. Well - was the release succesful? Not exactly...

It turned out that when we put code up to our staging environment we didn't have much of a plan for saying: "What does it mean to put something onto our staging environment?" We have always focused on being able to automate our releases so a release to our staging server never takes more than a few minutes and can be performed by anyone who has the password to our buildserver. In other words: Our Continuous Integration setup rocks - but what is it all worth if nontechnical errors are not caught until somebody is actually starting to USE our code? When is a feature Done - how do we test and assert that Done is really Done?

I will for the rest of my life never let nontechnical requirements to a feature be part of what IT can be blamed for if something gets released and doesn't work the way it was intended. That's just not what we are hired to do as software engineers - we build software. We are not supposed to have the deep insight in a business domain because we are hired to express the business needs towards their domain in programs and websites which provide the business with solutions to their problems. However - that's a dreamworld scenario because in a lot of companies IT has become the knowledge base of your business domain because of the insight you get into a domain when it is mapped to code. You have become bloated with too much information. How many of you have tried this - hands up everyone. I have both mine up right now ;o)

What usually happens is that the person implementing software also begins to take excessive responsibility for the business domain and while being responsible is good, being overly responsible is bad because people tend to think that "That's not our problem - that's something for the IT guys. They know what to do". When the business starts to react like this is the sound of an emergencyalarm going off.

I have a feeling that this is the usual case in most small companies and in quite a few large ones as well. IT knows what to do and how things are supposed to work. When this happens IT becomes responsible for the business domain and suddenly you have the business coming to the developers to ask for insight into their own domain.

I have a feeling that when we in collaboration with the business were unable to catch that a number of non-functional requirement caught us off-guard a few days before October 1. it is due to a number of reasons

• IT departement is supervising the business domain - but developers can't test their own code. Developers are in my opinion the lousiest testers the world will ever see - and that goes for both technical and nontechnical requirements.
• The IT guys takes the majority of responsibility because they know the business domain best - there can be a number of reasons for this (business culture for instance) but the business should never be excused for not being Master Jedi in their own domain and for not knowing their own domain at least as good as the developers.
  
• We tested what we could see - nobody tested for the things that wasn't visible.
  

What are your experiences in this matter? How do you lay off responsibility to the business domain experts and convince them that they are truly experts in their field and should take that responsibility on them? What are your Def. of Done criterias for completing a story? Lots of question asked, I know - drop a comment if you have something to share with me :o)

Regards K.

Microsoft Visual Studio 2010 sneek-peak

Microsoft is working on the next version of Visual Studio and has just published an article about the features of this and the corresponding version of .NET Framework which will be released as version 4.0.

 

I read the article and haven't dug deep into anything but I have noted that Microsoft claims that they will support Agile enviroments more in this release. So - with this in mind I read the article and this is what I noted down while reading:

• They have forgotten about the fiasco of CASE-tools and invented an Architecture Explorer which can draw visual diagrams of existing codebases. Visual diagrams of class coupling can probably sell the 2010 release to CEO's but is useless as a tool for developers. Typical example of some Microsoft gadget covered in visual sugar which might taste nice but leaves you with nothing but an empty stomach after you have eaten it.
• I noted this sentence: "Identify and run only the tests impacted by a code change easily with the new Test Impact View."  I (choose to) read it this way: You write a line of code and only run the tests impacted by your change. All other tests are NOT run. That's NOT very agile - early feedback is a core asset during agile development which is why you always run the entire testsuite in your project before each checkin. This tool is a good example of a tool which will do more harm than good in your daily life as a developer and I regret the fact that it probably will be the default to have this feature enabled after a standard installation of the 2010 release.
• The current Developer Edition and Database Edition is merged into one - that is actually good because agile teams don't distinguish between DBA-work and code. Everything is code and nobody owns parts of the business domain - so having the working environment being able to gap over both UI, code and database as default is a step forward.

I found an article on www.cio.com which goes more in-depth with the issue if you are interested. It is coloured in the sense that it doesn't question anything so read it to get to know more about the features.

 

I'm not very surprised by Microsoft going in this direction - doing a lot of effort to integrate their idea of what Application Lifecycle Management should be like but very little room for improvement and extensions to their way of doing things. If I had to work with someone who patented the idea of what software development was all about in our team and didn't leave room for me to challenge and change things - working with him or her wouldn't be fun. It could be and sometimes it probably would be - but the overall feeling would be mediocre at best. Why is Firefox the best browser out there? Because it allows you to extend it's basic functionality with something you find better. The way you are supposed to use the Internet isn't limited to what Firefix can and can't do - you own your own experience of browsing webpages through Firefox. If only Microsoft could get that and use it in their products...

 

Regards K.

 

P.S. - Not everyone at Microsoft is looking at their own bellybutton all the time. It looks like they will integrate jQuery into the ASP MVC, the Ajax Toolkit etc. which is very good news since jQuery is an opensource product which will continue to evolve in it's own direction regardless of what Microsoft comes up with in the future    :o)

JAOO 2009 - I'm going :o)

I have just returned from JAOO 2008 in Aarhus and that was all I hoped for. I can tell on and on about all the inspiration you get by going to such a conference but I won't right now. It might pop up on this blog in the months to come.

One of the things that settled in my mind was the fact that architecture isn't about structure - it is all about roles and responsibilities. Class diagrams aren't architecture - they are just a representation of one way to implement a given architecture. I don't know how many times I've drawn squares on a board to boxes representing "Person" and "Order" and by drawing a line between the two I believed I had the beginning of an architecture sketched. I couldn't have been more wrong and after these three days I'm beginning to understand why. Now I learned that in an architecture:

• Roles needs to be defined
• Responsibilities needs to be described
• Represent objects and actors to act on the roles and responsibilities you figure out

No wonder I repeatedly hit my head against the wall when trying to abstract my "architecture" a little, because building abstractions on top of implementations which have been built without a larger picture in mind is next to impossible. Programmers aren't used to describe intent which basicly is what an architecture is in itself - we just build stuff that works. I didn't get that one until this week.

I came to think of one approach I tried a year ago when modelling a new domain for an auction site: Object Modelling in Colour. Object Modelling in Colour essentially describes 4 types of objects, Party-Place-Thing, Moment-Interval, Role and Description. Using these four types of objects you can model an entire domain using archetypes to describe responsibilities and because each archetype is coloured you are able to quickly inspect a domain or describe a given domain to a non-technical person. We used it to model a new domain and the original domain model actually survived throughout the entire project so the initial approach made us deliver a very decent first shot at describing our new business domain. Just about everything else from there went horribly wrong on all levels but that's another story. Buy me a beer some day and I'll tell you all about it ;o)

Maybe this approach could be used again to model architecture? I haven't read up on it or heard from Modeling in Colour since then so the concept might have evolved since last time I used it but it could prove to be worth a try the next time we face an architectual challenge which requires us to take a helicopterride to get a birds-eye view on the things we work on.

One of the best quotes I heard during these three last days is this: "All code is cost. Only some code has value". Everything you do you should do only to deliver code that has value once delivered. You should focus on writing code that not only you care about. Sounds easy, right? It isn't...

I'll stop for now - I have numerous notes that I have reworked tonight. I am sure I will get back to reading them more often than previous ones because they are really good, I think, after reading them again during refinement and rework.

Regards K.

JAOO Aarhus - I'm going there Monday to Wednesday

I'm going to the JAOO conference in Aarhus Monday to Wednesday - I'm really looking forward to going there. I'm reading through the program right now - there are several tracks you can follow, i.e. Cloud Computing, Enterprise 2.0, Programming Languages, Railing, Solution Track and The Odd Track.

The conference is called "JAOO Conference - for developers by developers" - I looked up Microsoft TechEd and expected to find some similar subtitle and TechEd is mainly for developers as I can see it - developing Microsoft products of course. I would love one day to attend TechEd but I have this odd feeling that it is more of a commercial event where you get a pair of baggy 10$ sandcoloured pants, a pair of ugly glasses, a blue shirt plus a Beatles-haircut and suddenly you have 15.000 Bill Gates-look-a-likes wandering around praising a single technology. Maybe it is just a good, ol' prejustice and I would love if I was wrong about this one... Which is one of the reasons it could be fun to attend TechEd just to be able to go home and tell other people with similar prejustices that they should go as well.

JAOO markets themselves as being an agile conference and the technologies and methodologies presented on the tracks are more Java and Ruby-ish than they are Microsoft. JAOO does however have presentations where you get an insight into the .NET Technology and they are also able to invite a Microsoft stars such as Anders Hejlsberg and Eric Meijer to come and tell a story or two about LINQ.

The hosts and presenters of the tracks are not the primary ressource I believe - it is the people attending who will make the conference to whatever it will look like in retrospective. I am looking forward to sit down, get to learn new stuff and perhaps talk to people about agile stuff and what each of us are working on. If you are going (what are the odds? But anyway...) drop a note and tell me what you think and what you were able to take with you :o)

www.scrumalliance.org

I came by yesterday because I was awarded a membership as part of my Certified Scrum Training and accidently stumbled across the Email with my user credentials provided after the SCRUM course. The website seems to have quite a few interesting articles - and did you know that in order to be a Certified Scrum Trainer you must pay a one-time fee of nothing less than 7400 dollars... Of course you will have to pay an annual renewal fee of 7500 dollars but then your annual membership of the website is included (a mere 100 bucks).

I don't know - I just think that's a lot of money for having a reference to somebody who have an idea that you know something about Scrum. Anyway - I think I want to check out the site and read some of the articles. More to come later - if you know of other Scrum communities worth checking out please let me know  :o)

/ K.

Define user satisfaction

Quote from Software facts and Fallacies by Robert L. Glass - page 133:

"A user will be satisfied if he gets a product that meets needs, is available at an appropriate time, doesn't cost a fortune and is of reasonable quality".

We had a couple of real world users testing the website that we have been building for the past 3-4 months. I noticed a few things walking around yesterday evening while they were testing:

• Nothing crashed. I never had users come in to test any of my code on an entirely new website without anything crashing with an ugly ASP.NET stacktrace showing up.
• Nobody gave up and needed a lot of guidance help to complete their testing. There were a lot of questions of course and quite a few logical errors but people seemed to have a basic understanding of what they were supposed to do to keep moving forward.
• 4 out of 5 questions could be solved with a textual changes / graphics instead of written text or layouting the page a little differently. We could really use a dedicated tester which knows something about design and usability in our team.
• Nothing is as painful and as to see users revealing stupid logical errors. In Denmark we usually write the zipcode and the city on the same line: "7100 Vejle". We had an inputfield, some 30 characters allowed but we had clientside validation which threw an error if you entered any non-numeric value or more than 4 characters (all zipcodes in this country consists of max. 4 numeric characters. Small country, you know...). During our own day-to-day testing during development we had always just entered the 4 numeric characters which would pass validation check - and we would gladly have put this in production if users hadn't pointed out our own stupidity to us in advance.

As the wise men say: "You learn the most by your biggest mistakes". Point taken - we had a few things to correct. And - given the quote from above: We actually delivered something the users testing our system felt was useful - we tested on the night scheduled a month ago - we haven't spent more than a few months developing and it provided a solution to our Product Owners problem. How about that? :o)

Regards K.

Process change only works top-down

Recently I have researched a bit on how to make a SOA project succeed - and much importantly: Why SOA projects fail. Given that the best way to make speed is to avoid making errors uncovered by others a Google search for "SOA Antipattern" reveals all kinds of goodies.

There are a lot of repeated do's and don'ts around many of which are quite obvious. For one: "Don't dive into a SOA project with a Big Bang refactoring of all your infrastructure". Agile chapter 1, page 1 (perhaps page 2): Don't do big refactorings at all. There is no such thing as a big refactoring if you have committed to the agile way of doing software development.

But: There is one argument which isn't quite so obvious and can be counter-argued with theoretically. The argument goes that the owner of a SOA business case should be a business executive in the area that the SOA service should be serving. Why is that? Well: For one: It commits the business to take responsibility for the IT they want, a.k.a: Having the business own it's own IT business cases stops having IT delivering good, stable and reliable products which doesn't solve any problems.

Having experienced a bit of problems lately in our Scrum process I came to think that there are a few similarities between the two. You need the business present on a daily basis taking responsibility of the development of the product you are about to deliver. The key elements which are critical for the Product Owners to be mentally involved in a Scrum team are (in my opinion):

• Force the Product Owner to come to your Daily Scrum. No excuses - they must show up and listen to what you have to say. They might not understand everything but the team needs the Product Owner present to ask questions and for guidance.
• Speak their language. Never say "This feature sucks because it requires me to make serious changes to moduly Y and X" but "That sounds like a neat feature- and it will unfortunately take X days and hours to implement". They don't understand technical complexity but the PO has a deep respect for "Return on Investment" which means the time spent on a single feature by the development team.
• Make them test every time you commit something to the mainline /staging environment. No excuses. If the PO haven't tested an implementation the PO can't say it is Done and your team haven't improven the velocity of the sprint.

By following these steps you know that the Product Owner knows what's going on and can be held responsible for - well - IT projects that doesn't solve any problems in the business domain ;o)

The best way to ensure that the PO does in fact adopt to these few guidelines is to not let the IT departement drive the Scrum process. It can't be stressed enough. Any kind of process change and mindset change must ideally come from the Dark Knight of Evil, a.k.a the president of your organization. If i.e. SCRUM is only implemented within the IT departement you never get the Product Owners to adopt your philosophy because the live in a different world with a different mindset than yours. That mindset might not leave room for i.e. half an hour of testing when the Scrum Team says something needs to be tested. It is probably not because the Product Owner doesn't know or can't see the value of testing - but if the Product Owner is being overruled and assigned other priorities by his/her boss the SCRUM process fails because the team is unable to show progress to the rest of the business.

It's all a matter of prioritizing time - the SCRUM team and the Product owner needs to have the same priorities and only the Dark Knight of Evil mentioned above can reassure that the priorities are the same for various Product Owners and the various development teams within an organization. That's why the biggest antipattern in my opinion when implementing SCRUM in an organization is to let a single departement drive the mindset change through. It'll never be a good experience for all parts and inevitably the SCRUM process will be questioned again and again.

IE8 InPrivacy - good or bad?

Take a look at this entry on the IE8 blog: Microsoft's latest weapon in the ongoing browser war is a feature called InPrivacy which basicly protects a user on the Internet from having i.e. cookies persisted on the user's harddrive from websites he or she visites. Cookies can be impersonated - that is, they are no longer stored on your harddrive but remains in session scope so when you close your browser or goes to another webpage the provider of webpage X doesn't have a clue about you whenever you re-visit the webpage...

This is good - or is it? Everybody (or at least everybody I know) hate banners for one. They are plain out annoying. I can't think of one single time where I clicked a banner during the last 6 months on purpose because I was intrigued to get to know more. There are several ways of removing ads while you are surfing without making your browsing experience very unpleasant because this is what will happen if you disable cookies in your browser. Most sites simply won't allow you to log in or even surf the website if you have disabled cookie persistence - and user's seem to comply with this since cookies are so widely used to store information about a user visiting a website.

So - imagine a world where cookies are enabled but only per session - nothing is saved. What will happen? A few things is bound to happen:

• Everybody sees the same adverts because everybody comes without the vital information needed to track your recent visits down.
  
• Visitor statistics on a website will be less trustworthy
  
• Personalized content is not possible before the user logs in (which requires the user to create an account etc. etc)

This might not sound so harmful from a developer's point of view but to the Marketing and Sales Departement this is bad news. How to increase income if you don't know anything about your users? How to predict trends and plan for market movements if you are rendered blind by your users because they use a browser which only impersonates cookies but does not save them?

Cookies are not the only way of tracking users - I wonder if this guy will pull if off - but the cookie protocol is so simple that everything but cookies as a usertracking device is a more tedious task to use than simply using the HTTP cookie. However the trend against Internet advertisement begun several years ago with the first popup-killers so the InPrivacy feature could be somewhat expected. Microsoft would eventually enhance the popupkiller feature in IE6 which was the first mainstream, non-third party attempt to enhance the user experience of browsing the web and as they say: The future is what's happening while you are thinking ahead.

What do you think of Microsoft's InPrivacy feature - and what will the consequences be for people using the Internet in the years to come?

SQL Profiler tip

Ages ago I discovered a nice little feature in SQL Profiler to enable you to only see the queries which comes from your machine. Very useful if you are not the only one using a database and want to track down which queries you are responsible for initiating from your local machine. I assume that you have basic knowlegde of SQL Profiler and trace templates - otherwise you should read more about this fantastic profiling tool before you proceed.

Here goes:

1. Start up SQL Profiler
2. Choose File --> New trace and attach to your database
3. Click on Show All Columns - and whoops: Up comes the column "Hostname". Choose this column for every event you want to appear in your trace.
4. Click On "Column Filters"
5. Find the "Hostname" column and enter your computer's hostname in the "like" field
6. Save your trace as a trace template - name it i.e. "MyComputer"
   

Now - this is the sweet thing - you can fire up SQL Profiler and trace every query which comes from your machine. All you have to do is to choose the trace template "MyComputer" and start tracing calls which only you have started.

I find it extremely powerfull because it enables you to debug single lines of code in Visual Studio and monitor exactly what SQL is hidden behind various peeks and pokes to your domain model. I use it about every time I use SQL Profiler - I couldn't live without my personal trace template.

Nothing magic about it - just one of these mighty fine things to have in your debugging toolbox I guess ;o)

Regards Kristian

Definition of quality - part #2

Followup to an earlier post about how to define quality - I actually heard another definition a few days ago which claimed that "Quality is when customer expectations are satisified".

I dare you: Can you argue against that definition and point out the weaknesses in the above statement?

Javascript != Internet Explorer

I had this funny experience today with this little piece of Javascript:

function Redir(sAcceptUrl, orderId)
{
document.location.href = sAcceptUrl + "?orderid=" + orderId;
return false;
}

The function was called by a button's onClick-event like this:

input id="theBigRedButtonGoesWild" onclick="Redir()" type="button

This worked fine in IE but not in Firefox.... Firefox just posted to the same page and didn't care very much about the document.location.href change - What the hey ???

It turned out that when using this little function in Firefox you have to use the return value of the Redir() function in order for the Firefox event model to NOT perform a postback - like this

input id="theBigRedButtonGoesWild" onclick="return Redir()" type="button">


It has something to do with the fact that a button in Javascript is actually always a submit-button and inherits it's behaviours from a world which posts back if nothing else is being dictated. IE's event model is - well - different ;o

This was just a quick one - I am on vacation for 3 weeks starting in about 5 hours (first thing on my todo-list: Go to the parent's house and mow their lawn because they are on vacation...) so this blog will be on hold until I am back from work

Regards Kristian

RSS feed

For Your Information Only: I have burnt my feed on FeedBurner so please change the URL to this feed in your favourite RSS reader to this one:

http://feeds.feedburner.com/JustAnotherSoftwareEngineer

Thanks - and a nice weekend to you too :o)

Regards K.

Antipatterns exception testing

During my first encounters with Test Driven Developement (TDD) I adopted the ExpectedException attribute and used it heavily when coding - that is: I focused a lot on testing for every exception written in the code.

I have come to the conclusion during the last few weeks that my testcases didn't provide very much value if you test heavily for exceptions. There are a few bulletpoints to mention here:

• Tests written for testing errorconditions on general exceptions (ArgumentNullException etc) are not important. You should write exceptions for ArgumentNull etc. etc but I don't test for them anymore. Focus your testing on things you can assert instead - a test which throws an error will fail the test so even if you don't write an explicit test for the error condition your test will still fail you if the error occurs. Never ever aim for 100% code coverage - if you do you are walking a deathmarch.
• Business value exceptions are on the other side very important to write tests for. If you have custom exceptions classes which you throw when i.e. a business rule fails to validate you should write a test which succeeds only if the error is thrown. This provides business value: You know that your business logic works because you get your expected exception thrown
• If you throw exceptions in your code WITHOUT explaining what went wrong I will hunt you down and shoot you in the legs. Not very pedagogic indeed but exceptions are only useful with a meaningful description of what went wrong. You are giving the consumer of the exception no data to help figuring out what went wrong.
  

Which best practices on this issue do you reccommend to others?

Rhino + VS debugger == WFT?

We have used the MVP pattern lately in my recent project to increase testability and decouple the UI from our business logic. To enhance our testing environment we have begun using Rhino Mocks and it is an overall satisfying experience even though I am still having a hard time "getting it right" when writing tests.

I want to share with you one of the "What The F***" experiences I had just a few minutes ago: One of our mocking tests failed. Well - insert a few breakpoints and fire up the debugger. And then it happened: For every time I ran my test I had errors on different lines in my source code... Most of the times I had a NullPointerException but at other times the Rhino framework threw mysterious errormessages at me...

I was a little scared to see a unittest behave like this for twenty minutes and really had no clue what was happening but my collegue was able to solve the puzzle once I asked around for a little help. What had happened was that in my MVP Presenter I had set up an mock of my view and some expectations for different properties to be called during OnLoad. They should be called just once so when you start using your debugger's Quickwath on those properties you "use up" the quota of expected calls. You are actually fulfilling the expectation you just set up when quickwatching a property in a test with expectations set Rhino-style... And when the code afterwards tries to execute the code you intended the expectation to test for your test fails because you only set your property up for being accessed just once.

Lesson learned today: When a test which uses mocking fails you - clear all breakpoints and try again. It actually solved the mystery and I was able to fix the initial cause of the error within a few minutes.

Firefox - not just another browser

Disclaimer: Lots of people have written this post before me. Don't come back and tell me that you haven't heard this one before ;o)

*****************************************************************

I am usually very relaxed when it comes to the tools I am using - I use whatever suits my needs and strive not to be very religious about who created them and if I am using the newest version or not.

I have used Internet Explorer for quite a while (always actually). I have tried a few browsers over the years the latest one being Maxthon which was recommended to me by one of my former collegues. It never hit the spot mainly because I didn't give it a real try - I didn't spend enough time to see what extra value it could provide me because it seems to be a quite successful browser variant.

However - I must admit that the new Firefox 3 is amazing mainly because it is so freaking fast. It feels like I just had my computer upgraded to a bigger processor and doubled my RAM. This is the first browser I have begun to use as frequently as Internet Explorer - simply because it is better than it's competitor. The addins are also extremely powerful - they have been around for years but the vast amount of plugins written for Firefox is simply amazing. If you want to do something whatever it is - searching, social networking, image grabbing, resizing, debugging... Somebody is likely to have written a plugin for Firefox which enables you to do whatever you want to quicker and easier than before you discovered the plugin.

Speed + extensibility = I love it. IE isn't a bad browser at all but they should really be careful not to be become a has-been. Jugding by these figures IE still wins the socalled "browser war" but they are about to loose precious market shares unless they saddle up and start producing something of similar star quality.

Regards K.

Fusions for dummies

Does anybody know where to buy the "How to merge IT-infrastructure and culture of an organization - for dummies"? Well... My company is about to take part in a fusion which will give birth to a unified organization responsible for all sorts of athletics, sports and excersise in Denmark. Today we had a meeting where we discussed various issues concerning IT-migration stuff and various non-tech and tech. related issues. This is a quick summary gathered from my personal experiences and beliefs - it does not relate at all to anything other than my personal view on how to do things "the right way":

Do figure out a way to quickly deliver some shiny new functionality It sounds like an anti-pattern but it will make you and your current organization shine. It will also help positioning you and your team as a neccesary and vital part of a future IT-departement. Sometimes (most of the time, actually) people in charge doesn't have a clue about what's right and wrong in the world of software development - they however are in charge and do prefer shiny new stuff rather than a Powerpoint filled with techstuff which are very sexy if (and only if) you are a software developer.

Nothing good comes to he who waits. Be aggressive and argue your case to ensure that it is your concept and strategy which will lay the foundation of a new IT-infrastructure

Plan an internal plumbing-strategy to refactor old technical debts to a more smooth and agile solution. Focus on the most basic principles and stick to them. Get used to release often - in the wakening of a new organization waterfall strategies are doomed to fail miserably so you will have to be able to deliver quickly as Product Owners find themselves in the process of getting to know your new organization.

- People before you have lost wars because they won the wrong battles. Don't spend time upgrading your backend support system even if it sucks and lacks basic features - you can be pretty sure that a new one from another company will be planned for in a new organization. It sucks, right? And you argue your cause, so you have the arguments ready to convince the new IT-boss that the system should be discontinued in a new organization. Your frustrations will end on a specified date - don't waste precious time on upgrades if they will not survive the birth of a new organization

Be agile! (can you see the yellow glow above my head?). Don't expect anybody to be able to answer questions about the future so get used to living in a world of chaos. Be pleasantly surprised if you get guaranties and precise directions but don't be overly disappointed if people fail to answer to your frustrations. They don't fail because they want to displease you - they simply does not have authority or plain out doesn't know any better than you do.

Regards Kristian

The infamous Save() method

We (a collegue and myself) had a little infight a few days ago during a pairprogramming session - I advocated for having all Save() methods being void and parameterless whereas he didn't see any problems in having them returning objects and/or taking input parameters at will.

I couldn't at that time argue my case except that I saw this as a violation of the SoC (Separation of Concerns) principle - and why force the consumer to handle a return value if the consumer doesn't need to have one? The discussion grew a little ugly at some point but yesterday just before leaving the office we talked it over again.

It turned out that my collegue's experienced with TDD for various reasons has not been overly positive - having to figure TDD out for yourself without having some sort of experienced mentor inhouse will lead to frustration in 95% of all cases once you try to use TDD in a real-world scenario. We argued about having a signature of Save() methods in general and I understood my own reservations when we discussed what would happen once the signature of the Save() method changed because we i.e. wanted to introduce a new parameter in a call to Save() - example:

public void Save(string a, string b, int c)
{ ... }

was to be extended with:

public void Save(string a, string b, int c, List d)
{ ... }

What happened in his mind was that the compiler would burp on all places where the Save(a, b, c) was used so you had to change the code of your tests in all places.

What happened in my mind was that you had to change all working tests using the infamous Save() method because you changed a single signature of a method. This is bad because

1: The time spent maintaining your tests should be kept at a minimum
2: You could be mislead to work around changes in your model to avoid having to alter your tests to reflect that change - and THAT should ring the alarmbell.


Conclusion:
1: Having simple method signatures should be a goal in itself to avoid breaking the code of your tests when you want to introduce new functionality and parameters which needs to be carried around in your application.

2: Do use objects to carry around parameters for you. Less code is needed and the readability of your code is much higher. Having i.e. an object carrying 10 primitives around your model is much more extensible than having to extend every class with a property for param #11.

3:
You should not be afraid of having "dead" objects in your model and view which can only contain data. They are keeping the numbers of properties and overloaded methods in your application to a minimum :o)

Related articles:

TDD antipatterns (I don't agree to every one of these but it is a good checklist)

This guy suggests best-practises for API design:
How to design good API's

Inversion of Control article

I finally found an article which explains the IoC concept and value of using an IoC framework. I think I grasped the concept quite a while ago but what the value of this IoC thingy was remained unexplained to me...

http://www.ytechie.com/2008/06/i-finally-get-the-point-of-inversion-of-control.html

The Pareto Principle

Did you know that the 80/20 rule is also known as the Pareto Principle? I sure didn't ;o)

Check it out on Wikipedia

/ Kristian

Certified ScrumMaster notes

If you ever see anybody on the street giving a strange handshake and barking like a dog you have witnessed two ScrumMasters saying hello to each other. That was the last thing I learned last week at our ScrumMaster Certification Course held by Boris Gloger, the founder of Sprint-iT.

I won't go into detail about the course but I want to share with you my notes. They may not mean anything at all to you but I think they will mean the world to me in the next few months when I end up in situations where mindsets have to be changed, priorities have to be explained and roles and responsibilities are to be established.

I at first wanted to write them all down but I will try a new approach: The photography. I have seen many people use photos of slides and flipovers with crude drawings and always thought that whatever was on the slide now got put away in an image and wasn't properly "refactored" into useful notes. However, I ended up asking myself how useful my own notes are to me and to tell the truth I rarely (if ever) go back to notes I have made earlier. I must be doing something wrong otherwise I think I would be using them more often. So now I will try a new approach to see if pictures of Post-its saved on my harddrive will be of more value to me than notes properly entered in a Word document.

Here they are - the combined results and "Heureka"'s of two days of Scrum training. Read them all if you like and please do comment on any of them if they puzzle you or simply looks interesting to you.

Regards Kristian

 

P.S. - If the quality of the images are too low on the Web due to Blogspot fiddling with the size / quality of uploaded images you can download a zipped package of all the notes here. The image quality is not very high to begin with - this is because I had to take them with my mobile camera (the new HTC S730... Windows Mobile 6 with WiFi, GPS functionality, Qwerty keyboard and a default ringtone which scared the pants of several fellow customers at the local hardware store the first time somebody gave me a call)

P.P.S. - I noticed that one or two of them has Danish writings on them so if you bump into notes where you mumble "What the hey ???" then you should do a spellcheck to ensure that you are trying to decipher English notes instead of Danish  ;o)

Hello Rhino World

I have discovered something tonight - the art of testing through mocking. Yes, I admit it: I've never actually given much thought to the fact that mocking could be remotely interesting due to the fact that a mock is simply just a replacement for something you intend to test, i.e. a database access layer or external devices connected to your computer. I do not like to think of myself as being religious but nevertheless I have never given mocking a try because it just didn't feel right (!). So much for trying to see things from the other side - until now, because:

We have had quite a few exhausting weeks at work. Our source control is coming up to speed and a CI build enviroment is slowly emerging. It just builds everything but we are working disconnected from eachother and nobody can screw up the build for days without getting instant notice. I like it sooo much... We have hired one of my former collegues, who is now an independent consultant, to tell us about Agile development and TDD. Last Wednesday we talked a bit about mocking and I peeped a little about the paradox of testing a simulated version of the real world. However I decided that I would give a mocking framework a try one of these days and I tried it out tonight, so I created a simple scenario:

I want to create a Person object and store it in a database. The person should expose to me whether or not he has been saved or not. Separation of Concerns, I know, I know... I'm just mocking a scenario here... (applause sign on). And - tada - I want to test on both a real object and a mocked one and be able to retrieve a positive response whenever I ask Mr. Per Son: Have you been saved?

I downloaded Rhino Mocks because I had it recommended and it seems to be some sort of de facto standard these days - mainly because it is strongly typed which doesn't seem to be the case with other .NET mocking frameworks. I created the following unittests to mock my reallife Person object:

[Test]
public void CreateDomainObject()
{
Person p = new Person();
Assert.IsNotNull(p, "Person is null");
}

[Test]
public void RealPerson_NotPersisted()
{
Person p = new Person();
Assert.IsFalse(p.IsPersisted());
}

[Test]
public void RealPerson_Persisted()
{
Person p = new Person();
p.Save();
Assert.IsTrue(p.IsPersisted());
}

I then created a Person object to simulate this behaviour:

public class Person
{
private bool persisted;
public Person()
{
persisted = false;
}

public void Save()
{
persisted = true;
}

public bool IsPersisted
{
get { return persisted; }
}
}


...and now things get interesting. A mock of the Person is introduced in the following test:

[Test]
public void Mock_Persisted_Property()
{
IPerson persistedPerson = GetMockedPerson();
Assert.IsTrue(persistedPerson.Persisted);
}

private IPerson GetMockedPerson()
{
MockRepository mocks = new MockRepository();
IPerson person = (IPerson)mocks.CreateMock(typeof(IPerson));
Expect.Call(person.Persisted).Return(true);
mocks.ReplayAll();
return person;
}


The MockRepository makes it possible to take an instance of an IPerson object - that is, an interface describing the methods and properties on the object you intend to test. The domain object does not actually have to inherit the interface so if you do not want to have your domain model "interfaced" for various reasons, you do not have to. The IPerson I created is simply:

public interface IPerson
{
bool Persisted { get; }
}

I do not want to do anything with Save() so I leave it out of the interface. Maybe it is not best practise - I'm a newbie on this so you are obliged to guide me in the right direction if this has proven to be an anti-pattern.

In the Expect thingy I decide that a call to the Persisted property on my Person object should return true. The mocks.ReplayAll() stops recording expectations on my Person object and now I am ready to validate my expectations in my tests.

This makes it possible for me to run the Mock_Persisted_Property() test succesfully - and retrieve a positive value when asking if the Person has ever been saved even if the Save method has not been called. This is truly great because I have had numerous encounters with problems regarding third-party vendors and external hardware and processes which has not been testable for me until now either because testing them would result in extremely slow integration tests or that the tests themselves and the chance of a succesful test suite run would be extremely tightly coupled to a certain state of the hardware being tested (i.e. the hardware device should always be on and responding to requests).

I like this a lot. I have only scratched the documentation but I will definately go deeper into this during the next weeks and months. I have seen the light.- or at least seen the possibilities instead of only focusing on the limitations of mocking ;o)

Regards Kristian

P.S: - The entire source (Visual Studio 2008 solution) can be downloaded from this location

It has been quiet for a while

I just want you to know that I'm not dead or anything - just haven't had the time to gather my thoughts on the things we're working on right now. I'm about to become a Certified ScrumMaster late this month - having worked with Scrum for almost a year I think it is about time to get the theory in place. And I have made sure that every person in a Product Owner role at my new job have been submitted to the Product Owner course. And I have been a fireman all last week or so... Continuous Integration to the rescue in a not so distant future...

Hang on out there - I will share something with you guys when I have something ready for you guys.

Regards Kristian

The art and magic of manual deployment

Well... I promised myself that I would write a post on this blog at least once per week. I actually tried but always halted on the one question: "Uhm - what to write about - I've only got some 16 hours remaining..."

What is the purpose of such a goal if you have to dig deep to find something remotely interesting to write about? I therefore announce that I will only be writing whenever I feel like it. Heck, nobody of you guys (all three: You, my mom and my parent's dog - I haven't got a clue how many people are actually reading this) even knew that I made a promise to begin with but it sounds pretty good, right? ;o)

I have went from a complete newbie in my new job to actually being able to deliver some kind of work. Slowly I have begun moving tasks from the "Sprint backlog" to the "In progress" and actually some of them have moved to the "Finished" part of the whiteboard without being moved back a few hours later. It feels good to participate in getting a job done. We're releasing March 25 and have loads to do - I haven't got the time to write this but the second option was benchmarking on various Danish newspapers for news I couldn't care less about anyway.

The reason for choosing Option #1 was that yesterday I suddenly realized how much time we spend deploying stuff to our staging enviroment. Everything is done manually so if you have changes in 4 files and you added a new Usercontrol and included a new Javascript file to the solution you will have to _manually_ (yes, manually) find all files and upload them to the staging server. That is as crappy as it can possibly be. Where do we get these files? From the developer's machine, what else? Yes, my boys, everything is left to the man behind the machine with the largest possible margin for human errors to occur. And of course we have no backlog of uploaded files on the staging server so if you accidently overwrite the wrong file with one that will break the stagingserver's build you leave your users f***ed until you correct the error (that is: restore a backup from your own machine or call the server maintenance guy to restore the file for you from yesterdays backup because you haven't got a working backup locally. Yeeeehaaaaaaa!!!).

I have read a bit about how we can use our Continuous Integration enviroment to deliver a clean build for every checkin to be able to make revised deployments. My thoughts are to build the scripts neccessary to let the buildserver create a fully deployable package for every checkin which will enable us to synchronize i.e. revision 1447 of the codebase (stored in it's own folder) with the content on the staging server using robocopy. I have no experience on creating scripts apart from reading on various blogs about related issues but I promise to write a few follow-ups on the matter as we get along. Until then I will be stuck with issues such as deploying files from my machine which I acciddently forgot to check in.... There's nothing but work to do here, I suppose ;o)

The Decision Trap

I have been developing software for about 6 years now - give or take. Throughout that time I have had numerous encounters with users when I try to explain to them why they have to make a certain decision to enable me to figure out how I am supposed to approach a specific problem. Maybe I am not the best to communicate (being married I know that for a fact) so I have had a few meetings which went pretty ugly because I was unable to tell the users why they had to have an opinion on matters such as a particular detail in the flow diagram or in a certain submit form. The answer sometimes was "I don't care - I just want to be able to f***** submit an order! Why can't you just make it work like I have told you a million times before in our previous meetings?". I do not remember the exact words so maybe the F-word was left out in the actual conversation but the other parts of the conversation was close to the one described.

I have always taken this as a sign of users really not being interested in doing their job properly. They didn't want to spend the time to investigate on their responsibilities when they should describe a certain story or task for me - in the end that was something which the computer guy would probably do better. Somewhat simplified and with a few exceptions I must admit that I have thought this about my product owners more than just a few times. Just until this weekend actually when I was put in a user's situation without even knowing it. The story goes:

At home we decided a few months ago that we needed an outer house with a second bathroom. We had one but it was not heated, the rooms were badly placed, not wired properly and the entire building was not isolated at all. We have a kid and expect a few more to follow in the coming years so we need a place beside the main house where you can get rid of dirty clothes, dust of the contents of the sandbox in our yard and change shoes before opening the door to the kitchen entering the main house. So we went to the bank and lend a lot of money and last weekend we tore the outer house apart completely. Down to the bones - nothing left but 4 walls and a roof. What a mess..... Afterwards we dug out 40 centimeters down to be able to get water pipes, sewer lines, electriciy and yadi-yadi into the floor before isolating and sealing off everything with concrete for the rest of our life. I have my dad helping me out because he recently retired and I felt a strong obligation to make sure that he doesn't sit on is behind all day and disintegrate. The fact that he has been a farmer for 20 years and a craftsman for 40 in various enterprises and knows everything about building a house there is - that's nothing but a nice sideeffect ;o)

After digging and moving dirt all last weekend he spent the last week building infrastructure such as sewers, electricity, cold and warm water etc. Last Saturday I helped him with the tubes for the floor heating system we decided upon and everything went well. We went in for a cup of coffee because he had a few questions regarding the placement of various items such as toilet, shower, washing machine etc. so he shoot at us and we answered the best we could. I hadn't given much of it any thought because I am not very detail oriented as a person - luckily my wife had thought a bit more about things than me so we quickly gained a shared understanding on what we wanted to do with Outerhouse version 2.0 whenever the project was finished in late 2008.

My dad at some point caught me off guard with a question on how much isolation we wanted to put into the walls. I replied with a tired face: "What do you suggest?" and he replied somewhat similar to "Well there are a few options" and started explaining that if you went for option A you didn't have to put as much into the walls as option B and C because - but if option B was the chosen one and we didn't consider D and E we could get into trouble later on if we decided to i.e. change placement of the tumble dryer.... I felt an urge to cry out loud: "I just want to sit down and take a dump! That's my primary success criteria for building a restroom - I want to empty my back reading my favourite Gary Larson comic! If it is cold outside I want to be able to turn up the heat and pay a hideous heating bill 6 months later. Can you build me a toilet and some floor heating, please? That's all I ask for".

Needless to say I didn't say anything but went for one of the options of his choice being tired of having to take all kinds of matters unknown to me into account and deciding for myself. I realized later on that I was just being a user caught in the Decision Trap - knowing that your decisions today will have great impact on all kinds of things totally unknown to you and at a great cost in time and money if you make the wrong call today.

I learned an important lesson that day - and the next time I get into a meeting with users being tired of stupid developers asking stupid questions about stupid issues I will have a little first hand experience which hopefully will enable me to put myself in their situation before ruling them out as impatient and irresponsible product owners ;o)

Minimize Outlook to System tray

I found this small registry hack today because I have always been tired of having Outlook consume space in my Windows Taskbar. Enter this registry key and whenever you minimize Outlook it will only appear in the System tray. Sweeeeet....

Disclaimer (primarily because 90% of the readers of this blog are from the States ;o) ): Do NOT in any way try to alter settings in the Registry if you do not know what you are doing. I will not be held responsible blablabla.... if you mess up your own machine.

Hack is for Outlook 2003 - the Key path will be different if your Outlook is not the 2003 version.


Hive: HKEY_CURRENT_USER
Key: Software\Microsoft\Office\11.0\Outlook\Preferences
Name: MinToTray
Type: REG_DWORD
Value: 1 = System Tray, 0 = Taskbar


Reference: Click here