What Was That Developer Thinking?! How a Value System Inspires Developers

Ever had a developer join a team, suggest a radical solution, and be shut down? Or have them suddenly be allowed to develop their ideas? I find it fascinating how this happens, and may have some insight. Each company's culture, whether they know it or not, has inherent values. For example, do they put security first over maintainable code? Do they allow applications to have bugs and issues just so they can be first to market? Do they always invest in new ideas instead of making code work? I find the answers by evaluating a company's set of values, as discussed below.

I ran across a book early in my career that has impacted me for the last 10 years. It was all about best practices, with 700 examples. I used it as a reference for some time and, although concepts and opinions within it have changed, the guidelines — and more importantly the values — of the book have stuck with me.

The values or concepts in that book are (paraphrased, listed in descending order):

• Robustness — Code must work as intended and not cause fatal errors.
• Security — Malicious app use is not allowed.
• Scalability — As the number of users grows, so too must the application.
• Efficiency — Light and fast, with no added strain on external resources.
• Usability — The application should be easy to use and learn.
• Code Reuse — It should be easy to reuse code for other projects.
• Extensibility — Extendable, localizable classes with limited effect on the current app.
• Maintainable — Source should be readable and consistent, without undocumented features.
• Language Interoperability — Code should be translatable to another language.
• Ease of Development — Productive, quick coding with fewer human errors.

Shortly after acquiring the book, I also had a respected CIO define values very similar to the book and then rank them. When a development decision had to be made, we referred to the values listed on the walls of our cubes. This was a huge win for the development team. When opinions cropped up or action was needed, we could always resolve it based on these values.

As I recall, they were:

• Safety — Code must work and not impact existing production.
• Maintainable — Source should allow anyone to work on it.
• Code Reuse — Business logic should be seen in only one location.
• Innovation — Code must be thought through and creatively crafted.

I have reflected on development for the last 17 years and how teams are productive — or not. In many cases, the teams that produce great applications have an alignment of their values. They see the bigger picture and have a leader who consistently adheres to their value system. For teams that are not producing, look into the values of each team member and take inventory of what each person thinks. I suspect a quiz ranking a list might be helpful.

Regardless of my lists above and my opinions, I truly find it rewarding to understand why developers think the way they do. In our minds, it is logical — we value one idea over another because we have a value system. Please take the time to assess what value system is in your current employer, and what value system you have. The best developers, in my mind, are the ones who can adapt to their employer's values.