Craftsmanship means we should refuse to work in dysfunctional environments!

June 17, 2010 | 3 Minute Read
This post was originally posted on my old blog.


My post "From coding whore to opinionated developer" last year had quite some comments.

I was taking the position, that we developers do not have to put up with everything. As professionals we should set some minimal standards and if they are not achievable then we should not be here.

I was focusing on rather technical aspects of development. One and a half year later I have come to the conclusion that we should extend our standards to all aspects of development. In my opinion it is a sign of professionalism to insist on certain standards in our environment. If these standards are not met, we should try to change things, but if this does not work we should strongly consider the option of leaving.

Jumping on the crusade of Uncle Bob et al. for craftmanship in the software industry, I think we as craftsmen should refuse to work in projects where the clearly unproductive political and organisational overhead is in no relation to the actual essence of the project. Our professional pride should not allow us to accept certain conditions.

Symptoms of such dysfunctional project environments are:

  • Having to sit in overstaffed meetings where we don't have to say anything and won't get anything out of it.
  • Working on short term contracts that do not match the assigned tasks (you don't know if you will finish the given task)
  • Starting to work without a contract
  • Having to start urgently and immediately on a project but when you start working there is actually no work for you to do or nobody has time to introduce you.
  • Starting on a project but the necessary infrastructure is not available (hardware, software, accounts ...)
  • The only times your manager is approaching you is when you made a mistake in your weekly time-report.
  • Having to feed bogus status reports to three different managers that do not talk to each other.
  • Having a horde of business analysts on the project, but not knowing who they are, where they are, what they do and how this should effect your work.
  • Having no chance to get to know the real stakeholders of the projects.
  • Knowing that any concern you voice is just draining away in the maze of organizational overhead.

Accepting symptoms like this is a sign of resignation, it means that you accept that you will never deliver what you are capable of (which is quite a comfortable excuse for mediocrity), in essence you are giving up on being a professional.

Sadly I observe that contracted developers in big enterprise projects put up with almost everything (I am including myself here). Some of us struggle, but we give up at some point. We can't identify with the project any more, we do not care any more. We are just executing tasks. We cling to the cheap excuse that at least we are getting paid ... we have given up on being craftsmen.

This is the typical No pigs, just chicken antipattern.


(Note that I am aware that a lot of us developers are suffering from the "I do like my profession, I don't like my job"-syndrome, I am not arguing that we developer should be treated like divas, but I think that there are a lot of environments where we cannot bring any change ever, and the only way to achieve a change is to refuse to accept them ...)