Have you ever found an architect, developer or designer who
was not willing to express that the code, interface and architecture should be
standardized, consistent and all code must match the adopted organizational or
industry standards? Yet, many times the
standards are either un-published, unreadable, unrealistic or so far out of
date that no one really knows what they are (if they can find them) since
maintaining them is always a low-priority task when the development team is
overwhelmed with “real” requests.
Of course, if you ask the response is… “We don’t need them documented
since “all true professional, experienced and high-quality professionals know and
keep up with the really important standards, patterns and methodologies.” Or, occasionally someone forces someone to do
the paperwork and they are so highly documented, specific that it takes months
to even read them all and many are ignored just because the industry standards
changed, they deal with useless style issues and/or no one wants to update the
document(s).
And the code quality continues to morph into a heterogenous state
despite our best efforts, aspirations and ideals. If you throw in a few experienced
contractors who do it their way and a few more who just copy and paste code
from any source available and the code is now seasoned with a variety of
interesting flavors and code recipes that of course anyone can follow because
they are fully commented and the code is “self-documenting” … right? Hmm, less coding… looks great… hmm, it works
I can’t quite figure it out.
Does this sound familiar? Suddenly, someone in the organization
with enough authority and passion realizes the madness must cease, order must
be restored and rumors begin circulating that only a total uprising and strong
leadership can overcome the trend so that deadlines can be met and the swarms
of bugs and efforts to exterminate them can be controlled, managed and
eventually eradicated so peace can again reign between the business analysts,
customers, development and quality assurance teams.
So, the review and refactor revolution begins… it’s amazing
code snippets fly, inheritance and polymorphism are restored and of course
coupling is almost entirely eliminated by large doses of dependency injections
and inversion of control. Curly braces
align, indentations rule and in-code comments declare that “if this variable is
true we will function!”. We work in
parallel and our tasks return asynchronous results that of course are using “standard
result”. “That’s great, where can I find
the standard?”, the newest developer asks during the code review. The silence is deafening… Did he really ask
for that? Oh wait… that’s right we don’t need to document our standards, best
practices…
If this sounds familiar, it’s ok you are like most other
organizations and developers that have the same issue. I wish I could say there is an easy fix but
standards and consistency are like most other important items. They will cost you time and effort to create,
manage and maintain but are well worth owning and having. You can borrow someone else’s but usually
hand-me downs or borrowed items don’t fit or are out of style. Feel free to try an old pair and make them
yours or modify an existing set to fit your needs and requirements. As you do this, realize now that there are
some things that are too complex to be managed using a single standard or methodology;
and accept that some standards are like style. Some people have none and you don’t have to
like all styles! Sometimes, style or the
lack thereof just does not matter. Don’t
like curly braces, tertiary expressions or certain operators don’t use them. However, you must learn to allow others to
be creative if their way is clear, concise, functional, secure and performant! I often find that you don’t have to tell
others that your practice, pattern or method is better than any other. If it truly is that good, others will emulate
it and advocate it for you.
Regardless start now, persist your standards and post them
in a location that all can see. Feel
free to use build tools to examine the code and help enforce the standards. But remember, you must maintain them also and
have a plan or process for correcting the issues created as standards change. Make sure that before you try to review code,
architecture and the user interface.
Remember standards and best practices MUST be as agile as our
development environment and delivery.
They will and should change.
Focus more on ensuring that they are available for all to see and as
well maintained as your code and you will find working with a team and others
will be as amazing, exciting and enjoyable as your ideas and implementations!
Enjoy!