Writing code and creating working software is not hard but writing quality code and creating valuable software is.

The software craftsmanship manifesto values:

Not only working software, but also well-crafted software.
Not only responding to change, but also steadily adding value.
Not only individuals and interactions, but also a community of professionals.
Not only customer collaboration, but also productive partnerships.

That is, in pursuit of the items on the left we have found the items on the right to be indispensable.

One can hardly doubt that the principles from then manifesto can be satisfied in other way than through passion. Of course, not all individuals involved in the process of software creation do their job with passion and dedication. Some do their job just because they need money or because they have some other interest and they really don’t care about the final product. They create software because they have to and usually is bad software.

Bad software is not software that does not work! Bad software, from my developer point of view, is software that was created chaotic. The project, from the beginning or from another point in the project’s timeline, was not governed by some rules and tenets. The individual involved in the project did not adhere to some standards and everyone was doing anything just to make a piece of working software.

This kind of projects are like pipes with rubber tape. You add more and more rubber tape (bad code/ideas, hacks) where you find a crack and in the end you will be over whelmed by the mess you created. Also, the fixing cost (refactoring) will be enormous.

In order to create quality software (both from the developer’s and end-user’s point of view) the team must create a set of good and realistic guidelines that must be used by every member. The guidelines can include various things like design patterns, coding standards, document writing standards, communication methods and models, meetings standards, etc. These guidelines must not be all brainstormed in the early stage of the project – they need to be created before the moment of the first occurrence of the item they refer and should be possible to change them later, if needed, in exchange of better ones.

Well crafted software and guidelines are not, on their own, the key to success.  Another characteristic of the team members, that was mentioned before, is passion. Unfortunately, this cannot be imposed – you either care or don’t; no one, except the individual himself, can change this. One must want and be able to suggest improvements of the process.If you care about what you’re doing then you are capable of suggesting improvements. Passion leads to ideas, ideas lead to change.

Good ideas should be valued and bad ones should be thrown away but only after careful analysis and explanation. No idea must be considered bad or good if coming from a specific team member. This means that experienced team members can have good and bad ideas and novice members can also have good and bad ideas – members should be equally treated.

Not even standards and passion are not enough for creating good software. If people are individualists and tend to care only about what they are doing it will end up with some good pieces but not connected or poorly connected. Individuals must care about others, must communicate, establish good relations and form communities. These communities must be able help members to find solutions and members should be able to improve the community.

Instead of conclusion, will step back a little and say more about passion. As long as you are not passionate about what you are doing, you cannot get good results. Also, you can’t be proud of what you are doing. This is a vicious circle: passion leads to pride, pride leads to passion; the opposite is also true. So I will end with what Aristotle said “Pleasure in the job puts perfection in the work”.