Software craftsman, author of Software Craftsmanship: Professionalism Pragmatism Pride ( and founder of the London Software Craftsmanship Community (LSCC). Sandro started coding at a very young age but just started his professional career years later, in 1996. He has worked for startups, software houses, product companies and a few international consultancy companies. Having worked as a consultant for the majority of his career, he had the opportunity to work in a good variety of projects, different languages, technologies and industries. Currently he is a director and a software craftsman at UBS Investment Bank, where he writes code, look after the quality of the applications, mentor developers and help teams around the world to get better at delivering quality software. Sandro is a DZone MVB and is not an employee of DZone and has posted 34 posts at DZone. You can read more from them at their website. View Full User Profile

Open-source developers deserve respect

  • submit to reddit

I was recently reading Gojko Adzic's blog post called How is it even possible for code to be this bad? I must admit that I was very sad to see tremendous lack of respect towards the Hudson/Jenkins community and towards open source software developers in general.

Firstly I would like to say that any person out there that is working on an open source project deserves a lot of respect, mainly the ones working on projects that bring so many benefits to so many companies and developers around the world. The velocity that our industry moves forward and evolves is, in general, because of many open source initiatives. It's because of thousands of developers that work on the their spare time, for free, to create software that will make the lives of many other developers, companies and users much easier. These people are kind enough to offer their work to all of us and are humble enough to ask and accept help from many other developers around the globe.

One thing we need to understand is that every project has a history and many things, throughout the lifespan of a project, can be responsible for the success or failure of a project. It's always easier to criticise something instead of trying to help and make it better. As far as I'm aware, I don't think that anyone in the Hudson/Jenkins community ever claimed that their code base is the best example of quality software ever written and we all should learn from them. If that was the case, probably it would justify such harsh words written in the original blog post

The only acceptable form of criticism towards any open source project or developer is constructive criticism. 

If we think that a open source project is below standard and/or not good enough, we should either not use it or we should contribute to make it better.

However, I do understand the point Gojko is trying to make. Yes, I agree that good code is not the only thing that makes a project be successful. I think we all could name a few projects that we delivered where clients and/or users were relatively happy but the code base was a bit messy. There are always exceptions to the rules. Trying to get our code as perfect and as clean as possible does not guarantee that our projects will be successful and having a messy code does not always mean that our project will fail either. We all know that. Even my 5 month-old baby girl knows that.

However, I totally disagree with Gojko's statement that "[Hudson's success with "bad" code] is close to the final proof that God doesn't exist for the whole craftsmanship debate". It is almost like saying that Agile is rubbish and everyone should forget about it just because some waterfall projects succeeded. It is like saying that we all should forget about good principles of software development just because some projects succeeded with messy code. In summary, is like trying to get some exceptions and transform them into rules. There are many ways and many things that can contribute to the success of a project. Software craftsmanship is one of them and a very important one. In a software project, the most important thing is the software itself and looking after its quality is an obligation of every developer involved in it.

Although software craftsmanship on its own may not be enough to guarantee the success of a project, the lack of it can be reason for its failure. Single-handed.

Another important point we should ask is the definition of a "successful project" and in which context or environment but I'll leave that for another post.

If exceptions invalidate rules and that is the way we should look at things, does God exist for anything in software development?



Published at DZone with permission of Sandro Mancuso, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Cosmin Mutu replied on Thu, 2011/06/30 - 8:05am

Nowadays people take for granted everything that`s for free.

What? Youtube is not working? OMG! How dare they? (As if they paid for it).

I guess the same thing happens for open-source projects.

I can only take my hat off in front of the developers that actually find / have the time (and use it) to code for the community.

Ronald Miura replied on Thu, 2011/06/30 - 10:05am

Well, there is no God.

Gojko says, in the comments:

"Koshuke’s comments show that we have a completely opposite view of testability and clean design. Which is fine, I don’t expect everyone to agree with me."

But, in the next paragraph:

"But my point wasn’t to dissect every single piece of hudson, it was to point out that a project with a complete disregard for clean code is very successful." (emphasis mine)

At the same time he says it's just a difference in perspective and opinion (and it is), he judges the project based only in his assumptions of 'truth', in a very disrespectful way.

AFAIK, the guy is a jerk, but an expected result of all this 'software craftsmanship' movement crap.

(sigh) I wish I could unsign that manifesto....

Lund Wolfe replied on Sat, 2011/07/02 - 3:28pm

I would hesitate to cast judgement on the entire code-base based on a few snippets of code, though these examples do cast some doubt on the Hudson developers' skill/knowledge of OOP and best practices. I haven't looked at the original Hudson code, but the main Hudson developer has a good reputation (the reason for forking Hudson to Jenkins) and Hudson does have a simple user interface and day-to-day dependability and user quality (the first and only real contender among CI tools IMHO). The quality of the design and code on the whole may actually be very good and could easily be turned over to average developers if needed.

"Clean"/quality code is great but really only becomes significant (to the business at least) when the end user quality is seen to start deteriorating because of ongoing code deterioration or inability to add enhancements in a reasonable amount of time. These code snippets appear to be refactorable without much difficulty. Seriously poor quality design and code is actually a nightmare to refactor and usually gets a response of "rewrite" from developers. You know you are in this situation if you need a guru just to maintain the code at its current level of user quality. Open source code may have more eyes on it but that doesn't give it either an advantage or disadvantage over corporate/commercial code. The code is only as good as the developers.

Christopher Radius replied on Tue, 2011/07/26 - 1:39pm

Nice article! Project managers can download Jenkins, together with enterprise support, from the new WANdisco uberApps Store. Check out the video for info:

Sirikant Noori replied on Sun, 2012/01/15 - 12:04pm

The point was pretty well made in the original article, if rather bluntly, that code quality is not a measure of success. But as you have pointed out projects are long running things that have both a past and (hopefully) a future.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.