Total Recall – or Lean goes to France (or actually Czechia)

I am a proud owner of a Peugeot 307; it’s a great little car. It looks good, is fun to drive, has a spacious and modern, well designed, interior, good sound proofing; yes pretty much what you look for in a car of this size. As an extra bonus you’ll also get a really close relationship with your local Peugeot service center; since you’ll be bringing in your car for big and small repairs repeatedly there’s plenty of bonding time. It also gives you the opportunity to try out new cars on a regular basis, when you get a courtesy car to drive during the time yours is being patched up. Small tip to fellow Peugeot owners: If you collect and save your recall notices instead of calling the garage to make reservation as soon as you receive them, you can batch the recalls and perhaps only have to visit your garage once a month or so.

Well, seriously, it is a nice car. But when recall notice number three arrives by mail in less than three years (not counting the numerous times you have to visit the garage to fix something that is broken without an official recall), you start to wonder. Not only is it annoying for the owner to go back and forth to the garage like a yo-yo, but also, this must start to get expensive for Peugeot, both with regard to actual service costs and damage to their reputation, which eventually could hurt sales. Anyway, it is quite obvious that quality is not Peugeot’s unique selling proposition.

Apparently Peugeot has reached this conclusion as well. When it was time for PSA to build a new assembly plant in Czechia, they decided to partner up with Toyota. And why would they want to do that? To tap into Toyotas boring design and lack of driving pleasure? No, probably not. Peugeot has a QA problem they need to address, and the way to do this is to build quality in from the beginning, as you will only have limited success trying to patch it on at a later stage. So they turn to the company that currently pretty much defines quality in the automotive industry for help. In the latest edition of the Peugeot customer newsletter, Peugeot New, there is a long feature on the new plant, and when interviewing the manager about the production system the reason for the joint venture is spelled out: “What you have to understand, when it comes to the production, computer and IT systems, it’s Toyota and ‘the Toyota way’ that is used.”

We’ll see how this turns out. Combining Toyota’s lean production system, credited for Toyota’s ability to consistently deliver the best built cars (and along with that a net profit of USD 11B last year), with Peugeot’s feeling for innovative design and character could work out. But I bet there are some corporate cultural differences that need to be solved along the way…

The first products coming out of the TPCA plant, the Citroën C1, Peugeot 107 and Toyota AYGO, are about to hit the showrooms. Time will tell if they deliver to expectations.

And then, as an instant reminder of the absence of the silver bullet, the latest large vehicle recall comes from no other than Toyota themselves. Recalling 160 000 of their environmental flag ship hybrid car, the Prius. You’ll never guess the source of the problem...

sventon

It’s here! The first official build of sventon, a Subversion web GUI application written in Java for browsing SVN repositories. It’s still to be regarded as a beta release that needs more work and testing. But this first release has most features expected from a tool like this, and a few extra unexpected ones. If you have a Subversion server repository you’d like to easily browse using a web browser, please try it out! All you need is Java 5 and a compliant servlet container, such as Tomcat 5.5.

One thing that really bothers us is reading long installation manuals with close to a billion steps that need to be completed in order to get software running, so we spent quite some time on making the installation as easy as possible. Please let us know whether we succeeded or not.

If you decide to give it a try, please give us feedback on your experiences and new feature requests through http://sventon.berlios.de.

Many thanks to Alexander Kitaev for providing the JavaSVN library that sventon relies on for Subversion interaction.

Do you, JAOO?

I am just about to leave for JAOO 2005, the premier European developer conference on software technology, methods and best practices. Last year was a great experience, and this year's schedule looks as promising, so I am very much looking forward to attending. If you are going, why don't you send me a note, prehaps we could meet over a beer or two!

/P

Blog This

Citerus is growing and so is our army of bloggers. Please visit the fine writings of Tobias Hill and Magnus Mickelsson.

/Patrik

It's Subversion time!

One of the most important tools in the developer’s toolbox has got to be the version control system, the VCS. This is where we store everything created during hard work on our development project’s journey from the first line of code to release and continued maintenance. The VCS forgives us if we accidentally delete the wrong file and lends a helping hand when it is time to fix that pesky bug that popped up out of nowhere in the deployed software. The VCS is one of the system developer’s closest buddies. If the system works, that is, otherwise it can be a pretty darn annoying enemy.

Surprisingly often when working at a client site I encounter a product that I guess most of you are familiar with, Visual SourceSafe – VSS. SourceSafe Pretty Much Does Not Perform as a version control tool. I really cannot understand why Microsoft put their name on it. There are probably about a billion blog lines of text written on the topic of SourceSafe’s failure to perform, so I will not bore you by adding more to that. But, if I got a Swedish Krona (or SEK for those of you who know your ISO 4217 currency codes) for each time I tracked down problems in source code related to the behavior that if a file is deleted from the repository by another developer SourceSafe fails to remove that file locally when a Get latest… operation is performed, I’d be rich. Or at least I’d have enough money for half a latte at CoffeCup in Stockholm’s main train station. But if you don’t like lattes, or just feel like you need more arguments against SourceSafe, try http://www.google.com/search?q=sourcesafe -site:microsoft.com (or, for the sake of irony, the new MSN Search: http://search.msn.com/results.aspx?q=sourcesafe –site:microsoft.com).

I can only speculate in why SourceSafe shows up time and time again; I guess availability could be a major reason since it comes bundled with development tools from Microsoft, also it is fairly easy to get started doing version control using SourceSafe if you’re running Windows. Rumors also say that there is a fair chance of successfully integrating SourceSafe with VisualStudio.

In the open source arena there is another ruler: CVS. Among open source developers CVS has been the favorite for a long time and the de facto standard for version control. I have used CVS from time to time and I think it is pretty good, but I certainly do understand that there might be people who find it a bit scary with its command line oriented heritage and semi perfect Windows support, although modern IDEs such as Eclipse and JetBrains’ IntelliJ IDEA have done their share to ease usage. CVS is far, far from SourceSafe’s dire state but still, it has been around for quite some time, and signs of aging are beginning to show. CVS has its share of less great solutions that could need an overhaul.

This is where Subversion comes in! Subversion is a new version control system, created from scratch, and available as opens source. The Subversion development project has been going on for some time, with the goal of building a compelling replacement for CVS in the open source community. Terminology and the ways of working have been kept from CVS to facilitate migration to Subversion, but at the same time many of the problems in CVS have been fixed. On the list of new sweet functions we’ll find atomic commits, complete version control of directories, support for moving and renaming files and directories, effective delta support for binary files, and more.

At the time this is written Subversion is available in version 1.2.0. I have only been running it with Windows, but binary packages are available for Solaris, Red Hat Linux, MacOS X, and more platforms. Subversion can be installed locally for version controlling files stored on the local hard drive or, perhaps more interesting, as a server allowing multiple participants in a project share files. Several options for server installation are available, one is to run Subversion with Apache HTTPD 2.0 and use HTTP/WebDAV as transport.

The selection of Subversion clients is considerable, with different feature sets, maturity and quality. One of the most mature clients available for Windows users is TortoiseSVN, a shell extension to Windows Explorer integrating Subversion in the Explorer file browser (if you’ve been using TortoiseCVS you know how this works). Several other clients are under development, one example is JetBrains that will deliver integrated Subversion support in next major release of IntelliJ IDEA. Scripts for converting existing CVS and SourceSafe repositories are available for download. The conversion process usually makes it possible to keep version history and user information from the original repository. Continuous integration tools such as CruiseControl already offer Subversion support. An Ant task is being developed, and the Ant exec task can also be used if you feel like automating your build process (which you of course do).

Subversion manages files using the copy-modify-merge paradigm, a CVS user should have no problem start using Subversion. If you’ve used SourceSafe with the multiple checkout option set, you’re in pretty good shape as well. If you on the other hand has used SourceSafe with its default behavior that employs exclusive file locking you may have a little initial challenge converting to the Subversion way of thinking and working. I started my version control journey on SourceSafe myself and initially had a very hard time comprehending how copy-modify-merge could ever work without creating total chaos. But it turns out it works very well as long as you work with files that can be merged (e.g. text files), and after a while it’s really hard imagine going back to the “old” way of doing things.

It has never been simpler and cheaper to get a powerful and modern version control system. Take good care of your code, stop using SourceSafe and have a closer look at Subversion. Yes, now.

• Subversion - http://subversion.tigris.org
  
• TortoiseSVN - http://tortoisesvn.tigris.org
  
• Version Control with Subversion (book) - http://svnbook.red-bean.com/
  
• VSS - http://msdn.microsoft.com/vstudio/previous/ssafe/
  
• CVS - https://www.cvshome.org/
  
  

Closing comments

This text was initially written in Swedish by me and edited by Tobias Fors for Citerus’ excellent newsletter on effective software development, PNEHM! When the article was pre-released internally at Citerus it sparked a bit of a discussion, a colleague of mine strongly claimed that it was wrong to argue that people should throw out their existing working VCS system in favor of a half done product such as Subversion. I don’t have a hard time agreeing with that statement as such, but I do believe that SourceSafe isn’t a working VCS system, and although Subversion may not have been around as long as CVS I definitely believe that it is good enough and it will continue to improve. The Subversion project has been self hosting for several years and in 1.0 release for over a year. I’d say that Subversion is starting to reach the early majority (but then again, who am I, Gartner?).

As for switching from CVS to Subversion I’m not so sure if it is time just yet, it depends on your situation. PushOK argues that Subversion is not ready to take CVS’ place, Holub on the other hand argues the opposit. As always, it is up to you to investigate the options more closely and make your choice. As long as you don’t let that choice be SourceSafe.

PNEHM! is published mostly with Swedish content and is available at http://pnehm.citerus.se/ Read it online and sign up to be notified when new articles are available.

/Patrik

Once more, with feeling

I was home, sick, the other day (yeah, happens to the best), and finally had the opportunity to watch the excellent U2 Elevation Tour DVD, filmed in Boston 2001.

Being an engineer I always carry around that somewhat silly urge of trying to figure out how things work; from that perspective the extra material on the DVD with all the "The making of" stuff is a mandatory view. In one clip of "the making of elevation live" you can see director Hamish Hamilton jumping up and down in the broadcast bus (or whatever it would be called in TV production speak) during the very start of the live take, screaming "I love my job! Come on! Come on!!!".

And, once again, it hit me, I mean, I love my work too, but, funny thing, so far it has really never managed to provoke that kind of reaction. No jumping. No screaming. Yeah, sure, now and then you stumble across a piece of code that is particularly great performing, elegant, self explanatory and simple. Yes, subtle excitement has been known to occur on occasion. But it is pretty far from the feeling you get when you see Bono entering a sold out arena.

Perhaps we can find a way of putting more feeling in there. Or perhaps in my next life I'll do something else, drummer perhaps. Yeah. Cool. But for now, time for some more CRUD.

But then again, to quote the singer himself: A singer is someone with a hole in his heart almost as big as the size of his ego. When you need 20,000 people screaming your name in order to feel good about your day, you know you're a singer. Bono: 2001 Harvard Commencement Address

/Patrik

The Reading

There are a few books that I bring to most of my software development projects. These are books that I mostly use as reference throughout the project, but many of them can also be read from cover to cover. They provide a level of comfort, much like friends that you can ask for advice. And just like friends may grow apart, books age or for other reasons reach a point where they don’t provide much value any longer, when this happens they are replaced by other books. To stretch the analogy just a bit too far, good books are also hard to come by, and aren’t easily replaced. OK, enough of this, here’s the current list:

Domain-Driven Design: Tackling Complexity in the Heart of Software
Eric Evans
This is an excellent book on domain driven design and on OO design in general. Now when the promise of transparent object relational persistence seems to finally start to deliver we’re able to design object oriented systems as they were meant to be designed: Object-Oriented. This book contains tons of ideas, tricks and patterns on how to create a powerful domain model to use when solving domain related problems and creating software for the domain. What else can I say: It’s great, go buy now!

http://www.domaindrivendesign.org/

Patterns of Enterprise Application Architecture
Martin Fowler
This book is divided into two parts; first a tutorial part on enterprise application architecture and then a catalog of patterns. Here you’ll find patterns such as Value Object, Service Layer, Domain Model and, the not all uncontroversial, Data Transfer Object. Examples are provided in Java and C# with diagrams in UML, and since it is not as technology centric as, say, J2EE Core Patterns, my guess is that it will age a little more gracefully.

Brief descriptions of all the patterns are available at http://www.martinfowler.com/eaaCatalog/

Fowler is currently working on Further Enterprise Application Architecture Patterns, they are published at http://martinfowler.com/eaaDev/

Design Patterns: Elements of Reusable Object-Oriented Software
Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
Yes, this is one of the classics that have been around for quite awhile and doesn’t need much of an introduction. Although one could wish for an updated edition with UML diagrams, and although Java and C# developers may find it easy to get lost in the Smalltalk example code it’s nevertheless a great book. The fact that this book still feels relevant after ten years is pretty cool in itself.

http://www.awprofessional.com/title/0201633612

Effective Java Programming Language Guide
Joshua Bloch
Before leaving Sun for Google Joshua Bloch made many important contributions to the Java language, including the Collections Framework. This book is crammed with great advice and design rules on OO programming in general and Java programming in particular. The discussion on why adding an aspect by extending an instantiable class will fail to preserve the equals contract (Item 3, Obey the General Contract When Overriding Equals) makes it worth its price alone. The book also works as an inspiration when designing you own APIs.

Now we’re only wishing for an update that will cover Java 1.5 (or Java 5 or Java2 version 5.0 or whatever it is called today).

http://java.sun.com/docs/books/effective/

UML Distilled
Martin Fowler
This is a thin UML reference with descriptions of the symbols, the different diagrams and their usage. It has pretty much all the info you need about UML and with one diagram type per chapter it’s an easy read whenever you need to brush up your UML skills.

http://www.martinfowler.com/books.html#uml

Software Configuration Management Patterns: Effective Teamwork, Practical Integration
Steve Berczuk with Brad Appleton
This is a patterns book on software configuration management. It’s a good read if you need to set up or adjust your configuration management process. Examples are provided for implementing the patterns with popular VCS tools, including Subversion, CVS, Perforce (and, if you must, Visual SourceSafe). Some patterns are also available online, such as Streamed Lines: Branching Patterns for Parallel Software Development.

http://www.scmpatterns.com/book/

SCM Patterns – Steve Berczuk, ISBN: 0201741172
UML Distilled – Martin Fowler, ISBN: 0321193687
Effective Java Programming – Joshua Bloch, ISBN: 0201310058
Design Patterns - Erich Gamma et al, ISBN: 0201633612
Patterns of Enterprise Application Architecture – Martin Fowler, ISBN: 0321127420
Domain Driven Design – Eric Evans, ISBN: 0321125215

Books with specific technology focus
If you are looking for books on a specific technology, I’d go this way:

EJB: Enterprise JavaBeans, Monson-Haefel et al, 059600530X
Servlets/JSP: Java Servlet Programming, Hunter et al, 0596000405
J2EE Architecture: Core J2EE Patterns: Best Practices and Design Strategies, Alur et al, 0131422464
Hibernate: Hibernate in Action, Bauer et al, 193239415X

Fiction
When you feel like reading something that is not related to work, why not check out one of my favorite fiction writers Ben Elton. Blast From the Past and High Society are good starting points.

Happy reading!

/Patrik

On Shipping Crap

You have to read this. You have to. http://www.butunclebob.com/ArticleS.UncleBob.TheNextBigThing

Now read it again.

What are you going to do about it?

Peace, out, till next time,
/Patrik

Learn a Language

The Pragmatic Programmers tell us to learn one new language (computer language, that is) a year. So, if you feel that you are falling behind, let me suggest:

Brainfuck, http://www.muppetlabs.com/~breadbox/bf/

and

ETA, http://www.miketaylor.org.uk/tech/eta/doc/manual.html

If you feel that two new languages are not enough (or perhaps just need something more, let's say, useful), there is always Ruby:

Ruby Brainfuck Interpreter http://www.stephensykes.com/bf.html

Ruby ETA Interpreter http://www.stephensykes.com/ruby.html

Peace, out, till next time,
/Patrik

A TDD Confession

A year or so ago I attended this, kind of dorky, presentation (or perhaps it was a workshop) on test driven development, TDD. Two guys were showing how to construct a class method by method by first writing tests for a method that did not exist yet and then add the actual implementation. It went something like this:

- OK, the requirement states that it should be possible to configure the component by supplying a size value when the component is created. Then there should also be a getSize() method that returns the current size. So we start off by writing a test for the getSize() method:

  Thing thing = new Thing(12);

  assertEquals(12, thing.getSize());

The test was run, it failed and the getSize() method was adjusted to make the test pass:

  public int getSize() {

    return 12;

  }

The test was extended:

  Thing thing = new Thing(22);

  assertEquals(22, thing.getSize());

The test was rerun. Guess what!? The test no longer passed! The code was now adjusted to make both tests pass. And this is pretty much how the presentation/workshop progressed; slowly more and more functionality was added by first writing stupid tests and then adding overly naïve implementations that would most surely have to be rewritten when the tests were extended. If I’m not mistaken, all this was in C#, to further incite my ignorance.

It was quite obvious to me that this was a waste of time; something I naturally found obligated to pass on to the guys giving the presentation. I also managed to come up with some other arguments against TDD:

• Ad hoc coding from a test point of view will result in bad API design.
• Slower development
• Tested, but messy code due to much focus on tests, and less focus on the actual implementation.

Instead of going for the obvious argument bait, one of the presenters challenged me: "I suggest you try it, really give it a try and see if it works for you".

FF a year. Now I’m sitting here writing a lot of my code TDD style (I’d love to say "all of my code in TDD stylee", but that simply would not be true, also I don’t feel I have enough street cred for the additional e).

So what the hell happened?

It actually was quite simple, my motto being “now and then it happens that I from time to time try everything once”, I did just that. And TDD still sucked. So I tried again, and again, and things started to turn. My fears were not realized, quite the opposite indeed.

The API design didn’t deteriorate, but rather improved. It is really hard to write tests if your API is bad, if your methods aren’t crisp and your classes have a lot of unnecessary coupling to other classes. Naturally, I knew all this before… but TDD made it somewhat clearer.

The development didn’t slow down. I already used to write unit tests before I tried TDD, but not until after the implementation was done, and doing it the other way around didn’t slow down development. In fact, modern IDEs have sophisticated functionality to help you very quickly create the tested class from the test class. Also, the code quality has improved; if you don’t write the implementation until after the test is written there simply will be no untested code (Well, at least in a perfect world scenario, as long as you implement nothing that is not fixing a broken test, but you get the idea). You can now prove that your code works, and will continue to work after refactorings and other code modifications have been performed.

Yes, it is true. When you work with TDD the code is tested, and sometimes it is also messy. But this is a great opportunity to exercise your refactoring skills, work the code, make it shine! This can be done in a safe manner now when you have your tests. Sweet! If you take your time to do this, the code has the potential to look better than ever.

Find a good balance between writing code and tests. You don’t want to write too large chunks at a time so that you code functionality that has no corresponding tests, but on the other hand you might want to stay away from the over simplistic approach described at the beginning of this text. You will have to find your own pace and scope, a test coverage tool can come in handy here, it will tell you if you slip and start to write code that have no corresponding tests.

TDD works especially well if you work with an architecture based on a plain object domain model, adding new functionality to your domain classes will be a piece of cake from now on. Also, a good IDE with excellent refactoring support, such as IntelliJ IDEA or Eclipse, is more or less necessary. Actions such as "implement method" and "introduce variable" make the TDD developer’s life so much easier. If your IDE is lacking in this department, you’re missing out on much of the fun (go ask your manager for an upgrade now)!

The workshop presenters were unfortunate enough to have me in the audience, but to repair some of the damage I’ll pass forward the TDD challenge: Try it, you might even like it.

Peace, out, till next time,
/Patrik

For coverage tools, Try EMMA, or Clover.