You know you’re in for an interesting conversation when the first sentence you hear starts with “I know it’s against industry best practice but….”.
Know, there’s nothing wrong with going against the “industry best practice” if you’ve got a good reason. I’ve been there many times, with good reason. …. Can you pick my favourite word here??? “Reason”.
If I’m looking at your design, best practice or not, then I’ll probably want to know what reasoning lead to this final design. I’ll want to know what other options were considered and what the pro’s and con’s were.
If you’ve chosen to go against the grain and implement something which isn’t best practice then that’s all the more reason why you should provide the reasoning for it. You can bet that almost everyone who looks at your design is going to say “Ummm … why did you do it that way? Best practice would be to … “. So instead of repeating yourself, provide some reasoning for your design. Create a “Design Rationale” document and just use it as your reasoning and assumption register as you’re ploughing through the design. At the very least it will be a great reminder for yourself when you come back to look at your design in 2-6 months time when the new guy on the team wants to talk about how the system is put together. 🙂 It’s also great for the team when you leave and it makes getting an assessment / second opion much easier.
One last note. If you come across a design that is not best practice… don’t just immediately dismiss it as being wrong. It just may be the case that some clever people had very good reasons to do it another way. Maybe.