Importance of prioritization

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....

Read more »

Posted in: Random Thoughts

Design is contextual

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...

Read more »

Posted in: Agile Values,Design,Engineering Practices

Israel Craftsmanship – First meeting

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 spa...

Read more »

Posted in: Craftsmanship

Starting TDD – Conclusion

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...

Read more »

Posted in: Agile practices,Development Practices,TDD

Starting TDD (Part 6)

if you are really lucky you will find yourself joining an team which already practice TDD: New developer joining a team doing 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,...

Read more »

Posted in: Agile practices,Development Practices,TDD

Starting TDD (Part 5)

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: A lone developer in charge of implementing TDD 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...

Read more »

Posted in: Agile practices,Development Practices,TDD

Showing GoogleTests/JUnit Results in CC.Net

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. Instruct googletest (using the –gtest_output) to write its result into an xml. Update the ccnet.config file to merge the resulting file into the CC.Net build report. Put the supplied xsl into the webdashboard/xsl directory of the cc.net installation. Download the xsl from this link. Update dashboard.config...

Read more »

Posted in: CC.Net,GoogleTest,tools,Unit Tests

Starting TDD (Part 4)

In some cases the idea of TDD is seen as a promising idea by the organization. lets consider the following A Lone Developer in charge of evaluating TDD 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...

Read more »

Posted in: Agile practices,Development Practices,TDD

Starting TDD (Part 3)

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 A lone Developer in an indifferent organization 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. Start Learning If you find yourself...

Read more »

Posted in: Agile practices,Development Practices,TDD

Starting TDD (Part 2)

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: A lone programmer in a hostile organization 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...

Read more »

Posted in: Agile practices,Development Practices,TDD

Starting TDD (part 1)

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. You don’t need the entire team 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...

Read more »

Posted in: Agile practices,Development Practices,TDD

Using CollectionAssert of MSTest

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...

Read more »

Posted in: AUT,MSTest,TDD,tips