Being Cellfish

Stuff I wished I've found in some blog (and sometimes did)

May, 2008

Change of Address
This blog has moved to
  • Being Cellfish

    I don't like Mock objects


    When looking at BDD and TDD examples it is very common to see the use of mock objects in the code. This however strikes me as a little bit strange since I think you should use stubs and not mocks when working with BDD/TDD. A mock is basically a stub with the added knowledge that a mock object knows how it is expected to be used. In my opinion this fact disturbs the focus when  applying BDD/TDD. Additionally I think maintainability is decreased since the tests will now have a dependency on implementation internals and you risk having to change your test not because the API has changed but how things are done internally.

    Let me explain what I mean with an example. Consider a data object used to handle transactions and the ability to read and modify the amount money on a given bank account. Now assume this data object is used as a parameter to a transfer method that is used to transfer funds between two accounts. One way to implement the transfer method could be:

    1. Start a transaction.
    2. Get amount from the to-account.
    3. Get amount from the from-account.
    4. Set new account amounts for both involved accounts.
    5. Check that the from-account does not have a negative balance.
    6. End the transaction.

    From a maintainability point of view I think mocking the data object will be risky since the mock will verify that the correct number of calls are made in the correct order. It wouldn't surprise me if we some day saw a new transfer implementation looking something like this:

    1. Start a transaction.
    2. Get amount from the from-account.
    3. Check that the amount is enough.
    4. Get amount from the to-account.
    5. Set new account amounts for both involved accounts.
    6. End the transaction.

    The example may seem a little far-fetched but still I think it points toward a maintainability risk involved when using a mock. But OK, let's assume that maintainability will not be a problem. We're still shifting focus from what is important I think. As soon as a mock is involved when I write my test/scenario I do not only have to think about the behavior I expect. I must also think about how my mock will be used since that may or may not affect my test code. Using stubs instead of mocks will reduce that focus shift since stubs are just doing what they're told without regard of context.

    Sure one might argue that using stubs will also involve having to think about how the stub is used. That is true but without the risk of having order or number of calls to the stub mess up your test/scenario setup. And the less time you spend on thinking about setup and the more you spend on defining behavior, the better I think. And thinking about behavior of internals and/or dependent objects should just be kept to an absolute minimum if you ask me.

  • Being Cellfish

    When pigs fly


    Flying PigThere are probably a lot of people out there that would say that Microsoft will develop stuff for Unix the day pigs fly. Well in that case you better start looking out for those flying pigs! If you somehow missed last weeks announcement I've collected a few links (and still collecting) regarding System Center Cross Platform Extensions.

    The pig in the picture is one of all the flying pigs thrown out to the audience during break out sessions and handed out in the information booth during MMS 2008. It was quite popular I've heard...

    So why is SCX pig flying news? Except from the fact that Microsoft is now making it possible to manage non-windows servers using the same tool as for windows servers; Microsoft is openly using open source in one of its applications, have announced that it will take an active part in the open source community and contribute back to the community, for example as a member on the OpenPegasus steering committee.

    Oh, and one more thing. The engineering team is partly located in Sweden, a country where Microsoft haven't had any developers (except consultants and evangelists) for quite some time. At least it is breaking news for all Swedes...

  • Being Cellfish

    SQL crosswords


    I don't know what's worse; making crosswords with only SQL related questions (requires free registration to access) or actually trying to solve the same. This is one of many thing that currently puzzles me. One other thing that also scares me is that I get annoyed when I cannot solve these crosswords right away...

  • Being Cellfish

    Tobii has an eye for Scrum


    Yesterday I attended a presentation at Tobii on how they've implemented Scrum in one of their development teams. The presentation was started by Henrik Kniberg who gave a short introduction to Scrum. I do not envy his task since a quick poll showed that more than half of the audience was practicing Scrum in their current project. One thing that always amazes me at these kind of presentations are the two or three persons attending who think that Scrum is a silver bullet solution to all problems and who ask all kinds of questions related to their current situation trying to figure out what they have to do in order to make their Scrum implementation more successful. What they don't seem to get is that Scrum is not the answer to your problems - it just helps you see your problems. You still have to solve the problems yourself!

    But back to Tobii. We got a great demo on what eye tracking software can be used for,including playing FPS games. And I must say it was extra interesting for me to see what the team was really developing since I was the person brought in to coach them when they wanted to start using Scrum. I attended daily scrums, sprint demos and retrospectives but I never got a chance to see and understand what they really accomplished.

    So how did they implement Scrum? I would say they pretty much implemented vanilla scrum from out of the box I would say. But this is usually not enough to successfully implement Scrum I would say. In their case I think the following things were the keys to success:

    • The interest in Scrum came from the development team. Not everybody and they were a bit suspicious to some of my suggestions in the beginning but that is only healthy. You should be suspicious to new things and evaluate if you really benefit from them, but you must be willing to try at least.
    • The team got a product owner who quickly saw the benefits from a new way to work and embraced it. Last I heard she was talking about implementing Scrum into the sales and marketing teams too...
    • They used an external coach from time to time. I wasn't there to help them every day and sometimes they worked two or three sprints before asking for my help again. Using a coach from the outside is very valuable I think since the coach not only comes in and sees any problems from a new point of view. An external person can easier say things that people involved in the day to day work are reluctant to say in order to preserve a nice fussy feeling at work.

    So what can you learn from this? Well, doing great stuff is always easy when you have great people to work with. The team I worked with at Tobii had all the best prerequisites for success and that is one thing you either have or you haven't. But what you can do is to use a coach. Having the ability to discuss different matters with someone outside of your regular workmates as well as having somebody that easily can say those things everybody want to say but are afraid to say can in some cases be what makes or break your implementation of Scrum.

  • Being Cellfish

    Stored Procedures and data sharing


    In my career I've worked with stored procedures in a way I think many people never do. For example I've worked on projects where both the data access and the business logic have been placed in the database in the form of stored procedures. Not quite your standard three-tier solution but it works quite well when the people with all the business knowledge also knows a lot about databases and SQL but less about anything else. Obviously this involves a lot of data being passed around between stored procedures.

    This means that I've seen a few different ways to pass data around and I'm sad I didn't find this page earlier. Sommerskog's description of the pros and cons with different approaches would definitely have saved be some time. Over the years I've tried output parameters, cursors, tables, user defined functions and the table data type. And as usual the latest technology is not the best for all situations but may simplify things that was cumbersome to accomplish before.

    And some times the simplest solution is the most brilliant. A common problem I've faced is that I have one SP (stored procedure) returning some data as a select statement. Later on I want to reuse that SP in several other SPs. Previously I've been using functions or temporary tables to do this which both have their disadvantages, rewriting the original SP being one. But with the insert-exec pattern I can reuse the SP right away. I'm embarrassed I didn't think of that before. Let's say it is so obvious you don't think about it. In the same way you forget to look for your glasses on your nose. It's no silver bullet and it wouldn't have solved all my problems but it is yet another tool to use.

    So if you're working with databases you should definitely take a closer look at what Sommerskog is writing because knowing things like that will definitely make your life easier. And there is no point in learning it the hard way by your self.

  • Being Cellfish

    Books on agile


    Previously I've written about where to start when applying agile to your project. But not all people are happy with that since they want to read a book. Fair enough - I also started out reading books when agile cached my interest. So people I know tend to ask me what books I recommend to someone who wants o learn more. Typically they ask for a book on Scrum but that is not really what they want. They want a book to help them work better in their project.So this is my prioritized list on books to read when you want to learn more and implement agile into your project successfully. It is prioritized so if you only read one book, read the first one and then add more reading as you have time.

    1. Scrum and XP from the Trenches by Henrik Kniberg. This book gives you many practical tips and tricks that works. It is also downloadable for free making it an easy pick for me. You get a good all round book for free. Even if it cost as much as all other books on this list together it would still be first place.
    2. User Stories Applied by Mike Cohn. Writing good user stories will make things easier in your project. That's why you should read this book to get good depth knowledge on how to write those pesky user stories.
    3. Agile Estimating and Planning by Mike Cohn. Before Scrum and XP from the Trenches reached the first position in my list I used to recommend this book before the current number two. But since Kniberg discusses this in his book I feel that the user stories book gives you more bang per buck than this book, given that you've read Kniberg's book.
    4. Agile Project Management with Scrum by Ken Schwaber. This used to be my number one book on this list but even though this book gives you a lot of practical tips and tricks regarding Scrum, the current number one book is even more practical and also covers more things (like estimating/planning). Hence this book have been reduced to fourth place. It's still worth reading since it gives you a good solid Scrum education but only if you've already read the other books on this list.

    Of cause there are more books on certain topics like TDD but that is not the typical question I get. So I'll leave such books for a future list. Maybe.

Page 1 of 1 (6 items)