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
But here are some important things that might go unnoticed in the above paragraph.
- Define The Task
- Define Quality
- Define Maintainability
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.
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.
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:
- 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.
- 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.
06-17-2008 11:34 AM