Agile Zone is brought to you in partnership with:

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

Frustrations and Aspirations of a Software Craftsman

  • submit to reddit
For a while I've been thinking about what makes me like or dislike a project. Having spent a very big part of my career working for consultancy companies, I was exposed to many different environments, industries, team sizes, processes and technologies. There were projects that I absolutely loved, some projects were OK and some were a real pain.
There were even a couple of times in my career where I questioned myself if the choice of being a software craftsman and keep walking the long road would be the best thing for my sanity.

What makes me dislike a project?

Well, there are many factors. Here are just a few but is far from being a complete list:

  • Bureaucracy is something that can be really frustrating. That includes process for the sake of process, innumerable cycles of approvals, tortuous and long test and deployment cycles, pointless documentation, and all that anti-agile stuff.

  • Old technologies or the "wrong" technology for the job is always demotivating. We love new toys. There is nothing more annoying when the technology stack is imposed on the team. "You must use these tools from Oracle or IBM. But, hey, don't look like that. You have support if you need it."

  • Lack of autonomy and credibility. "You are just the developers here. You don't make decisions. You do what you are told to do. There are much smarter people here to worry about the _real_ problems. And by the way, you don't have admin rights to your PC and you can't access a few websites either."

  • Uninteresting domain. It's always difficult to find motivation to build a great software if you don't like what the software does or don't really believe in the business idea.

  • Demotivated people. How can we find motivation and have team spirit when your colleagues attitude is: "Oh, I just turn up to work, keep my head down and do what I'm told. If something goes wrong, it's not my fault."

  • Finger pointing and highly competitive environment, where no one plays as a team. This is an environment where everyone wants to be the boss, they are always looking for a scapegoat and the less work they do, the more they delegate, the better. If something goes wrong, it would never be their fault. If something goes well, they take all the credit.

  • Arrogant and unskilled people. Arrogance many times is used as a self-defence mechanism in order to hide the lack of skills a person may have. "I don't need to read any books. I think all these new technologies and methodologies are crap. I've been doing this for years. I know what it is best."

  • Software factory concept. "We need to go faster. Let's throw more developers here. Which ones? Doesn't matter. Just hire some monkeys."

  • Mortgage-Driven Development

  • Project managers that think they are the most important member of the team

  • Very deep hierarchy

  • You can't help those who don't want to be helped.

  • I really could go on forever here....

So what is really the problem here?

When I first mentally thought about all these items, I realised that almost all the things that make me dislike a project are related to people. Yes, people. One of the few exceptions are uninteresting domain and old technologies. So even if I make sure that I don't work on projects related to subjects I have no interest and that use the latest technologies, the people involved may make it very frustrating. Have you ever been on a project where you thought that the project had everything to be a great project but for some reason it was a pain?

After this analysis, things were not looking good, so I decided to look at all the projects I really enjoyed. It was when I realised that in some of them we didn't use the latest technologies and in a few of them I was not exactly passionate about the domain either. One or two were even quite bureaucratic. So, why did I enjoy them? What was in there that made me put them among the projects I liked the most? Once again, the answer was "people".

The good projects and what I always would like to find

My favourite projects had quite a few things in common but the most important ones were passion, craftsmanship, friendship and trust.


It's not because you like something that you are going to be good at it. However, to be really good at something, you must have a passion for it.

The best people for a job are the ones that love the job. This in the essential quality that drives people to be successful in whatever they decide to do. A passionate person will do whatever is in his or her power to keep acquiring skills and do the best they can. Passionate people bring innovation, they question what they are doing, they want to contribute, they want to get involved, they want to learn. They want to succeed. Passionate people CARE.


The only way to go fast is to go well - Uncle Bob Martin

In all my favourite projects, the focus on quality and the willingness to see users satisfied and using the system was always a big thing. The whole team was focused in delivering the best project we could, taking into consideration all the constraints we were under. It was clear to all of us that to be successful we had to be pragmatic. We also always believed that how it is done is as important as having it done.
Software craftsmen use the right tools for the job, are skilful, are pragmatic, care about the quality of their work, care about their reputation and want to delight every single one of their customers and users. Software craftsmen CARE.


So far I've been talking about passionate people and care. However we know that people have different opinions and there are many ways to do the same thing. Now imagine a room full of very passionate people that don't really get along. In the best scenario, there will be some memorable arguments. In the worst, they will kill each other.

Friendship is the answer to that. The importance of social events for a team is enormous, even if it is just a few drinks once or twice a month. Like it or not, we spend more time with our colleagues than with our own family, so it is important that we have the friendliest environment possible. Having lunch together at least a few times per week is another thing that can help improve this friendship. Team members need some time together where they are not always just talking about work. Team members need time to know each other. 

Among friends people feel comfortable to speak their minds. Working with friends helps to improve the quality of the discussions and no one is worried to expose ignorance or give suggestions. Friends help each other, friends learn from each other, friends CARE for each other. 


Once people can demonstrate their commitment and passion, can demonstrate competence, willingness to learn and contribute and are able to deliver the best software possible, trust is easily established. With trust you gain autonomy and are free to decide what it is best for the project and to do your job well. With trust you can be more effective when delegating or sharing tasks. With trust we can remove all the bureaucracy that impedes that we do our job efficiently.   


I just wish I could find the things I described above in all projects. Companies should aim to hire passionate and skilful people. People that can contribute to their projects and organisation. People that are willing to share and learn.

Unfortunately not always we will find all that. In those cases, the only thing we can do is to try our best to change the environment around us. We can try motivate people and share our passion. We can be nice to everyone, respect our colleagues and promote an environment where everyone feels comfortable to ask for help, to help each other and share knowledge.

With great people we can overcome any obstacle and have an environment where every morning, when we wake up, we would think: "Yay! Today I'll have another great day at work."
Published at DZone with permission of Sandro Mancuso, author and DZone MVB. (source)

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


Sivaprasadreddy... replied on Tue, 2013/02/12 - 7:47am

Oh I am not alone, there are other ppl having the same problems :-)

Very good points. The main reason for dissatisfaction in S/W development is mostly because of people, not the technical problems.

Especially the first 3 bullet points in What makes me dislike a project? section makes passionate developers highly dissatisfied.

Toufic Zayed replied on Tue, 2013/02/12 - 11:38am

So true!

Cohesion and team spirit is difficult to build, and easy to destroy (one or two key people with the wrong mindset can completely corrupt an otherwise effective team).

This is why not only the technical knowledge but also the mindset of the people you hire is very important.

Customer relationship is the same, it's sometimes difficult to achieve a completely trustful and fructuous relationship with the customer, and when you have it, you must protect it from the bad influence sometimes politics can bring.

I've learnt that to build highly effective team, all members including the managers (especially them) must be very careful about the way the team is running.

It may seem obvious, but it's rarely applied, too many time we see politics, competition, jealousy and incompetence instead.

If we should investigate the causes for failing projects, I'm pretty sure that most of the time, people rather than technology are the key explanation to failure: bad decisions, unrealistic planning, wishful thinking, all these antipatterns that we can see at work almost everyday!

Senthil Balakrishnan replied on Tue, 2013/02/12 - 4:38pm

I like and share this honest expression of frustration, but then we are not in an ideal world. The key challenge for any project execution is to work within constraints that real world poses on us. We can wish this would change but then not in the near future :)... 

Lukasz Kujawa replied on Wed, 2013/02/13 - 3:20am

Just this morning I was contemplating common mistakes of managers and executives. This article summarise it very well. It's sad some companies chose to demotivate and frustrate own stuff. 

The question is what can be done about it? A polite letter to CEO/MD/CTO/HR? 

Florin Jurcovici replied on Thu, 2013/02/21 - 1:49am

I'd add unnecessary meetings to the first point.

"uninteresting domain and old technologies" is IMO also a people issue. I think most programmers that care find solving difficult (programming) problems interesting, regardless of the domain. Of course, if there's a nice free library out there which would allow you to solve a problem in a week, then go for beer for the next month until delivery, but management or un-skilled coworkers insist on using the dreadful in-house implementation which has been used since ever, you instantly develop a strong adversity for the project.

Comment viewing options

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