Bring back the trust

The software industry changes extremely quickly. As a result there is a need for companies to be highly mobile and have the ability to respond to threats, clients, or market changes in a fluid manner. Because of this I have seen countless examples of the organization changing at the cost of the engineer, which is one of the many reasons why some software engineers have such utter disdain for “management types”.

We have all met at least one engineer in the past that had a bitter taste in his or her mouth for corporate leadership. Why? Trust. There is a level of trust that must come between all leader and follower relationships. This trust is one of the most important things in the company as it ultimately drives the output and quality of the company. Many times, either correctly or incorrectly, software engineers feel that they are the first ones to do the heavy lifting but the last ones to get recognition for doing so.

Here are a five things that will help to improve relationships with your developers:

1. Listen.
Listen to everything and understand it before taking an action. Often times developers tend to “dumb it down” for the “manager types”, leaving out often pertinent technical details. If something doesn’t quite make sense, ask for more information instead of immediately passing judgment. Despite the fact that “dumb it down” implies lesser intelligence on the part of “manager types” it doesn’t actually mean anything of the sort. You wouldn’t expect a career software engineer to understand the intricacies of the corporate pro forma balance sheet so it only makes sense that he or she wouldn’t expect you to understand the intricacies of bit shift operations in a hashing algorithm.

Part of this item comes in the form of project management. If a developer states that it will take one week to complete a project then it will likely take a week to do the project. Before demanding a shorter time frame, throwing more people at it, or forcing overtime, understand what went into the estimate. You simply can’t make time out of nothing and, as the Mythical Man Month points out, adding more people to a software project will often increase the time it takes to reach completion.

2. Stick to your word.
If you tell people something, stick to it. If you can’t stick to it, make every attempt to explain why and to make things right. This applies from everything to projects to job role. I worked for a company at one point that had promised us over and over that a certain (bad) thing would not happen. Then it did. The senior management immediately lost all credibility and control of the organization.

3. Give recognition.
Unless projects are marveled at because of their ingenious engineering, engineers are often the last to be thanked but the first to begin work. My current company does a pretty good job of recognizing the hard work put in by their engineers however I have been in many situations (at other companies) where sales, marketing, senior management, and call center personnel were all repeatedly thanked for making a project a success but the developers that wrote the actual product were not even mentioned.

4. Promote education.
Engineering is a mental job. Most of what goes into designing and writing code takes place in a little box within the head of every engineer. When creating systems the complex relationships, object models, and business rules all come together in a mental map that allows engineers to simply transpose their creation to the screen. By promoting education employers can not only further the abilities of their developers but allow them to sharpen their skills. As Stephen Covey points out in The 7 Habits of Highly Effective People, one of the most fundamental things people can do is to sharpen the saw meaning, in a nutshell, take time to improve the self.

5. Foster downtime.
Despite the public perception, software engineers are just as social as the rest of us/you. They are not work horses that blossom under the constant crack of the whip. As with all people, downtime will often bring a much larger gain through employee happiness. Studies have shown that a happy and secure employee is always going to be more productive than a pressured and tired one.


The Quadruple Edged Sword

I was recently in a meeting where we were talking about performance and someone posited that performance is the number one thing that should be focused on in enterprise software. While I will concede that I agree, I only concede in fourth.

I feel that ultimately software must be able to do four things, each of which are equally important:

1. It must meet consumer expectations
If a program has a million bells and whistles, all of which are great, it is utterly useless if the single bell all consumers want is missing.

2. It must work
This almost sounds silly to say, but there are countless commercial sites that I have not returned to because it was obvious that they had not taken the time to make sure that the most basic of things, such as logging in, work correctly. Directv is one such site that stands out in my mind – I can log in, try and pay my bill, and am returned to login – this becomes an endless loop. If consumers can’t trust you to test the basic and glaring issues how can they possibly trust you to protect their vital personal and financial information?

3. It must be fast enough
There is a marked difference between fast and fast enough. Fast is an ambiguous term that must be anchored to something relevant and, by itself, is just a meaningless number. Fast enough means that you can perform at a speed that the reasonable user would find acceptable. Fast enough means that you can handle the expected, and even above expected, load without sacrificing performance in the process.

4. It must be maintainable
We have all written bad code. Bad code sucks. Bad code is time consuming, frustrating, and overly detrimental to the company. Maintainable code should not just be functional but should be designed so that future developers are able to easily understand what is going on and quickly and accurately make changes. While this is not possible in every scenario, in most it is.

    As a developer it is very easy to get focused on one or more of these factors, neglecting to treat each as a single part of the larger whole. The more time and effort developers are able to devote to making sure every application meets these four criteria, the more successful applications will be.