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?
1 comments:
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.
Success might be measured at a point in time by the usage of the project at that moment, or it could alternatively be measuered by its ability to adapt going forward. All else being equal, Id like to think that it is this latter view of quality that software craftsmanship can influence for the better.
What's really interesting about Jenkins/Hudson is that we have an already 'successful' project that is now being taken in different directions by different teams. And although all else is probably not equal (as commercial politics and todays other news concerning Hudson being handed over to eclipse show) we have the chance here to compare how these two branches progress. Will software craftmanship be applied in either branch? If so, will we be able to guage its value? Who knows, but I cant think of a better case to study in recent times.
Post a Comment