Software Development Culture

We live in an increasingly globalized and dynamic world, and the software engineering space is not immune to the challenges that this presents.  Companies are starting up, shutting down, off-shoring, near-shoring, and sometimes all of the above.  This post presents a hypothesis around the definition and assessment of a software development culture.  For the sake of argument, I will refer to this as “Development Culture.”

As of 2015, I have worked in a professional software engineering capacity for about 20 different companies, based in several different countries, either as an employee, a contractor, or a consultant.  That puts me in a position to think I know something about the specifics of this thing called Development Culture; what works well, and what does not work so well.  One thing that I have observed is this: there is usually a huge difference between the Development Culture that is claimed publicly, and what is actually happening behind the scenes.  This makes for a much more challenging experience for those in a job search, simply because things cannot be taken at face value.

So, dear reader, let us explore this topic a bit further.  I think we should start by laying out our assumptions.

Definition of “Development Culture”

I think of Development Culture as the teams, environments, tools, and leadership that are involved in the creation, development, deployment, and support of a technical product or service.

That means Development Culture is more than a couple hero programmers, free pizza, tons of caffeine, sweat equity, and the occasional happy hour.  It is also more than an enormous cubicle farm and warm bodies to fill all the hiring requisitions.

Who cares?  I think this is an entirely valid question.  I honestly believe most companies that have development capacity do care, probably at the highest levels in an abstract sense, and at the lowest levels in a tactical sense.  However, they may simply be unequipped, understaffed, staffed inappropriately, or under too much environmental or economic pressure to take action that would nurture and support the kind of Development Culture that works.

• A Development Culture that is not aligned with the company direction is probably not going to produce great products (I can only point to my own empirical experience on this one, but it seems to be a logical conclusion.)
• Turnover of talent can be very expensive in terms of ramp-up of new resources.
• Every time a key technical person leaves, valuable investment intellectual property (IP) is going out the door, possibly to the competition.  In extreme cases, the code is also going with them.

I was once at a company that produced mission-critical (mission-critical meaning someone might die if the software breaks) software in a completely waterfall model, and they  produced this software amazingly well, despite being in a relatively dull, bland working environment.

On the other hand, I have been on high-energy, youthful, highly agile development teams that produced little to no results in the same time frame as the waterfall example, through no fault of the engineers.

I met incredibly smart people in both teams, but I suspect that the engineers in either environment would not have traded places with each other.  So I would surmise: what works for developers in one scenario at one company, might not work so well in another.

This experience forms the basis of my assertion: I don’t think the classification of development culture is as simple as “good” or “bad.”

I highly doubt that an effective Development Culture means that everyone is happy all the time, or that nobody ever quits.  It is simply a matter of the balance between results and the relative satisfaction of the people working toward those results.

Now that we got that out of the way, let’s think about how we might assess whether a Development Culture is effective.

There are many organizations that survey their customers and have a solid understanding of their customers wants, needs, and pain points.

Some of these companies do the same with their own staff, in the form of employee surveys.  Usually these surveys are assembled by a human resources department, perhaps with input from cross-functional management, and perhaps not.

Such surveys are often very high level, rhetorical, and too indirect to meaningfully assess the alignment of a development function.  It is exceedingly rare, at least in my experience, that the engineering or development side is queried in a focused, relevant, and respectful manner.

Therefore, I think it is necessary to approach any assessment of development culture along two lines:

1. The quality of the output of the development team, as related to upstream inputs and goals; this is already a heavily metric-laden area, represented by cost, cost of support, cancelled projects, bug counts, customer NPS metrics, and so forth.
2. A direct assessment of the culture of development itself, as solicited straight from the involved engineers.

For this post, I am going to focus on Point #2.

I am not the first to do so.

About a thousand years ago, the legendary Joel Spolsky laid down his gauntlet with his famous Joel Test.   The very cool John Sonmez elaborated on this further in one of his blog posts.  Others have lent their own interpretations, but these tests are very specific to the mechanics of coding, which is a narrow part of the overall concern.  I wanted to take the discussion further.

Mostly for my own selfishness, I will apply my own background to produce a tangible set of questions that might be used to differentiate a Development Culture that is working, from one that is not working.

These questions could be asked of a person in an engineering or development capacity, to deduce whether there are problems in the culture, as defined by the above definition.

Here were my (admittedly arbitrary) parameters in assembling this set of questions:

• must be able to complete the assessment in about 5 minutes at 15 seconds per question
• questions must relate to any organization
• all questions should be straightforward yes/no style, no ranking or scales
• a “yes” must indicate a positive alignment, and a “no” indicates otherwise
• based on the answers, I should be able to score companies that I have actually worked in, and have it make a degree of sense

I couldn’t quite get down to 20 questions, but I think I arrived at a solid list.

But First: An Acronym For It

Before we see the questions, out of a sense of obligation, I had to create an acronym for it.  So, it is thus christened: the Software Development Culture Assessment (SiDECAr). Here it is.

1. Do you have a clear understanding of how your work relates to company goals?
2. Do you think you are being paid what you are worth?
3. Do you enjoy the physical conditions of the environment in which you work?
4. Are you and your colleagues treated fairly and without discrimination?
5. Does your company support you in keeping your skills up to date?
6. Does your company work with your schedule?
7. Do you feel that you have a future with your company?
8. Does your team work effectively with the business, product management, QA, and support functions?
9. Do you feel that your company supports meaningful and honest dialogue about technical or environmental matters?

1. Are you proud of the product or service that you work on?
2. Are you motivated to contribute to your company’s success?
3. Do you enjoy your daily work?
4. Are you using modern development tools (e.g. great IDEs, great CI tools, Git, Jira, etc)?
5. Do you enjoy the languages and technologies you are currently using?
6. Are development teams automating all possible parts of the testing, integration, and deployment processes?
7. Are you supported in keeping your skills up to date?

1. Do you trust your manager?
2. Does your manager support you, your ideas, and your team’s ideas?
3. Does your manager remove obstacles and address problems for the team?
4. Does your manager interact in an honest, ethical, transparent manner?
5. Does your manager care about the morale of the team?
6. Do you think your engineering leadership cares about you as a developer/engineer?
7. Do you think your engineering leadership makes sensible decisions?
8. Is it clear to you how company leadership makes decisions?

Add up all the “yes” answers, assign them one point each, and the best score possible is twenty four points.

Very simplistic interpretation of the results from my own biased perspective:

• Score of 0..10: Tread cautiously, or at the very least, prepare for many challenges both technical and non-technical.  Many people thrive in such an environment, and many people do not.  At least you know what you might be getting into.
• Score of 11..18: The company is probably aware of its Development Culture and it sounds as thought they are trying to Do The Right Thing.  They might seem to be on the path, at least.
• Score of 19..24: Either this Development Culture seems to be fostering its own growth and looking after its development teams, or more assessment data is needed.

Eating the Dog Food

While I cannot name names, I tried this questionnaire for myself, based on some of the companies that I have worked with:

• Score of the largest company I ever worked with: 6/24
• Score of a very small company I worked with: 8/24
• Score of a company that I had the most fun working with: 12/24

Thus, I am sad to report, that the companies I have worked with may not have many bragging rights for great development culture.  On the other hand, perhaps these questions are a step in the right direction, asserting that our industry has some work to do.

What is your score?  Tell me in the comments section (please, no company names).