RSS
Facebook
Twitter

Thursday, May 27, 2010

The Israeli software craftsmanship group is on its way

As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:

Not only working software, but also well-crafted software

Not only responding to change, but also steadily adding value

Not only individuals and interactions, but also a community of professionals

Not only customer collaboration, but also productive partnerships

That is, in pursuit of the items on the left we have found the items on the right to be indispensable.

 

From the Manifesto for Software Craftsmanship

 

IMAG0398

Today I was in the very first meeting of the software craftsmanship in Israel group, and it was a very good start.

We had a great turnout - I estimate that than 50 eager software developers came.  The organizer Uri Lavi presented the idea of software craftsmanship, it’s roots in Agile practices and explained about the various methodologies and practices that makes a professional software developer.

At the end of the session a prime number code kata was shown – go watch it now if you want to see a good example of how TDD should be done.תמונה047

 

Join the Software Craftsmanship in Israel LinkedIn group to discuss software craftsmanship and get notification on upcoming sessions.

 

Related Links:

Tuesday, May 25, 2010

Who’s afraid of C++

C++ is the 2nd programming language I’ve learned (C was the 1st) back in object oriented course and I’ve been using it ever since. From my first job where I’ve wrote code using Vim and XEmacs (for Linux - I’m not that old) to my current job where I’m using Visual Studio 2010 I’ve never stopped using C++.

I know most of its tricks and I occasionally use some its “black magic” and I enjoy seeing the code I worked so hard on doing what I need it to do.

Since .NET 1.1 came out back in 2003 I’ve been a .NET addict. I’ve enjoyed seeing how the .NET world progressed and changed over the last 10 years and I’m proud to be one of the passengers in this amazing ride.

Luckily for me I got to enjoy both worlds – excluding my first job every project I worked on I’ve used both C++ and C#.

I wrote a graphic engine using C++ and used C# and winforms for the application's  UI, I’ve used Managed C++ to expose an old C++ legacy application using web services written in C#, I’ve written code in both C++ and C# to harness the profiler API to do my bidding. And I always thought I don’t have a clear preference between the two – they are merely programming languages designed so I can write software that does what I want.

But it’s not true, every single project I did on my own free time I’ve used .NET. Because I seem to get results faster using managed code and I don’t have to mess with many compilation and linking errors.

And the tools – although C++ has it’s share of productivity tools it cannot compete with the sheer amount of tools that are available for the .NET developer. Although us C++ developer did get some much deserved support in the new Visual Studio but it still takes much more time to develop application than with C#.

And it’s more than that - at work we try to keep a clean and well structured code but I’ve noticed that there is a big difference between our clean C# code base to the messy bordering spaghetti C++ code. One the reasons is that we use Resharper for refactoring our .NET code while we still haven't found a similar tool for C++. The simplest refactoring such as a method name change need to be done at least in two places (remember header files) and can cause very interesting compilation issues that would take some time to solve – so developers tend to avoid them.

The same developer who would make sure that each class is stored in a different file in C# would put five classes in the same header file to avoid unnecessary conflicts during build.

I’m not sure if this lack of discipline is caused because it’s harder to write clean code in C++, the lack of tools, or fear…

 

What I do know is that writing C++ requires much more energy and I guess that’s why I enjoy it so much – it’s much more fulfilling achieving something hard than something trivial.



Monday, May 24, 2010

Docx 2 UnitTest – an interesting tool for VS2010

Last week I got a chance to check out a new unit testing related tool called Docx 2 unitTest.

When I first saw it I remembered a previous job where I needed to produce a lot of documents along with my code. It was such a hassle that one of my fellow developers planed to create an application that will automatically generate word documents from the source code so that she won’t need to update them every single day. D2UT does the opposite – it generates (part of) unit tests from a document. So if you feel more comfortable writing documents than writing code (marketing/PM folk – I mean you) or if you need to maintain ordered documents of your test plan (QA) you want to check out Docx2UnitTest.

What it does

After installing the extension all you need to do is create a simple word (2007/2010) document that looks something like this:

image

Now all you need to do is add the Docx to your project and presto – your tests are automatically created, or at least the test names:

image

It also creates “tests” for XUnit and MSTest as well.

This tool look like a few “BDD” related tools that enable product managers and marketing folks explain to them developers what they should be doing. It is also a good way to store your test plan/requirements in document form.

The cool thing about this tool is that it uses ms-word which anybody who ever picked a keyboard should have used at least once which means that you do not need to learn how to use a new application just to specify tests.

 

My only biff is that I’ve needed to add the required project references (NUnit/MSTest/XUnit) by hand – which seemed like a bit of a hassle but other than that this looks like a good start on the right way.

 

Right now D2UT doesn’t do much but what it does it does well, and it’s a good example of what can be achieved using the new Visual studio extensibility model.

DotNetKicks Image

Thursday, May 13, 2010

Why TDD is good for testers

A while back during a presentation on unit tests a member of the audience asked me a question I hope never to answer ever again - “So these unit tests you’re talking about, are they written by developers?”

The reason I don’t particularly care for that question is that developers think that unit tests (and tests in general) are a part of the tester’s work (hence the name). Just because TDD (Test Driven Development) has the word test in it doesn’t mean it is a form of testing, in fact is a development methodology which means that it should be practiced by developers to create code.

It’s not that unit tests cannot be written by testers, in fact I’ve worked on a project where some of the unit tests were written by the QA team with very limited success - because the QA team didn’t know the code I wrote as good as it was difficult to produce good unit tests.

So why should testers care about unit tests? Some think that tester’s role will become obsolete if we’ll write enough automatic tests, both unit tests and integration/acceptance tests – I say that’s just wrong. Even if an application can be 100% tested using automatic tests there is no way in hell that the developer that wrote the code will be able to come up with all of the scenarios in which his code can fail. Us developer are too attached to our code, and testing our application for flaws is almost impossible emotionally.

 

So the tester’s job is safe. But should he care about what the crazy dev guys are up to? absolutely!

Because when a developer take the time to unit test his code it means that the tester receives a better product to test.

I cringe when I remember what a crappy code I used to ship to QA – some of it was so low quality that it didn’t even run. Nowadays this doesn’t happen, I do get a bug reported from time to time but it’s usually not a “stupid bug” because I made sure that my code worked before it left my machine.

Unit tests proved that my code can run and do most of what it suppose to do so that the tester can concentrate in finding bugs instead of checking that that my code passes basic sanity.

 

So if you’re a tester get the dev team to TDD so you’ll be able to do real work instead babysit code the developer was too lazy to run even once…

 

Related Link:

Introduction to Mock objects session coming up

New to unit testing? Heard about mocks/stubs/fakes and want to know what it’s all about?

You’re in luck because I’ll be talking about mock objects from the ground up. It’s going to be an online session so everybody’s invited!

 

Check out vconf site for more details.

Wednesday, May 05, 2010

Four ways to do pair programming

After we’ve covered the typed of developers I pair programmed with I want to explain how pair programming can be done – based only on my observations:

Turn based

The idea is very simple – you change places, after a predetermined interval. Whoever wrote code (driver) becomes the one who reviews the code (passenger) and vise versa. You could switch places each time you finish a feature or every 30 seconds it’s up to you. The important thing is that you do switch roles according to some event you both agree on.

Obviously using this method keeps both developers interested in the code and should help avoiding the situation where only one developer write the code while the other slowly falls asleep.

Tester – Coder

This is one of my favorites, when writing test first design (TDD) one developer’s objective is to write a test that fails, the second developer need to make that test pass by writing the minimum required code. You can switch roles every now and then so that both of you get to write the feature (and tests).

This is also a good way to teach test driven development to your team - by example.

cute penguin couple - explored by Adam Foster | Codefor.King of the hill

However grabs the keyboard first writes the code. If he stops or slows the other developer can grab the keyboard (trying not to cause any serious harm to his fellow coder) and continue from there. Oddly enough I’ve seen some pairs where this method actually worked.

Just remember to make sure that both of you feel conferrable working this way otherwise you might offend your co-worker.

One mind – four hands

This method is quite rare, in fact I’ve only seen this kind of synergy a couple of times in the past. Both developers think so similarly that they instantly understand each other’s code without any need to talk or explain what was just done.

One developer writes code while the other reviews it and when one of them tires of his/hers current role they switch roles without more than a node of the head.

The problem is that it can only work if both of you think the same way, meaning you might still make mistakes you can make on your own.

 

This ends my short observations of the elusive practice of pair programming (at least for now).

I’m sure there are a lot of other ways of doing pair programming – so please enlighten me and tell me know how do you do it?



Related Posts Plugin for WordPress, Blogger...