Tuesday, December 30, 2008

Retesting software modules

How do you test a piece of software or module that came for retesting, meaning you found some bugs, submitted them to developers that fixed them and sent the module back for retesting?

I think that, whether roles such as QA experts are more or less defined in the team, the person who found the bugs should accurately check the software, as she's the one with more experience on the history of the bugs. It would also be useful to hand the software to another tester, which could look at it with a different perspective and identify more and/or better tests.

The important thing is that tests should be repeatable, better yet automated where possible, otherwise it would be very difficult to positively assert that the bug has been fixed.

Wednesday, December 17, 2008

A parallel between software and people

Recently I witnessed the umpteenth dysfunctional behaviour between developers and systems engineer (nothing new below the sun). The subject of the debate was the backup of several customers' databases used by a software application built by developers, and each group was repeatedly passing the buck to the other one; systems engineers said "you built the application, you perform and collect backups", developers said "you are in charge for all backups, these should not be treated differently". Obviously the hidden agenda was trying to avoid a task nobody likes. It was all worsened by the fact that Xmas holidays and consequent vacancies are approaching, and several people will be home playing the couch potato.

And who was wrong? And who was right? It didn't matter in the thick of the fight...

I think that the right approach is "hey we're in all this together, let's talk and get a solution out of it", but sometimes a long history of untrust and urban guerrilla warfare can be hard to overcome.

Anyway, as a game, let's see if some software development principles and patterns can also apply to people :-)
  • Rigor and formality: formality is a plus (sometimes it can be a burden), but rigor must always be present.
  • Separation of concerns: complex systems are difficult to analyze, and it is very difficult to manage the process that leads to deliver. To overcome this point we try to separately manage unrelated issues. This is why we have developers AND systems engineers...
  • Modularity: it is a specialization of the former
  • Abstraction: complexity worsen the capability to build models that are effective for resolving the problem, thus we abstract from details that are not relevant to the goal. Is it important to know where databases to be backupped come from?
  • Anticipation of change: YAGNI :-)
  • Generality and Incrementality: following the Abstraction principle, we abstract and do not consider them now
Do you have an opinion you'd like to share?

Tuesday, December 16, 2008

Every build you break...


Roy Osherove singing in Barcelona, TechEd 07. Pity for the slightly too long introduction.

Monday, December 15, 2008

Words of wisdom from Master Oogway

One often meets his destiny on the road he takes to avoid it.

A very quick demo on Hudson

Uncle Bob has published a very quick demo in which he uses Hudson right out of the box as a stand alone process (no servlet container required).

Thursday, December 11, 2008

Agile and procedural

Today I partecipated in a discussion started by Dennis Morton who asked if anyone had succesfully adopted Scrum, XP or RUP on non-OO procedural based applications. A little rephrased, these are my thoughts.

Scrum is relatively easy. Implementing Scrum could not be that easy because you have to face several impediments: one of the biggest ones is that it clashes with the existing culture, but that does not depend on the particular language you use.

As Keith and Charlie pointed out, life is easier for OO programmers, as there's plenty of relatively inexpensive tools and technologies (if not inexpensive at all) that can help them: Junit, Cobertura, JMock, EasyMock, Hudson, CruiseControl, Eclipse, NetBeans, and so on and so forth in a sparse order, just to talk about Java.

I don't know of similar tools to be used in RPGLE ("inexpensive" and "IBM" cannot share the same sentence) but that might just be my ignorance, so it is up to the team to find a suitable solution (that could also be an expensive but affordable tool).

Anyway, I have to point out that Scrum is just (?) a very good set of techniques for project management, but it is not enough, as you must have in place the proper engineering practices to benefit from the advantages that Scrum offers.

It is useless to give a product owner the possibility to steer the project at every sprint planning meeting if a simple change requires tons of programming hours, as she always has to weight benefits against cost. You can be agile because you have test harnesses supporting your changes. You can be agile because you continuously refactor. You can be agile because all the team members own all the code. You can NOT be agile just because you use Scrum, as you're just exposing problems - problems that most of the times existed well before Scrum was implemented, so don't shoot the messenger. You also have to master the tools to resolve problems. And the first and most important tool is people, so I'm completely with Keith and Charlie who put them in the heart of the process.

We have to undergo a similar challenge as we'll embark on a very big project next year, almost completely based on IBM technologies. As we're starting from about 650 pages of detailed requirements, aged about one year, a remote customer, a distributed team with several new members (not to mention the rest), we'll surely have to cope with changing requirements (no, not the band in which Craig Larman plays in his free time) and lots of other variables and issues.

It is likely we'll have some answers within the next few months; up to now, as it is well understood that we'll have an application layer exposing services, the only thing that I could think of is the use JMeter as an acceptance testing tool. As always, inspect and adapt, rinse and repeat :-)

We're open to suggestions!

Wednesday, December 10, 2008

Dexter Jackson Mister O

I know it happened a couple of months ago, but I only saw the competition the other day... Dexter Jackson is the new Mister Olympia!


By the way... the commentators reported rumors about the great Ronnie Coleman joining back in the 2009 competition... I still haven't swallowed his 2006 defeat to Jay Cutler, and last year he suffered from too many injuries... shall we have him back on the top of the Olympus?

Snow, rain and commuting

I really don't know why slanderer have to say that some snow and rain can cause big traffic jams in Milano... today's commuting (less than 30 km) only took me 4 hours and 20 minutes...

Measure with JMeter

Apache JMeter is a subproject of the Apache Jakarta Project that can be used to measure performance on static and dynamic resources such as files, Servlets, Web Services and many more. Moreover, you can also use it as an automated testing environment, as you can easily compare actual results with expected ones using assertions.

Using JMeter is really straightforward and the manual is quite good; just remember to copy mail.jar and activation.jar in the lib dir (as an alternative you can always set the user.classpath property in jmeter.properties) if you want to test Web Services.


The picture shows a graphical example, but it is also possible to view the results in summarized reports, aggregated reports and so on.

We used it to simulate a heavy load on an i5 exposing a Web Service realized as a proof of concept, and drew a comparison with a similar service realized some years ago. We were quite satisfied with the results, as the average response time under stressing conditions has dropped by about 40%.

Wednesday, December 3, 2008

Enough with mobiles!

I am not against technology. I think technology has really improved our life. Internet has opened a whole new universe to a lot of people. Mobile phones and PDAs let you connect with everyone you need almost wherever you are, should you need it. But... do you really need it?

Technology should be an aid, and it should not generate addiction. It looks like people can't help talking on their mobiles, no matter where they are. Even when I got married one of our guests forgot to turn his mobile off. Some years ago, when wireless earphones came out, you could easily spot many (supposed to be) crazy guys passionately talking to themselves, waving and bustling about.

There was only a place where people dared to bear the burden of silence, possibily reading a book, and that was the subway (and only because mobiles didn't work down there). Now this last rampart has fallen.

I think that there's a reason if in some African regions "progress" is translated as "dream of the white man".

Tuesday, December 2, 2008

Collective Code Ownership Part 2

When I write "everyone is responsible for all the code" I also mean that everyone is responsible for all the tests, so if you only have unit tests and you need an integration test... write it! It does not matter if you didn't write the original code or the original unit tests, it does not matter even if you didn't talk to the original developer. It is your responsibility to write it: navigating through an application just to click a link is (almost) completely pointless, and it sure is a waste of time. That does not mean that end user testing must not take place (how could you assert that "a normal user should be able to foobar the barfoo without previous training" otherwise?), but we should strive to automate as much as possible.

This is even harder to assimilate, because not only you have to touch code written by others, but (heresy!) write tests for code you didn't write. It's already hard to persuade people of how much TDD pays off the initial investment and the mental shift, but it's even harder to push them to use tests as a primary way to discover how a particular piece of code works (I often write tests for third part libraries or also for checking the behaviour of java.lang or java.util classes I'm not sure about). I can understand that people fear changes, and that one could be unwilling to change the way he's always worked, but here we're talking about being afraid of one's own shadow. Try it, and try it seriously, and after you did if you still think it won't work (and you won't) you'll still be able to give it up. And... no, "I have no time" is not a valid answer, because not having tests only leads to wasting more time.

Alas, too often I perfectly agree with Gabriele...

Monday, December 1, 2008

Collective Code Ownership

To quote from Wikipedia:

Collective code ownership means that everyone is responsible for all the code; this, in turn, means that everybody is allowed to change any part of the code.

That also means that everyone has to change any part of the code when it is required. Developers cannot shield themselvs behind a "he did it". Even if you didn't partecipate in the writing, the code should be clear enough to allow you to understand it and change it confidently.

By giving every programmer the right to change the code, there is risk of errors being introduced by programmers who think they know what they are doing, but do not foresee certain dependencies. Sufficiently well defined unit tests address this problem: if unforeseen dependencies create errors, then when unit tests are run, they will show failures.

That's true, but... who controls the controller? Just today, after other colleagues were trying to integrate two systems without writing tests (boo!) we wrote a (supposed to be) failing unit test and... it didn't break as it should, as we were testing for equality objects that we clearly knew were different. That was because we forgot to change the equals and hash code methods after adding an attribute to the result class of which our tested method returned an instance, and we didn't have a test on equality on the result class because all the code was generated by the IDE. Nevertheless having a bunch of tests sped the process of finding and fixing the error: if we didn't write a failing test before proceeding we would have spent a lot of time before we managed to find our (not too subtle) bug - time our colleagues actually did spend.

So... always write your tests! That's another supporting example for the "we tried baseball and it didn't work" post: Collective Code Ownership also works because of other practices, such as coding standards, pair programming and unit testing. I'm still convinced of what I wrote, but I certainly agree on the fact that you cannot simply pick random XP practices and hope everything will go well.