Developer-Think

You’ve heard of group-think? The “tendency of the members of a group to yield to the desire for consensus or unanimity at the cost of considering alternative courses of action.” (http://www.businessdictionary.com/definition/group-think.html)

I think in the world of software development we have to be careful not to engage in “developer-think”. What I am calling developer-think I am going to define as the tendency of a developer or group of developers to disregard effective and real value-added design and development for the sake of what makes sense to them.

When presented with a new project, it can sometimes be challenging for the developer to stay focused on the task at hand. Mind you, I am not saying that features should never be added to the project! If the feature can be added without costing more than the value added it could be considered. However, if the developer wants to add the feature to increase the coolness factor, or to make it conform to a particular coding practice, or to just blindly do whatever the user requests, it would be better to leave it alone or at least give it some additional thought time first.

My boss actually has a very realistic point of view here “The faster you can get your project released, the less time the customer has to come back with questions or changes that will put the project behind schedule.” I think more developers should think that way! There can always be a phase 2 or 3 or whatever, but a project that is scheduled to take three weeks that turns into six months has some serious issues! Before you pass the buck, consider that it very well may be due to “developer-think”: not understanding the end user’s needs and requirements, over complicating a solution, feature creep without value added, and I’m sure we could think of more!

Some developers are very intelligent people who develop brilliant pieces of code in only a few hours. These brilliant developers, if not careful, can add complexity, and within a group who respect and admire their work, those same brilliant developers can easily lead the entire group into developing a security access application for a nuclear power plant instead of the requested simple login screen for a blog (just example).

Some developers are so focused on thinking analytically and logically they forget to think about the way the users leverage the application and in the worst cases of course, completely and purposefully disregard the users. But they don’t seem to remember that without the user, they just have an application that no one uses! I have been in places where users didn’t want to have anything to do with the developers or anyone in I.T. and as a result the projects are either very difficult to complete or hold no interest what so ever. Everyone who wants to work in that environment raise your hand! No takers? Huh. Maybe we should treat our users as a valuable asset to our work. For those developers who don’t like users, maybe its time to take this sage advice (slightly modified) “Keep your friends close, and your users closer”.

A third pitfall developers fall into is adopting a “cool” new coding practice without counting the cost. We have all read or seen something new and cool that either would make our lives easier or would be awesome to implement in our current application. Sometimes, with the right project and the right time allotment, we can actually implement some of those enhancements. However, the danger is in getting off target and making the project run a little late (or a lot late). This could lead to more time for user feature requests, open the door for visible possible enhancements, or just simply slow down the work of your team. Again, sometimes its worth it, but the cost needs to be counted first. In a good, agile shop, developers should be ready to release early, release often, and continue to keep the projects moving forward.

A good group of developers recognize these behavioral tendencies within their group and will work together to help each other stay away from these pit-falls. How can you tell if your team has succumbed to “developer-think”? Start with some of these evaluative questions: How agile is your shop? How long does it take you to release a fully tested medium-to-large sized project? What is your relationship like with your users? Do they value you or talk bad about “I.T. people” every chance they get? If those questions can be answered positively, you are probably on the right track already, but remain vigilant and keep them positive.