Archive for the ‘Quality’ Category

Software Craftmanship Conference 2009 report

Wednesday, March 4th, 2009

The SC2009 was one of these conferences where you would leave with more questions than answers. And it feels good! All in all, I felt humbled by the quality of the sessions as much as that of the participants. Evidently, everyone there was very pleased to be present and you could feel it in the bustling about and around!

The conference was hosted and catered in the BBC Worldwide buildings and as an architecture nerd, I have to say I loved the building and the interior decoration; it must be a fantastic place to work in, but it is hardly the point of this post, I simply digress.

First, you might want to head to Twitter / #sc2009 to have a look at how participants and speakers lived the event in real time.

Also, a broader coverage of all the blogs and reports for the conference will certainly pop-up on Jason Gorman’s blog (some day, when he will have got round to doing it). And more specifically, you’ll find a vox populis video of participants, including that of a guy who’s just realised he took a terrible accent in front of the camera ;-)

The complete program of the conference is available on the conference’s website and, gathering from participants to other session, the content was pretty interesting too; I wonder what kind of sessions were rejected by the selection committee.

Programming in the small

Some time ago, I had the opportunity to have a conversation around a pint with Ivan Moore and Mike Hill, where we were debating and mostly agreeing on how code should be formatted. Before that conversation, I felt like an alien insisting on a 400 characters line length in eclipse in place of the 80 characters that is the general, wrong, consensus.

This session was drawing from their own experience on formatting, writing and refactoring code, and how to challenge accepted “best practices” of code writing. It was very fun to refactor the bad code examples they provided!

Specification Workshops

This session was subtitled “The missing Link for ATDD & Example-Driven Development” and showed how you would come round to actually specify acceptance test cases using examples brainstorming: gather a lot of people that have knowledge in the business rules you want to specify and have them give examples of the rules. Discuss.

Definitely something I would try, but I’ll probably read Gojko Adzic’s book before to gain more insight on how to do it and not confuse it with iteration planning…

Responsibility-driven Design with Mock Objects

This session, however fun, didn’t quite cut it for me. First the facilitators started by “pitying” people who don’t do TDD; that could be a whole separate post in itself, but that kind of statement kinda makes me boil inside… and I am not even talking about all the Java/.Net snickering!

Plus, we did only scratch the surface of the purpose of the session, that is, learning about responsibility-driven design; we mocked objects alright, but we spent most of the time refactoring the code we had written…

However, I learned a lot from this session: they used Ruby as the supporting language for the demonstration… and I have to say I was rather impressed with a few things they did with it! Should I really, really, learn Ruby though?

Empirical Experiences of Refactoring in Open Source

In this session, Steve Counsel explained how he has analysed a few open-source projects to see how refactorings were applied throughout a project lifecycle. Although very interesting it was somewhat predictable: the most complex refactorings (e.g. remove duplication, extract superclass…) are less implemented than the simpler ones (e.g. rename variable, rename method…) by a factor of 10!

Thing is, even though this research stroke a chord with me as I am very keen on refactorings (even automated refactoring), it seemed like few conclusions were actually drawn from it; Steve did not tell us whether he had controlled for feature additions or development team turnover… furthermore, because the case studied were open source projects, I am not sure how much it would apply to corporate systems or commercial products. I guess I will have to find out!

Test-Driven Development of Asynchronous Systems

This session was possibly the most underwhelming one of the day; partly because it was the last one, mostly because it didn’t stimulate as much thoughts as the other ones.

Granted, Nat Pryce has implemented a very clever way of testing asynchronous processes during the integration tests (basically, having process probes that can tell whether the system has reached a stable position before executing test assertions)! I think if I ever face this issue, I would be very likely to use the same approach; or purchase a product that would do the trick! Wink-wink… :)

The take-home lesson learned

As I said before, I met a lot of very interesting people who care about software as much as I do, and the overall experience made me buzzing with thoughts.

But the one thing that I got out of it and that I will definitely be even more stringent about, from now on, is: refactor, refactor, refactor!

Sphere: Related Content

The case against Inversion of Control

Thursday, April 3rd, 2008

Inversion of Control is a refactoring that rose to fame with the implementations of the likes of Spring or PicoContainer. This is a quite misunderstood feature of software design (notably its implications), but a rather often used one - mainly through the use of the above cited frameworks. This article is an attempt at debunking the myth and presenting you with the hard, crude reality.

Not a pattern, more a refactoring

Of course, I would love to be able to antagonise refactorings and patterns, but it is not that simple and the separation between the two is easily crossed.

The refactoring we are using with IoC comes along the following scenario: we have a working system, but somehow we would like to reduce dependencies between some of its components; so we decide to refactor it and feed the dependencies to the components instead of having them explicitly request them. Under this light, I have to admit that I prefer the term Dependency Injection to Inversion of Control!

To realise this refactoring, we use the Builder pattern: a component knows how to built another component so that it works correctly without having to know how to build itself.

So, now we are on the same level about IoC, here is what is really bugging me with it.

Replaces compile-time validation with run-time errors

The main issue for me, is that you cannot verify your dependencies when you are actually coding. You need to run your application and deal with a hundred configuration errors before you can even start testing your feature.

Because all the wiring of your classes happen at runtime, you will not know until you are actually using a feature if it is correctly configured or not (with all its dependencies, ad infinitum). But this shouldn’t really scare you because you have tests for everything in your system, don’t you?

Introduces more indirection and delegation

To create an efficient IoC refactoring, you need to break down your dependency into an interface (depend on things less likely to change) and it’s implementation. That’s one level of indirection.

Now when you actually configure your dependency in you XML file, you don’t use actual objects, but names… text… that’s another level of indirection!

In order to manage all this indirection, your IoC container will use intermediary objects, proxies, to actually wire your classes together.

And that’s were it hurts a second time: when debugging, you have to traverse layers upon layers of classes and methods to understand where things go wrong! And don’t even get me started on actually trying to follow the path of a piece of code at development time!!

Hides dependencies but doesn’t reduce them

After all this meddling with your class’ instances, said class remains dependent on other objects but you have now lost aggregation dependency in the midst of the framework; that is, you don’t really know any more which dependencies the class needs to do its job (e.g. a data access objects) and which are just here for delegating (e.g. listeners).

Worse, if you follow the “best practices” enunciated in the documentation of your IoC container, it is very likely that you have now introduced dependencies to the framework in many places of your system: annotations? interceptors? direct use of the IoC’s object factory?

Refactoring, not central piece of architecture (bis repetita)

As a conclusion, I would like to insist that IoC should really be a refactoring for specific parts of your system and that you shouldn’t try to have everything dependency-injected, that’s bad for your system, and that’s bad for your sanity!

These days, you can be dubbed an Architect (notice the capital A, as before) very easily: just move every single instanciation into a IoC container and you get this very enterprisey architecture that’s as easy to maintain as it was before, with the addition of all the indirection… it makes you look good when new developers just stare blankly at your 2Mb XML configuration file.

Nota bene: I really have to thank Jason for motivating me to write up this post that I drafted earlier in January!

Sphere: Related Content

Depending on abstractions: a bad idea?

Tuesday, March 4th, 2008

I have seen my share of code where everything you are dealing with is an interface. And I have seen my share of bugs in this kind of code. While it is proven practice to depend on abstraction, this is also a source of many common mistakes.

nota bene: examples use the Java syntax, but as far as I know, the issue is the same in C#, C++… (name your mainstream language)

The culprit

Consider the following interface declaration:

	public interface Executable {

		public void init(Map config);

		public String execute();


Quite easy to understand, right? Any class implementing this interface can accept initialisation parameters with the init(Map) method and will be executed with the execute() method.

Wrong! This interface doesn’t tell you anything. Essentially, it would mean exactly the same if it was written as such:

	public interface XYZ {

		public void bbb(Map x);

		public String aaaa();


The problem with abstractions

The contract is fuzzy

The interfaces’ contract is really loose:

  • parameters are unspecified: nothing prepevents the user to pass null or strange values to methods; in our example, what is the type of objects in our Map parameter (it can help if we are using Java5+ - e.g. Map - but it would not be a panacea)?
  • return is unspecified: should we expect nulls? is there a domain for the values (X, Y or Z)?
  • call order is unspecified: when you are implementing the interface, what guarantees you that init() will be called before aaaa()?

You can’t test an abstraction

I hate to state the bloody obvious, but, unless you provide an implementation (be it a mock one), the best you can test with an interface is its existence in the system!

Your IDE can’t help you

When following code in your IDE, each time you encounter an interface, you have to guess what is the most likely implementation to be provided at that moment.If anything, you could still run your application in debug mode to find out, but you might not have that luxury… I know that feeling! :)

Dealing with it

The issue is very clear with interfaces, but it is exactly the same with abstract or overridden classes!

Of course, I wouldn’t give away the abstraction capabilities of an OO language just because that language has a poor contract management.

The only way of dealing with it for the moment is to make your code depending on interfaces completely foolproof: expect exceptions to be thrown, expect parameters not to accept nulls, expect return values to be null or completely out of your domain… and try to mitigate the risk that the method execution order might not be respected (when you are implementing an interface).

The way forward would be to implement a contract language for interfaces (OCL anyone?)… as a matter of fact I kind of see a way of doing it in Java. I need to put more thought into it though, any suggestion welcome!

Sphere: Related Content

I really care… do you?

Friday, September 28th, 2007

Do you care about software? Do you care about it being specified correctly, designed accordingly, developed qualitatively, maintained easily and that it gives the intended value to the business? Then take the pledge:

Analysts, developers, database administrators, stakeholders… you are all welcome to raise the profile of this campaign!

via - Be Part of the First 100

Sphere: Related Content

Automated Design Improvement

Friday, July 20th, 2007

Jason Gorman, again, inpired me for a new blog post. Some time ago, he offered an OO design challenge in which a design’s maintainability had to be improved upon without any knowledge of the underlying business case.
I quickly gathered that you could solely rely on metrics for determining quality level for a design and did a few trials myself (see below) to improve on the metrics[1].
Jason posted his own solution yesterday, and I suddenly remembered one of his earlier posts that suggested we should be able to automate this process. I detail such a solution further in this article and I give one possible (better?) solution to the design challenge.

Trying to find a methodology

My first attempt at making a better model was to try and see the patterns “through” the model. I moved a few classes around in ArgoUML, generated the Java classes and ran the Metrics plugin for Eclipse… alas, although the normalized distance from main sequence[1] was quite good (D=0.22), the relational cohesion (R=0.55) was worse than the reference model’s (R=0.83)!

First attempt at design challenge

In order to be able to improve models metrics with consistency, I had to devise a methodology.
I ordered the classes by their distance in the dependency graph: the more dependable, the better for maintainability. The dependency arcs are as follows:

B -> A -> C -> G
B -> A -> C
B -> A
B -> D
E -> D
E -> F
H -> D
H -> F

This prompted me to put the classes in four different packages like this:
Second attempt at design challenge
Not very different from my model created without applied methodology, but it has a great flaw: it has a cycle between p2 and p3! (and awful metrics too: D=0.40 and R=0.66)
Moving class A back to package p2 does break the cycle and improve the normalized distance, though only slightly (D=0.375).

Automating the search for a solution

At that point, I went to bed and left it running as a background thought until Jason posted his own solution to the challenge… the way he was proceeding with the refactorings reminded me of one of his earlier posts, though I can’t seem to be able to find it any more, that suggested we might be able to build a robot to perform random refactorings that would be kept if they improved the overall design of a system… if I couldn’t devise a method for solving this problem, I had better leave it to chance completely!

So I built a simple version of such a lucky robot with a very simple design, that would just pick classes from the reference model and, for each of them, decide randomly if it should create a new package or choose, still randomly, a package to put it in…
Once the model is fully built, it runs a few metrics and compare them to the reference model and, if it shows an improvement, keeps the generated model as reference model (otherwise discards it) and does another cycle.
And here is what it produced, after a few thousand cycles:

Third attempt at design challenge

It is definitely much more complex than any other model I could have come up with by hand, but it translates into nice metrics: D=0.1875 and R=1.0!

This leads me to believe that with a bit of work and time we could come up with a more advanced solution that would help designers get the best out of their design without risking to break everything…

You can download the rather crude source code if you wish to have a look at the application.

[1] see for a good explanation of a few software metrics metrics

Sphere: Related Content

The road to hell is paved with loose typing

Wednesday, June 13th, 2007

I am now (I just took a break to type this note) assessing the quality of a Java codebase using many methods, including actually trying to understand how everything is tied together. Well, it would be an euphemism to say it is convoluted .

The developers chose to have most methods accept as parameters (or return) objects, arrays of objects, 2 dimensions arrays of objects or a whole range of unspecified collections (Hashmaps, Treemaps, ArrayLists and Vectors without any consideration about their actual intended use), and they definitely didn’t use Java 5 generics!

Moreover, they can return collections containing collections of 1 element, arrays of objects where only the value at a specific index is populated or used, arrays of objects containing very different kinds of types (a String at index 0, an Object[] at index 1, null at index 2 and a String or Integer at index 3, depending on the size of the array at index 1…).

Worst of all, the Javadoc associated with the methods is either non-existent, wrong (cut and pasted from an other method), useless (the description is just the name of the parameter split into words) or completely unintelligible.

It is impossible that this code has ever been reviewed by any competent Java developer. I think the assessment I am running is actually turning into a code review.

Now I must find a way to quickly improve code quality and communicate it efficiently to the new developers team… any idea?

Sphere: Related Content

Quality can come at no price

Friday, May 25th, 2007

“Quality, Features, Time, pick two” is something you hear many times in teams on development projects. I am more a proponent of discussing only Time and Features with clients; but that’s only because I believe Quality can be achieved with a very low effort, following a few simple principles.

You might find that they sound like common sense sometimes but, by (recent) experience, I know there are many places where there is room for improvement!

Test, test, test and test!

OK, we’ve heard it many times from the Agile crowd, but however you do, test has to be done. Not one time, not two times, but all along the development. This is very documented and it really makes a difference:

  • screen usability tests[1]: even if you use just the hallway usability test, it will help making sure you are not going in the completely wrong direction with the UI; 80% of usability blunders can be picked-up in a day’s worth of usability testing and fixed on the fly.
  • automated code tests (unit tests and business cases)[2]: you really have to convince your developers that they can’t release code for which they don’t have automated tests. If it can be tested, it is better designed; if you have a test for a bug, the bug will never appear again (or at least you’ll know it).
  • user acceptance tests[3]: the customers have to be educated to come up with testable requirements; they will do the testing themselves!
  • load tests: if performance is likely to be an issue, test at least at the worst-case expected load level. It is better if the tests are automated.

All in all, it seems like a lot to do, but quick usability tests will avoid complete redesigns (1 day), automated code tests will keep you going free of regression bugs (cost of developing the tests balanced by the gains on regression bugs), UATs will make sure “everyone” understands the requirements (costs included in the requirements specification) and load tests uncover nasty surprises early on (a few days at worst, but gains on redesign at best)!

Choose good working environments

This looks like a pretty standard thought at first but if you try and assess what software people use in your organisation, you will certainly find out that many use programs that don’t fit their needs. And when I say needs, I mean features as well as usability. People will go to unbelievable lengths to have their program (most probably installed by default) do what they want them to.

For instance this doesn’t look good when your testers save emails and paste screen shots in Word documents in order to keep a track of bugs and tests. Have them use a bloody testing database and bug tracker!

Now imagine what you are going to impose to your developers when you chose a development platform. You have to have a pretty damn good reason to choose to have your logic coded at the database level (think PL/SQL) when you know for sure that it is probably the worst development environment possible (except maybe for APL :).

Tooling matters a great deal. It can make the difference between solving a bug in half a day and spending one week with fear gripping your bowels.

Choose your project’s tooling according to your staff skills and not according to some dubious trend. And if that involves implementing a good skills management strategy in your organisation, well, isn’t that what you should be doing anyway?

Check upon your experts

You can be confident about the quality of your software when you are confident in the experts. Those are the one you take your advice from and those you entrust with the development of your system.

Advice can be checked quite easily. You probably can get a good idea of an issue with a bit of googling… but you certainly can find someone in your network who has already gone through the same questions.

Work can be checked too. But it requires a bit more tact. However, if your DBA (OK I have something against databases today, but the point could be made with any one professional… think plumbers) consistently spends more time to do things properly than your good sense is telling you that he should, you might want to know if you can rely on him!

Do those checks regularly. Peer reviewing is probably the approach that yields the most effective results in terms of actually getting the answer you’re looking for, but it implies you have peers at hand that can be diverted from their actual jobs once and again. Also, your team might feel, rightly, that they are under scrutiny… and they might not like it.

The best way to do your checks is to have each member of your team explain what they are doing to the other members of the team. Have them show their code, their database configuration, their UI… peer review will occur naturally. And better, knowledge will trickle down through your team!

Surround yourself with good people

It’s a corollary to the previous one but also a summary for all of this article. If the people you are working with are dedicated to do their best at coding, optimising their environment, not talking BS, testing and developing their knowledge, there is a great chance they will produce good quality software!

Now all you have to do is actually build the system your customer wants!

[1]Register to Jakob Nielsen’s Alertbox and read one or two of his books for a first approach. Most web usability principles can be adapted with good results to rich client UIs.
[2]See JUnit or TestNG for Java, NUnit for .Net, but these principles can be adapted (and indeed found online) for any language.
[3]As a starter, read this article for customer-driven development and testing

Sphere: Related Content