First of all I must remind you that I don't like mocks and mocks aren't stubs. But recently I read a very interesting story on code without getters and its consequences. The story is about a company where the developers where asked to develop their (OO) code without any getters. The brilliance of this simple, and at first glance weird constraint is that it forces the developers to design the code in a way that is generally considered "better" (i.e. don't ask objects for data, tell them what to do). It also introduces the need for mocks in a natural way. Actually mocks are not needed. A fake or stub object might work just as well.
Let's take a look at an example. If we look at my example from I don't like mocks where I want to transfer funds from one account to another. Without getters the code would have to look something like this:
If we use a mock object we can test that this code actually changes the account values correctly. But we still have the same maintainability and focus problems I discussed in the I don't like mocks post earlier. And you might as well use a stub or fake object. Actually the use of a stub and fake will force you to focus on testing the right things in your unit test because you have to test the account.remove and account.add methods by them selfs. And when you know they work you can fake/stub that unit completely and start testing that transaction.commit does the right thing given different behavior from the account objects.
You will probably never see an Xbox Fit because Microsoft would never get away with things like Nintendo does with the Wii Fit. You have maybe seen this comic before and if you don't own a Wii Fit you may just laugh at it. But there is a lot of truth in that comic. I know because I own a Wii Fit. Let me tell you what I've experienced...
Sometimes (about once every month) I get a question when I start Wii Fit: Have you noticed anything about X's body recently? "X" is the name of my wife who also uses the Wii Fit. And I have to choose one of four answers: "No change", "Gained weight", "Loosed weight", "Better posture". This is a loose-loose situation for me. Because if I answer "no change" or otherwise wrong I'll get a "maybe you're not paying attention to X". If I choose the "correct" response the Wii will tell me: "you should say that directly to X". So either way, regardless of my answer, the Wii Fit will make me feel guilty...
My wife get another kind of questions... I tend to use the Wii Fit pretty late in the evening and then play some games. When that happens it gets close to (if not passed) midnight before I turn the Wii off and go to bed. In the morning (around 6am) I get on my Wii Fit to get the daily weight. I do this in the morning because it kept telling me, doing the fitness test at different times each day makes them less accurate. So I do it in the morning. Somehow it checks my user profile and sees that I was up late so it pretends it's sleepy. And then my wife get messages like: "You should tell Y to sleep more". Y being my name.
Think about that for a moment... The game uses my profile to harass me and my family about my sleeping habits... The intention is good but isn't this an invasion of privacy? Now think what would happen if Microsoft released a product that tracked your habits and started to tell you (and your loved ones) that you should change... That's why I think we'll never see Xbox Fit.
Talking about the Wii. There are however a few other cool things you can do with the Wii that I'd love to see on the Xbox too...
Here is one example of what you can do with System Center Cross Platform Extensions. Just wanted to let you know...
Military combat is not the only military concept where software development can learn. One thing we used in my unit was "positive reporting". Positive reporting means that we should report in to our commander often and not only when things go wrong. This helps the commander knowing what's happening.
The positive report concept also includes adding suggestions on what can be done. This is important since the commander is typically not there and is not able to see all opportunities the terrain and situation offers.
Bad example: Hotel-Alpha at check-point 42.Good example: Hotel-Alpha at check-point 42. We have clear view of check-point 4711 and I think we can take it without support.
In software development we can benefit from using the concept of positive reporting. The first part, keeping the "commander" (product owner) updated can be done with daily scrums, burn-downs, task board etc. Things we typically do. The second part however is one thing many software developers don't do very well. Instead of just bringing problems to the surface, take a few moments and try to think of a way to solve the problem (as in combat acting is better than reacting). Even though the suggested solution may not be the best one, it will quickly get you back toward the goal. And the suggestion it self will trigger others to think of better ways to solve the problem.
Up until recently I was a platoon commander in the Swedish national guard. Since all peace time activities in the Swedish national guard are based on work done voluntarily I applied a number of agile principles when running the platoon. I used a task board to visualize all activities needed to plan future exercises. I had at least monthly meetings with all squad leaders to keep us all updated. At these meetings we also discussed how the platoon activities could be improved and planned for the next few weeks. So we definitely used the concepts of retrospects and task board. Not very militaristic but when working with volunteer weekend warriors I think it worked out pretty well.
The Swedish armed forces enforces mission type tactics. This leadership philosophy was used successfully by the Germans during the second world war and have since been used in most special forces units. The basic concept is that each commander gives his subordinates the mandate to solve a task given the best way they see fit. The commander must also make sure the subordinates have enough resources to complete any task given. This sounds very agile to me. Maybe not what you expect an organization that is extremely hierarchical.
This made me think that there are maybe more military situations where we can see typical agile properties. And maybe even we can learn from the military to improve how we develop software in an agile way. The first thing I thought of was combat. Military combat means chaos. Agile software development is a try to control the chaos of software development. When I look at how I have prepared my previous platoon for and then engaged in combat have a lot of resemblance with how agile development projects are (or should be) run.
Almost all projects start with some kind of planning and so does military combat. There is also a military saying: "No battle plan survives the first shot fired". So how do I create a good battle plan for a platoon? Well, the bottom line is to provide as much information as I can about the situation and what I want to happen but without being too detailed. The first thing to do is to gather the platoon. The best plan is one heard by everybody and not just the squad leaders since when squad leaders tell their squad some information may be lost or accidentally changed. Once the platoon is gathered I start with giving them information about what's known about the enemy and what's known about other friendly forces. I also tell them what the task of the company is and what's our platoon's task.
When the situation is known I tell the platoon what the goal is. If our task is to assault a hill, I tell them where our squads should end up when the assault is completed. This is very important since during combat it will sometimes be hard to get all the needed orders out to each squad. But since everybody knowns what the goal is everybody can work toward that goal without explicit orders.
After I have told the platoon what our goal is I give quick overview of how I plan to get to the goal. Still without being specific. If there are any situations I can predict I would also tell the platoon what these are and how we should handle them by default.
Example: If we're ambushed from the right. The default action is to suppress with engaged squads and outflank with Hotel-Alpha (Hotel-Alpha being the call-sign of one of the squads).
Now that everybody knows the big picture, our goal and my intentions on how to get there it is time for orders. Exactly how these orders look like obviously depend on the situation. But I have always tried to give an order for what the squad leader can see. And one prepared order. A prepared order is most often what I intend for the squad to do once the order is executed but it can also be a reaction to one of the predicted alternatives we have. Example: Hotel-Alpha, advance as last squad toward target. Be prepared to outflank.
The reason to give an order which only includes one thing that the squad leader can see and one (or maybe two) prepared order is that I want leave as little room as possible for misinterpretation and not force the squad leader to think to much about what comes next. Also if something happens and the orders must be changed my experience is that no orders but a clear goal is better than a lot of orders with a clear goal because people tend to stick to the orders if they still apply.
A little comparison: The goal is to advance to and cross a road and then assault a house. Think about these two alternatives (where everybody knows we are to assault the house):
The second alternative (B) is much easier to do right. Also we don't know what will happen at the road.
Also the order includes important information like where wounded soldiers should be transported, where we should retreat to if the enemy turns out to be too strong and where the platoon commander will be during the assault.
Finally every order is ended with me asking each squad leader and then the platoon if there are any questions. Questions are answered and then each squad commander is asked to repeat his orders. This way I know they know what to do. Even with simple orders you'll be surprised how much can be misunderstood. Especially if you start trying to give orders for several steps of the assault.
So, no battle plan survives the first shot fired. So what do we do to control the chaos of a combat? Information is important. Observations by individual soldiers are shouted and repeated by all others so everybody knows what's happening and can adapt to the evolving situation. The same applies to orders and information from the commander. Also the goal (given previously during the order phase) helps pushing everybody in the right direction. Another important thing to win a fire fight is keeping the initiative. It is always better to act then react. Doing something is better than doing nothing.
So now we've won the battle and achieved our goal. What do we do now? The first thing that typically happens is that the squad leader gathers information from the squad regarding ammunition and injuries. This information is transformed into a summary to the platoon commander indicating what resources are needed (if any) in order to proceed.
I'd like to compare a military assault with an iteration. Giving the team the overall goal as well as the iteration goal will help the developers make the right decisions during the iteration.
If we compare the military order with the user stories in the iteration I think we can still learn something from the military. We should only have user stories the team can understand immediately (i.e. "see") and we should keep the number of options (prepared orders) to a minimum. Also make sure that important information such as where the product owner will be during the iteration is available to the team from the beginning of the iteration.
In the day to day work ("combat") it is important that everybody knows what's happening. Especially when something important happens I think the team would benefit from adopting the military way of shouting out critical events and having everybody repeating them.
There is no way anybody in the team would miss something if everybody shouted stuff like that out.
When the iteration is over we should naturally have a retrospect but there is one thing we can learn from the military. That is how we present the result of the retrospect. If the suggested improvements from the team are presented in terms of "what we need to complete the next iteration" I think it is more likely to be taken seriously than if it's just "we want to do this since it will be better". Also it focuses on what's needed to improve the process now. Stuff that will improve the process later can also be handled later.
I recently had a chance to really sink my teeth into xUnit.net. Since I've been stuck with CPPUnit for quite some time and working with xUnit.net was a relief. Compared to NUnit I find xUnit much easier and convenient to work with (and compared with CPPUnit it's in a class of it own).
I feel I must give you four good reasons (no particular order) for why I prefer xUnit.net:
So earlier I suggested you to take a look at xUnit. Now I'm telling you. You won't be disappointed!
I recently described how you can create your own usleep method when there isn't one to use. one thing that people however tend to forget is that the sleep methods (sleep, usleep, nanosleep) only guarantees that the calling thread will be suspended for at least the given time. There is absolutely no guarantee that the thread will resume its execution immediately after that time. On most platforms you don't really see the difference but there are exceptions. HPUX for example, even on an otherwise almost idle system I typically experience a delay of a few milliseconds even though I sleep for only a single microsecond.
So if you want your thread to sleep for an exact amount of time you have use a different approach than sleep. Even if you use some sort of synchronize mechanism (an event) and a timer (to trigger the event) there is no guarantee that the blocked thread will execute immediately when the event is triggered. This approach is more likely to work as expected than the use of sleep, but it is not fool proof since you never know what other processes execute on the system affecting your process' execution.
The closest thing you can come to exact sleep times is also the ugliest solution. You can always have a busy loop checking if enough time has passed over and over again. This will however change the behavior of the sleep into a busy loop which is rarely a good solution to a problem.
Since only a minimum time can ever be guaranteed with a sleep method, regardless of implementation you should not write your code so that it depends on an exact sleep method. I think you're actually addressing the wrong problem if you try getting an exact sleep. Instead try figuring out why you need an exact sleep and remove that reason because you'll never be able to get it to work exactly right. Maybe good enough for now but you never know what will happen in the future so it's just a bad design choice.
I didn't have the opportunity to attend the recent Agile 2008 conference in Toronto but I attended a summary presentation a few weeks ago. These are the key points that excited me.
People typically feel bad when they fail at something. But if nobody knows you've failed you don't feel so bad. But if nobody knows you're hiding something and that is not good for your agile project. But what if you celebrated every failure? Then you wouldn't feel so bad about it. And a failure is really something you should celebrate because a failure revealed means you can learn from it and improve. And improvement is definitely something to celebrate.
This reminds me of a story Tobias Fors told. In order to make people understand that it is OK to throw an index card/post-it away he sometimes let everybody on the team write something on an index card. And then without revealing it to anybody they must tear it apart and throw it away. Apparently some people refuse... I guess that is related to fear of failure in some way...
Dan North a.k.a. the inventor of BDD had a session where he showed how you develop behavior driven with a regular unit test framework. I think this is extremely interesting since I have always been convinced that BDD is just another name for TDD done right. Exactly how this is done will have to be a future article.
When you think about an agile project a lot of people think of an iterative process. But there are an increasing group of people who start looking at methods where the agile principles are used but without iterations. Kanban boards is one way of doing this that I mentioned earlier. I think this is a very interesting development.
I was also introduced to a new way of prioritizing items that was both fun, fast and effective even in large groups. I don't know under what name this was first described but I like the name trading game that was used during the summary. This is how it works:
On windows you have a problem you typically never encounter on Unix. That is how to get a thread to sleep for less than one millisecond. On Unix you typically have a number of choices (sleep, usleep and nanosleep) to fit your needs. On windows however there is only Sleep with millisecond granularity. You can however use the select system call to create a microsecond sleep. On Unix this is pretty straight forward:
int usleep(long usec)
struct timeval tv;
tv.tv_sec = usec/1000000L;
tv.tv_usec = usec%1000000L;
return select(0, 0, 0, 0, &tv);
On windows however, the use of select forces you to include the winsock library which has to be initialized like this in your application:
WORD wVersionRequested = MAKEWORD(1,0);
And then the select won't allow you to be called without any socket so you have to do a little more to create a microsleep method:
int usleep(long usec)
struct timeval tv;
SOCKET s = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP);
tv.tv_sec = usec/1000000L;
tv.tv_usec = usec%1000000L;
return select(0, 0, 0, &dummy, &tv);
All these created usleep methods return zero when successful and non-zero for errors.
There seems to be a lot of myths around the interview procedure at Microsoft. I had my interview a little more than a year ago and coming from Sweden it was a big difference to have the interview in the US. The interview is (as described in the myths) basically two parts. First half is number of people asking you to solve a number of programming problems on a white board. Since I flew in the day before and was severely jet-lagged this was a tough start. If the first guys thinks you're good enough you'll spend the second half of the day talking to different managers. At least this is what happens when you're interviewed for a software engineering position.
Another nice thing is that you're pretty good prepared for the interview by the recruiter. And there is no dress code. Actually they stress that since it is a long day of several hard interviews you should come wearing something you feel comfortable in. They're hiring you for your brain, not for what you're wearing.
So what kind of problems do they make you solve? Personally I prepared going over this list but don't expect to get any of those questions. I did not get a single question on that list. I have also (inspired by that list) added a few personal favorites that I use whenever I have to interview somebody.
Actually there is not much more to be said about the interviewing process I think. You have to experience it to know what's it like. And it is different for every person. Microsoft really tries to give you a challenge during your interview (at least my division does). So one thing I can tell you is that you feel pretty pleased with your self once you pass and get an offer.
So why is this filed under relocate? Well, I thought this would be a good start on a series of stories about my experiences relocating from Sweden to the US...