Knowing to prioritize is a necessary skill.
when you open windows live update which claims to have 1 more
important update selected
and you see that the update name is
Games for Windows - Live V3.3
You kind of think that someone is missing something.
Posted in: Random Thoughts
i once wrote about the fact that there is no perfect and absolute design approach/strategy. To me design always depends upon the context of the system it is developed for and it should evolve along with the system.
Furthermore, I believe design decision should also be based on the context of the people involved i.e. the development team. Meaning that a good design for a given system in one team might not be appropriate for a different team working on the SAME system
To understand the previous statement, we need to first consider the main goal in software design. Not what makes good design but what we would expect a good design to do for us, or why is design important. For me a good system design is one that will minimize both the system maintenance cost and the cost of of developing new capabilities. And if we can agree on this definition I would assert that it is only natural that the people working on the system must be considered in any design decision. Some people find that a high level of abstraction easy to work with, but other people prefer a more procedural approach and find the same level of abstraction hard to understand. Even when I consider myself I know that during different phases of my professional life my taste about design have changed and what I found to work for me these days does not looks resemble what i found easy to understand a few years ago. (and only part of this can be attributed to better design capabilities)
When choosing a design always balance your decisions between your design capabilities and the need to apply good design principles. Sometime going one way because someone smart said it should be like this (even if that person is really smart) will not benefit you unless you understand why this is good.
At the end no matter where you will go you will need to evolve the design along with the product and along with the team applying and using that design.
Software craftsmanship is something that naturally speaks to me, so I couldn’t miss the chance to meet other people sharing the same passion. Today the first meeting of the Israeli Craftsmanship group arranged by Uri Lavy was held at the offices of PicScout.
the meeting itself was more of a get to know gathering an Uri gave a short summary of what does software craftsmanship, why is it important and what will be the focus of the group. All and all it was a very nice overview session which didn’t go very deep but held many promises for more to come.
The nice thing about it was the surprisingly large number of participants. The sitting space allocated by PicScout was completely filled and people spilled in all directions. It seems that future sessions will require more space.
Posted in: Craftsmanship
How do I start TDD? is a question I’ve been asked too many times. Unlike many I don’t believe that in order to start you need the entire team approval. In this series I’ve described a few situation one might find himself in and offered some ideas on how to approach them. Although each developer has its own context i hope you can find some resemblance in the described cases and find the ideas useful. Since this is what I’m doing for a living this days, I would love to hear about your way on the TDD road and specifically on how you started and what were the initial experience.
last in a previous post i was asked by Daniel the following:
So if a single developer on a team is driving the design of his code by TDD, do you really think it would work? The code is probably going to be different in design hence other will probably have problems reading it since it could be a bit of paradigm shift. Also, if the TDD-developer has a similar skill-level as the rest of the members, the implementation time of each future will probably be longer for his items, even if the total time including corrections after QA-people, do you really think things like this will go unnoticed?
Daniel, I don’t know if it will work for you, but i have seen it to work several times. The differences in designs does tend to invoke a design discussion, which i have found to be a good discussion in which testable design is always defendable,in fact I encourage this discussion since they are a tool for winning people over. regarding your second question, I think that a reasonable developer (in many scenarios) can make the overhead nearly unseen, and i would also expect that it wont take too long for that developer skills to rise over his fellows programmers. However, I’m a believer of honesty and visibility, I wouldn’t try to hide what I was doing from anyone, and when challenged I would answer that this is the way i know how to code and point to the low defect rate resulting from doing things this way.
if you are really lucky you will find yourself joining an team which already practice TDD:
You are just starting a new job (maybe in a new company). You have heard all about how the team is doing Agile (Scrum/XP) and how the tests are written before the code (TDD). In fact you are nervously waiting to start doing all those wonderful things.
Take a breath.
Joining such a team is not an easy switch. If this is your first time doing TDD (and Agile). It is going to be kind of a shock, working in an agile team is different in many aspects TDD is just one of them. It can take some time to make the needed adjustment. I myself have not fully experienced this, but helping other pass through the transition, I have learned that it can be a frustrating process, especially if you not a new developer.
The best way to speed the process is to make sure to pair a lot, i.e., Don’t work alone! Always ask to work along with somebody else on the team. Even if the team is not practicing pair programming on a usual base, insist that for your initial phases you would like to sit with others and learn how to do things properly. Pairing is a great way to get the needed knowledge and expertise (and the fastest way I know of).
With some luck, one day, the place you are working in will decide it want to fully adopt TDD. On that day you might find yourself in the following scenario:
The team/ manager have considered TDD, they chose to evaluate it and decided that its a good idea. the decision as made and in fact most of the team is quite happy with the change. However, since its a busy time they want to approach the subject with some care and have chosen you to start the ball rolling. that is you are expected to lead the transition for your team first by doing it yourself and then by helping the rest adopt the methodology.
The steps in this scenario are very similar to the one described in Part 4 the focus however is to gather as much real hands experience the fastest way possible.
Sometime this kind of experience can be bought. If possible, bring in an outside consultant that will help you in the transition. If not, try to to make sure the next hire has hands on experience.
if this options are not present, arrange for the whole team to attend some relevant gathering/conventions. Go with the team to TDD courses. and in any-case, when following the steps described in part 4 make sure to share and include other team members in the process. And last practice a lot of pair programming TDD session.
remember the idea is to share and include the rest of the teams even if they are not actively practicing TDD yet. A successful TDD adoption is much a matter of mode and spirit, not only a technical problem.
But always remember, The key factor is to gather as much hands on experience as possible and having the patience to build upon such expereince.
In a Place I’m working in, we needed to integrate the results from tests running in the C++ googleTest framework into the team build machine which is running CC.Net.
It appears that GoogleTest can output its result into a standard JUnit xml format, however I couldn’t locate a proper XSL that will transform the results into a nice report in the CC.Net Dashboard.
The following link points to the resulting xsl file that will create a nice looking report from googleTest output.
Hope this will save some time for somebody.
In some cases the idea of TDD is seen as a promising idea by the organization. lets consider the following
You talked with your manager and thinks TDD might be a very good idea. in fact he has given you a green light to evaluate the approach. most likely other team members are also in favor of checking this out all are waiting for your conclusions.
In this context the plan of action is very similar to the previous scenario. The difference here is that you are expected to do a more thorough job, and you are expected to show result in a given timeframe.
Therefore, you still need to pass the learning phase, you also need to setup a CI Server and pick out the tools before starting. Time boxing the learning phase will be a good idea, while you still need to gain the knowledge you would like to do it as fast as possible, so pick the training solution that work fastest for you (for many a TDD course does a decent job in a short timeframe). On the other side you would like to invest more time in comparing and evaluating several options for your tool set (which include the CI product). at the end you will be find it easier to justify your choices if you can show that alternatives were considered.
Next step, is picking out a good place to start the actual writing. Since you are evaluating the approach, you probably have the option of picking out where you want to start, and the idea is to pick (for the first experiments) a place that you feel comfortable working on. a Place which will not be too hard. Try locating a small, decoupled section that is logic oriented. At this stage don’t try to tackle the most difficult place, there will be time for that as well. First gain some hands on experience with TDD.
Like initial stages, you would like to time box this first effort. When you finish it don’t forget to share your finding (and your difficulties). sharing along the way will help you when you finish the evaluation and a decision will need to be made.
According to the time allocated, you might have a chance to tackle a “tougher” piece with unit tests. If you are working on a legacy system now will be a good idea to approach the issues such a system present. You will need to gain more knowledge on refactoring and reading Michael Feathers book is also a very good idea at this point. Going through legacy code is harder and takes time. The trick to success with TDD is to have plenty of patience, this will become evident when working on legacy code. Getting help is also a good idea. If possible try using other team members via pairing sessions. Paring on the harder challenges is a great experience by itself and will also make the time for resolving the issues shorter. As a side effect you also introduce TDD to other in your team.
at the end always remember that you have a specific goal, to understand why TDD will be good for you and your team. And to show how it can be adopted by the rest of the team. So don’t wait for the time to end always remember to reflect on what the experience has thought you what were the benefits and what are the challenges. during the evaluation communicate with the rest of the team and draw them into the discussion. at the end you will probably need their weight to make the organization commit to TDD.
In the previous post I’ve talked how a even in the most hostile environment one can do things that will help on the road for becoming a better programmer. fortunately however the scenario described in the previous post is quite rare and in most cases things are not as bad.
The following is probably a more reasonable scenario
You discussed TDD with your boss and while he is not against it, he doesn’t see enough value in it . Most likely his reaction went along the lines of:
Yes, automated unit tests are great but …
On the other side, you generally get enough freedom as long as you get the job done. other team members also think TDD an interesting concept, but again no one has yet made any move.
If you find yourself in this situation (which I believe is quite common), there’s much you can do. As always you start out by learning. Books, blogs, lectures, videos,.. anything will do. There is even a slight chance you can persuade your company to spend some money and sent you to an actual TDD course.
Next step is setting up of a Continuous Integration server. Yes, I’m serious. If you are going to practice TDD, you should have a full blown CI server at your disposal. Setting one up takes somewhere between 30 minutes to a few hours. The benefits are huge, and down the line it will definitely help you convince others (most managers just love the visibility given by a CI server)
BTW You don’t need a dedicated machine for this. If you can’t locate a spare machine (and any machine will do) just set it up on your own personal development station.
Next step will be to pick up the actual toolset for TDD. the most important thing about it is not to let this slow you done. While there are several options out there for every technology, for the most part the differences between the tools will have no affect at this point. Later on you might want to change the tools but even if that happens the actual cost of switching is usually minimal, and you will have much better understanding then. Just pick the tools you feel will be the fastest to learn. Don’t let the tools get in the way.
Now comes the fun part. Just start doing TDD. Pick up you next programming task and allocate some time for doing it the TDD way. If possible try to pick a standalone piece of code if not never mind. Don’t worry about doing mistakes. Don’t worry if your tests doesn’t seem like unit tests at all, and don’t worry if your are not following the TDD rules by the letter. You are just learning. And remember, in most cases it can take a couple of hours, maybe even half a day to write the first test. Things will become easier as you gather more practice.
Starting out TDD is hard. Without help it’s even harder. The fact that you are alone in your organization doing TDD doesn’t mean you shouldn’t have any. Reach out to the mailing lists. Luckily The web is filled with very nice people which likes to help. It might take some time but you will get the answers you need. The real trick for succeeding in TDD is just to have patience. It take some time to master a new skill.
Hopefully after a few weeks/months you will be able to demonstrate the real benefits of TDD. If you stick to doing it, you will overcome the initial issues and will prepare the ground for the team to follow. You will have real experience, and it will be much easier to convince others of the value in TDD.
But even if not, if you got to this point you already are a better programmer.
In my previous post I explained that you don’t need the entire team in order to start TDD. So lets see some options for the lone programmer.
The question of where to start depends upon the context you find yourself in. For example lets consider the following:
You are a team member (or a team lead), you tried running TDD through the team but they feel its stupid, in fact they are strongly against it. If that’s not enough your manager also think TDD is a total waste of time and is closely monitoring to make sure you are focusing on writing production code only. And the worst thing is that the organization is a strict one, no tool can be used without going through the proper channels.
Yes this is as worst as it can get and there is not much you can do (other then maybe start refreshing your CV). But still you can start with the learning parts. TDD takes some knowledge to do properly, its not enough to just decide and jump ahead. there are practices to follow tools to be learned and techniques to be adopted. I have never encountered an organization that will block a determined programmer from acquiring knowledge, even if that knowledge is not directly related to current work.
Here are some places when TDD knowledge can be gathered:
Books:
Mailing Lists:
Also there are numerous conventions and blogs dealing with TDD and other Agile Aspects. which deals with various aspects of agile development and some are even more specific to talking and helping with Conventions (and recording of)
It might also be a good idea to refresh on proper design principle and refactoring techniques as well. Even if you wont be able to practice TDD writing clean properly design code is always a good idea and i have yet to meet someone which object to that.
One of the most common question I encounter is how to start with TDD. Usually the questions is formed as how do I get my team to pick up TDD.
There are many answers to this, and in fact it really depends on the specific context (more on this later) but one thing I do know.
A popular mistake is to think that a lone developer can’t do TDD and you need entire team do it together. This contradict the fact that TDD is a solitary practice i.e. you can do it all by yourself. Think about it, don’t you write code alone? TDD is a development methodology, its an exercise in producing high quality code, in that aspect its not different then doing low level design or writing clean code.
Do you need the rest of your team to design properly in order to produce good design (of your parts)?
Naturally the effect a single developer has is limited and will probably won’t go beyond his code, however doing TDD even if done alone will allow for his code to be better (and most likely faster). Of course its better to have the entire team do TDD. It’s usually easier and will increase quality of the entire product, but there is no reason to wait for everyone to realize that, is there?
So where to we start?
like always the answer is, “It depends…"
but more on this later
Here is a nice trick to apply when using CollectionAssert.AreEquivalent of MSTest. While the signature of the method is:
(ICollection expected, ICollection actual)
When using them in your code switch between the actual and expected. Pass your execution result as the first argument, and you expected collection as the second. Doing this will give a better more informative error message in during failures.
Lets see an example,
I have a test which ends with this:
var actual = CrapAnalyzer.CreateCrapReport("", "");
var expected = new Dictionary<string, double>();
expected["MyClass.Method1"] = 1.34;
expected["MyClass.Method2"] = 1.22;
expected["MyClass.Method3"] = 5;
CollectionAssert.AreEquivalent
( expected as ICollection,
actual as ICollection );
When run as is I get the following:
CollectionAssert.AreEquivalent failed. The expected collection contains 1 occurrence(s) of <[MyClass.Method3, 5]>. The actual collection contains 0 occurrence(s).
when I switch between the collections i get:
CollectionAssert.AreEquivalent failed. The expected collection contains 1 occurrence(s) of <[MyClass.Method3, 1.12]>. The actual collection contains 0 occurrence(s).
While at first glance both see the same, the first one gives me no added information that is not written in the test code. The second error on the other hand, actually gives a good description on what happened. Reading it I can clearly see that the result value for Method3 was 1.12 instead of 5 expected by the test code. Now I know the actual difference and there’s a good chance that I can understand what went wrong without opening a debugger.
5/27/2010
Posts
