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.
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.
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.
There 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...
An upsert is an operation where rows in the database are updated if they exists and inserted if they don't. This has been available as a replace statement in MySQL for quite some time. At first glance the merge seems much more cumbersome to use than the replace, but don't be fooled by this. One problem I've had with the replace command is knowing exactly what rows will be updated and which will be added. Especially when updating things that are part of a multi-column primary key. The merge however is really more clear in what it actually does and you have full control of what you update and what you insert.
Version 1.0 of xUnit.net has been released. So do we need another unit test framework? And I think the answer is yes. There are a number of things that I've found a little bit weird in NUnit and with xUnit.net they have been removed. I definitely think that you should take a closer look at why xUnit.net was written and the comparison with other unit test frameworks. xUnit.net definitely feels like a new fresh wind in the TDD/BDD toolbox.
Fun to see more and more people say this. In a typical development project there are three variables to play with; you can deliver at a certain date, with a certain level of quality or a with a certain number of features. You can guarantee two of these but never all three. Pricing comes into the picture since pricing generally limits the number of hours that can be put into the project. So adding money may shorten the calendar time it takes to complete the project or it increases quality and/or the number of features that can be implemented. Fixed price often goes hand in hand with fixed date but it does not have to be that way. And trading off quality is a big no-no I think since it will backfire.
So the only thing the customer really has to play with is price or features. Either you pay for all you want or you cut the number of features. Think of it as choosing restaurant for lunch. If you really want a steak you have to pay for a steak, but if you only want to spend one dollar you're suck with a taco I guess...
Here's another article on the subject.
As many before me I was recently looking at different mocking frameworks in order to find one that suited my needs, and was written in C++. And there are not many alternatives out there if you're using C++. I've found one open source and two internal (Microsoft staff can access what can be described as an internal codeplex) ones. Pretty soon it turned out that none of these frameworks did what I wanted. Actually they suggested using no framework at all for the situations I was looking to "solve" with a framework.
At this point I rediscovered an old article by Martin Fowler and it became crystal clear that the reason I didn't find what I wanted in the mocking frameworks was because I really wanted a stub framework (or rather a stub helper). Because what I wanted was a simple way to reuse the algorithm "return 17 the first 7 times called and then throw an exception after that, unless called with argument 4711 in which case you should always return 42". A pretty simple method to write in your stub if you just subclass and override the object you want to mock/stub but a little bit cumbersome in the long run if you do this a lot.
During a discussion on a company internal mailing list for TDD it became clear that people generally use the term mock object for almost every kind of non-production object used during testing. And when another large group do make the distinction between mocks, stubs, fakes and dummies you quickly run into trouble since you are no longer discussing the same thing. So here is yet another recap on what the different kinds of objects are so I can contribute to the cause, making world a better place to be. At least when talking about mocks & friends.
An alternative title could have been "why unsponsored open source never work" but since sponsored open source sometimes don't work very well either, I didn't want to exclude sponsored open source from this post.
Over the years I've had to work with a number of open source projects. Both sponsored and unsponsored. With sponsored I mean a project where there is a company driving the development and making sure the project progresses and produce good results. An unsponsored project is when a number of volunteers drive the development of the project. I guess most open source projects are unsponsored as in there is no company making business decisions on what features to support.
And that is usually where everything goes wrong in my humble opinion. Because there are is no business involved the most advanced features and the most complex bugs almost never get fixed because if you're developing in your spare time you will concentrate on the fun stuff, not the boring obscure bugs someone has filed. And this is the experience I have from several projects (where wxWidgets and geeklog are is just two examples). A well documented and used-by-many open source projects usually covers about 99% of my needs. And I've often chosen the open source because it really adds value and is easy to use. But always, always there is this last percent it does not cover.
And this is when I run into trouble because the last percent of functionality I need, and that isn't in there, I discover quite late and there is no way I can defend the decision to change the decision so I'm stuck with what I got. And now I have to start working around the missing functionality or I have to rethink my solution so that I do not need that last percent of functionality. Neither option is very appealing to me since both include a lot of work and the reason for using the open source in the first place is to save me some time.
OK so now we all hopefully agree that almost all open source projects have missing functionality (or bugs) that you need fixed in order to continue working. So why don't I just fix the things I need in the open source and contribute it back to the open source community? Well first of all I have contributed fixes to various open source communities. I'm glad to do that whenever possible but most of the time I'm unable to do that. The reason I'm unable to contribute back is that it would take me more time to understand how the open source project works internally than it takes me to work around the problem. Remember that I typically use open source in order to reduce how much I have to work. So when I have to work around some missing functionality, I want to do it as quickly as possible. And most open source projects I've been in contact with have been pretty hard to get familiar with when I start looking at internal stuff of the project. A nice clean, well documented interface sometimes covers something that takes lots of time to understand.
Preemptive comment: So how much open source does Microsoft use internally? Well I don't know. Each use of open source in each project have to be cleared by lawyers and since that takes time I guess developers at Microsoft tend to not use open source very much.
In the last year or so, Scrum has become very popular and people are trying to apply it left and right. I don't know if it is Scrum but the number of projects that are trying to use agile methodology have exploded in the last one or two years. And there is a problem with this. Many projects that "start being agile" are not agile at all.
For example: imagine you're working on a project where you used to develop for 4 months and then test for 2 months and then prepare a release for one month. Your boss have heard that agile increases productivity and you start having 3 week iterations; 2 weeks of development, one week of test and prepare a release for one week. Instantly you see productivity drop 50%. And the reason is that you have just chopped up your regular work in smaller chunks and the productivity feels like it drops because you now do 3 weeks of work in 5 weeks.
The problem with agile is that you need to understand it fully before you can implement it correctly. And this applies to the large picture (Scrum, XP) and the small picture (TDD, Daily stand-ups) - if you do not understand the purpose, you will probably do it wrong. Agile methods like Scrum will act as an catalyst helping you understand what all the building blocks are but you will still need to understand the purpose in order to be successful.
Then we have another problem; Agile methods, especially when applied as a bundled concept like Scrum may not fit every organization. For example I heard that one company I've previously helped start using Scrum (and I think I was successful since more and more of their development teams are using Scrum even without my help) are now trying to apply Scrum to the marketing team. I'm sure their marketing team will have benefit from some of the parts suggested in Scrum but if they try to force all their work into a Scrum-like cycle I think they will need a really, really good coach to get it right.
Yet another problem with applying agile is that it will probably be a big change in how you work and I know many developers who don't like change. These developers will try to resist and see all the problems with the new methodology and you will be working upstream in order to get them aboard. And I think there is an easier way to do it.
So where do I start?
There are several books you can read in order to prepare your self and try to not fall into the same pits as everyone else before you. Think that will be a future post... I have come to the conclusion that applying agile in small steps are probably the easiest way to do it. If you're going to apply agile in tiny steps I think this is the way to do it:
Thats it... If you do those two things correctly you will successfully implement agile into your team. If you think my list is to short you can always look at this Scrum checklist. But what about iterations? I mentioned that you should have retrospects after each iteration but that is not on the list... Well iterations are not needed to have retrospects. Just have your retrospects at a regular interval and I suggest no more than four weeks apart in the beginning. The longer the period between the retrospects the more problems will the team see and the slower change will be because after each retrospect the process used by the team will improve. If you want really quick changes in the process you should have a retrospect each week. Also iterations gives you the power of closure which should not be forgotten but if I have to choose between iterations and daily stand-ups or retrospects - iterations come in last. Also there is no point in making the list any longer because the last item, respect retrospects will over time have you implement all other good things than are considered agile.
Finally I think there is one more thing you should do in order to quickly become successful with applying agile. Get a coach! Maybe that should be the only item on my list because everything else will come over time with help of a good coach. I did not put it on my two item list because I know many teams will not have the opportunity to hire a coach. But if your retrospective shows the team wants a coach - you should get one. If your organization does not allow you to hire an agile coach there are two other things you can do; Ask around on agile forums or get someone from outside the team come and listen to your daily stand-ups and retrospects. This person will look at the process from the outside and may in many cases come up with a few new ideas on how to improve that you have not yet thought about. This person from the outside may also say things that the team is afraid to say. This will also bring problems to the surface.
Preemptive comment: How does Microsoft do Agile? Well Microsoft Research have one report you can read. And I will also come back to this subject in later posts on this blog.