Geeks With Blogs
AJ Warnock This Page Left intentionally Blank

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!

Posted on Monday, January 23, 2017 10:34 AM Coding Practices , Standards | Back to top


Comments on this post: Rule 1 - My way is always the best... Rule 2 - when it's not see Rule 1.

# Standards?
Requesting Gravatar...
I would love some standards, best practices, whatever. But, how to get started after inheriting an old application that looks very consistent, but needs major changes that go outside of what the original create envisioned?
Left by Benjamin Cuningham on Jan 23, 2017 4:31 PM

# re: Rule 1 - My way is always the best... Rule 2 - when it's not see Rule 1.
Requesting Gravatar...
Sorry for the slow response...

Well, you just have to pick an area and begin. The code will never be up to 100% of the current standards and you won't be able to go get it all up to standard at once. Set priorities and plan. Present the new scope and updates then get BUY-IN from the owners/customers before you start. Limit the impact of the initial deliverables but develop a plan to roll out to the whole application.

Remember, keep the initial part small incase it ends up not being acceptable and you have to throw out the work... It happens that is how we learn and sometimes the knowledge gained justifies the time and efforts of a throw away deliverable.

BUT you will never get anywhere delaying the start because it is a large task or an unknown completion date. Never know till you try it...
Left by ajw on Feb 09, 2017 10:34 AM

Comments have been closed on this topic.
Copyright © AJ Warnock | Powered by: GeeksWithBlogs.net