Software Development is Personal

I’ve met developers who are command-line wizards. They prefer to use typed commands and scripts for all their work. Some even do much of their coding in “vi”, because they feel that graphical IDE’s get in their way.

I’ve also met developers who are strongly visually-oriented, and prefer to use rich GUI interfaces for everything. Some even do much of their code using UML tools that take diagrams and generate classes from them.

And these two types of developers represent the two extremes of a broad spectrum of developer styles and preferences that are personal. I’ve met brilliant and effective software developers all along this spectrum.

I don’t think there is sufficient recognition of the human factor in software development. Techniques, tools, and methodologies that work well for some developers are often awkward and unnatural for other developers.

I see way too many proponents of some technologies or methodologies who say “Once you use XYZ, you won’t go back!” Obviously XYZ was a natural personal fit for these evangelists. And if other developers don’t instantly fall in love with XYZ, then the standard answer is “You just don't get it yet. Keep using it. You’ll get better at it with practice!”

Yes, of course any developer will get better at anything with practice. But what is not recognized is that technology XYZ might be fundamentally at odds with an individual personality, and at odds with the way that person internally structures and processes information.

A given developer might be more productive with technology “ABC” instead of “XYZ”, even if ABC is viewed as inferior by a plurality of members of the developer community. And yet, in our industry, there is much pressure to standardize and “keep up” with the latest trends. Developers who don’t use technology XYZ can feel embarrassed or fear that they don’t “get it”. They don’t dare openly admit that technology XYZ doesn’t seem right to them.

For example: Test Driven Development. I know many developers who tried TDD, and it was a perfect fit for their development style, and for their personality. They LOVED it, and they can't imagine doing ANY coding without it. Then there are other developers who try TDD, and find it doesn't pay off for them, and gives them two points of maintenance for every function point. And it's just not a natural fit for their personality to code "test-down" instead of "code-up". The truth is probably somewhere in the middle...that TDD is good for some types of objects in some types of situations.

And yet, TDD has become a major source of contention is the development world. The people who enjoy TDD are over-using it. The people who hate TDD are under-using it. And all manner of arguments and conflict ensues.

Human beings learn and think and process their knowledge in a wide variety of ways. Some learn best by listening, some learn best by seeing, some learn best by doing. Some people are extroverted, some are introverted. Some people need details, some people need the big picture. And so on and so on. The variety of ways in which different people think and learn makes it really difficult to make abstracted technologies or methodologies that are a good fit for everyone.

But then, how do we create an effective team of developers unless we standardize on a specific methodology and a specific set of technologies? How can you use TDD when both sides are insisting an "all-or-nothing" approach? It is difficult. I don’t have any magic answers, other than we should be aware of this phenomenon, and be sensitive to it. Assign developers to those tasks which are the best fit for their personality. Try to keep team standards at the lower levels, at the code level, where they are most important.

I’ve worked on teams where developers use different IDE’s and different Operating Systems, each tuned to their own preferences. And that does seem to work very well, especially in the Java and Open Source worlds where everything is cross-platform and follows a set of low-level standards.

But at any level where a team has to function as a single unit, there must be standardization. For example: All developers on the team must follow one project methodology. So, if your team wants to use XP (eXtreme Programming), and you’ve tried XP and it just doesn’t fit your personality, then stick it out for a while and hope they change their mind or hope you find a way to make XP work for you. But failing that, you might then try to find other projects and companies that don’t use XP. If XP becomes so popular that every company uses it for every project, then you might need to consider getting a job in another branch of technology.

But I doubt that will happen. Companies themselves have personalities too, and XP is definitely at odds with some corporate personalities. So the best thing is to find a company that has an overall personality that fits your own preferred working style. If you enjoy documentation and rigid procedures…then go work for an insurance company. =)

Finding a personality match with a company will make you most effective as a developer and bring you the highest degree of job satisfaction. And if a given project decides to use some specific technology that you find awkward, like Tapestry or EJB2 or whatever, you won’t have as much of a problem adapting to that technology for the sake of the team.

As developers, we have all gotten used to being effective and productive with sub-optimal technologies. =)