Sitecore and .NET are staples of the True Clarity diet, so to speak – we are both a Microsoft partner and a Sitecore partner, and we’re using these technologies to do some very cool things! Outside of these, most of the developers here are comfortable using a few other frameworks and libraries such as NUnit and jQuery, but are we really being adventurous enough with the technologies we’re using? I’d argue that we aren’t (yet), and I’d imagine the same goes for plenty of other developers elsewhere.
Why should we be more adventurous?
To help illustrate, here’s an example of a jQuery accordion (minus the styling) which I’ve thrown together for the purpose of this post:
<ul class="accordion">
<li class="accordion-panel">
<h3 class="accordion-header">
<a href="#">SitAmet Security 2.0 (Awesome Edition)</a>
</h3>
<div class="accordion-content">
Lorem ipsum dolor sit amet
</div>
</li>
<li class="accordion-panel">
...
</li>
</ul>
...
<script type="text/javascript">
(function ($) {
$(function () {
$('.accordion-content').each(function (index) {
if (index > 0) {
$(this).hide();
}
});
$('.accordion-header').click(function () {
var content = $(this).parent().find('.accordion-content')[0];
$('.accordion-content').each(function () {
var $this = $(this);
if ($this[0] === content) {
$this.slideDown('fast');
}
else {
$this.slideUp('fast');
}
});
});
});
})(jQuery);
</script>
So, is it any good? Well it works, the markup is reasonably semantic, the Javascript is nicely wrapped and I’ve seen very similar accordions get deployed to QA (e.g. by yours truly). But there are still a lot of unanswered questions about this piece of code, for instance:
- How flexible can we make the markup without breaking the Javascript?
- How easy is it to change the slide speed or the default content panel?
- Will it work with multiple such accordions on the same page? (Nope)
- Does it do anything unexpected? (Yes, it jumps to top of page when you click – href=”javascript:void(0)” is much better for Javascript anchors)
- Does it conform to accessibility guidelines such as AA and ARIA? (Note – maybe it doesn’t have to, but it’s certainly not a bad thing if it does!)
- Does it work in IE6 and on an iPad? (See the above note)
- Does the markup lend itself to looking consistent with your fancy custom dropdowns sitting next to it?
- How gracefully does it fall back without Javascript?
All these questions will likely be asked at some point, whether by a fellow developer, a tester or the client. Sometimes the answer will be “it’s fine”, but often it won’t be, and this contributes very significantly to the overall development time and cost of the piece of work. Additionally, bugs will occasionally slip past QA and UAT and only be spotted once it’s on a production environment, resulting in less client satisfaction and more time spent fixing bugs, which is neither fun nor profitable for anyone!
By contrast, a plugin such as the jQuery UI accordion has had countless eyes on it and many man hours spent turning it into a robust, reusable and flexible piece of code that’s already proven its worth on many commercial websites. Remember when IE6 was playing peekaboo with you? Or when you accidentally used an ID instead of a class in your jQuery selector? Well, these little annoyances have all been ironed out for you – why open yourself up to them again by trying to reinvent the wheel? It’s a classic case of “work smart, not hard”.
While I’ve used a UI example here, this applies to any area of coding, whether it’s an accordion, a search index or a Sitecore module. Which frameworks and libraries to use may be a matter of business requirements or personal preference but there’s certainly no shortage of options to explore.
So what’s holding us back?
One reason is what I refer to as “my code is awesome” syndrome. There’s a natural tendency to attach extra value to your own code just because it’s “yours”. Granted, you may feel more comfortable working with your own code, but to think that no-one else can write good code is pretty silly. How awesome did my accordion end up being, compared to the plugin? Not very!
Of course, it’d be rather cynical to think that every developer has an ego problem (those are in HR, ahem…). There are plenty of other reasons, the main one being unfamiliarity and its immediate consequences. When you’re pressed for time it can be difficult to justify setting aside some time for investigation (e.g. a spike), but when you consider the amount of time it can save it really becomes a no-brainer. Though this is typically viewed as more of a long-run reward, the investigation and learning time will often pay for itself within the scope of the current piece of work. A much-overlooked fact is that the back-and-forth of a piece of work between Dev, QA and UAT often dwarfs the initial development time, and that’s the main reason why this approach can provide such great benefits.
It’s worth noting that even if a library or framework doesn’t quite do what you need (or doesn’t do it as elegantly as you would like), it may still be your advantage to beat it into submission and adapt it to suit your needs. At True Clarity we have done this very successfully on several occasions! Often however, it’s a case of simply doing some investigation to find out what does and doesn’t work well out-of-the-box.
Sometimes you may not even realise a library exists for the task at hand or that it’s an appropriate time to look for one. But if you find yourself, say, copying and pasting hundreds of lines of SQL and data-mapping code that does basic CRUD operations, that should set off alarm bells! A quick Google search will bring up plenty of widely used object-relational mappers: NHibernate, ActiveRecord, Linq to SQL and Entity Framework to name just a few. You may not have used an ORM before, or even have known what an ORM was, but whenever you find yourself doing something boring, fiddly or repetitive, there’s a good chance that plenty of others did too and found a way to tame it. Those people may even be sitting right next to you and may have a robust in-house solution that you just haven’t used before. But to find the right answers, we have ask the right question: “Is there an easier way of doing this?”. If I were writing that accordion on a real project, it could easily have slipped my mind to ask that question, and that’s a habit that needs to be broken.
How can we make this easier?
As always, Google / Bing / <insert search engine here> is your friend and ally. But there are other ways to explore all the options out there: asking a fellow developer (whether sitting next to you or on a site like Stack Overflow) is often a great start. For .NET developers specifically, NuGet is an excellent way to try new things: if you’re looking for a search library for instance, simply type in “search” and all the most popular options will be a single click away. The fact that NuGet takes care of adding (or removing) the necessary DLLs, dependencies, references, and bits of configuration is absolutely invaluable and takes away a lot of the friction involved in trying out new libraries. Not a fan of the library you’ve just tried out? Just click “uninstall” and try the next one on the list!
But what about the learning experience?
None of this is to say that you shouldn’t bother trying to understand how these libraries and frameworks work behind the scenes – that’s still very important from a learning perspective! But as developers in a professional environment I feel we need to focus more of our efforts on learning to use third-party code and integrate it effectively – we certainly shouldn’t be spending a significant percentage of our total development efforts on re-writing, testing and fixing common pieces of code that are already freely available (or available at a fraction of the cost of developing it from scratch). So I think it’s time we really embrace this approach and make a habit of saying “I’m going to do something awesome with your code.”
True Clarity 