Why Developers Make Tactical Code Changes

There is saying that every speech is actually three speeches – the speech you planned to give, the one you gave, and the one you wish you gave. I think software development is very similar in spirit. Most software professionals want to produce high quality code. Yet,there is a difference between code that they write and what they wish they wrote.

There are a whole host of tactical code changes that creep into an application or product line which will have a negative impact for the long term. By tactical I mean short-sighted changes that corrupts the sanctity of the codebase – maybe it violates encapsulation, breaks the design principles that we meant to be followed, introduces needless coupling, worsens technical debt, and so on.

Why are these tactical changes being made? This question is extremely relevant to systematic reuse – whether you are pursuing reuse via objects, component based development, service orientation, or a combination of these. Here are some of my observations on why this happens:

  • Time pressure – the need for meeting deadlines. Often senior developers are fully aware of the right place to add code yet proceed with tactical changes. If technical debt is consciously taken on, this isn’t too bad. But, are these always conscious decisions?
  • Unwillingness to question key design assumptions (e.g. not considering ill effects of tight coupling between entities or systems) and not addressing support needs.
  • Not considering the need to support multiple concurrent versions. Backward compatibility and client integration needs aren’t considered at development time.
  • Lack of knowledge about existing capabilities in the codebase. It could also be inadequate knowledge about planned assets, or the roadmap for application transformation. This could be due to lack of communication and/or the developer being new to a team.
  • Thinking about changes within the context of short-term deliverables only. This usually manifests itself in seemingly harmless code changes that mushroom into bigger problems later – adding a method in a convenient place rather than the appropriate one or cutting and pasting a variation of existing functionality.
  • Lack of collective code ownership – if it isn’t my code or i didn’t write the first version why take the initiative to make it better?
  • Inadequate knowledge of team’s coding and design standards and practices. Where should a new component be added? who will review the code to ensure that it is reusable? how do i let other developers know? how do i document assets?

Do these reasons resonate with your experience? What could be added to this list?

Like this post? Subscribe to RSS feed or get blog updates via email.

tweet this add to del.icio.us post to facebook

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: