Let's say you are hired to help build or fix an application. You contract is not for hire and you know that after 3, 6 or 12 months you will be gone to repeat the same cycle elsewhere.

I'm sure we have all seen contractors that will do just about anything to complete the task in the allotted time span, sometimes in detriment of the code quality and maintainability. I'm also sure that if you're reading this then you probably care about this enough to avoid replicating this pattern.

But here are some important things that might go unnoticed in the above paragraph.

• Define The Task
• Define Quality
• Define Maintainability

The Task

In my limited experience, I'd say it would be shocking to be hired to just write code regardless of any parameters, as long as the deadline is met. I don't expect to hear from my client "I don't care if what you write is absolute garbage material but it needs to go live in 6 months."

Even if the client is very much driven by the deadline, even if the client doesn't say it out loud, there will always be an implicit expectation that our solution will have a minimum of quality to survive the planned life time.

Our task is never to just write code. They could have hired a high school intern if that's all they wanted.

Quality

I think the quality of a software product is directly related to how well the product adheres to the specifications. Oh, no, specifications. One more thing to consider.

If we're lucky the specifications will be available and include not only the product feature list but also architectural needs, expected maintenance and upgrade pains.

Again, we are not being given carte blanche, even if it sounds like we are. Maybe the client doesn't know how to communicate that to us, but we ought to know that our design needs to accommodate changes and lay on top of a maintainable platform.

Maintainability

The ease with which a software system or component can be modified to correct faults, improve performance, or other attributes, or adapt to a changed environment - IEEE Standard Computer Dictionary

The IEEE definition above is fine but, after a discussion in the last Chicago ALT.NET meeting, there seems to be an important omission here and the main reason for this post.

Maintainable by whom?

The same way our proverbial consultant from the beginning of the post could deliver abominably graded solutions and run away, so can we — with all our shiny, fancy-pants design and tools.

We have the responsibility of designing a solution that is maintainable by the client with their staff of with realistic chances of finding other contractors that can take it on (not necessarily us all the time.)

We have to weight our design decisions and desire to apply the better tools and architecture against the existing scenario. When discussing the possible solutions with the rest of the team that's a good opportunity to assess what kind of team we have to work with (or work for.) If the scenario doesn't look good, there at least two things that can be done:

1. Discuss the problem with the client and suggest that the staff would benefit from some training or mentoring, so that we can apply a solution that can be maintained more effectively. Training and mentoring may be strong words, sometimes a few informal sessions with the team can go a long way.
2. If the above is not possible, then the responsible thing to do is choosing a design that the existing team will be comfortable maintaining after our departure. Knowing when to suppress your good intentions is also an important quality of a good consultant, I think.

That's not to say that we should give up trying to raise maintainability bar of our application designs. The rising tide can lift most boats but careful with the over-dimensioned anchors.