Igloo Developer Relations works with partners and customers who are developing extensions or solutions that fit their specific needs. We also build solutions ourselves to solve problems for customers – both internal and external.

There are times when a low-level solution to a high-level problem can seem daunting – How do you solve for X when you have to think about A through W?

 We’ve adopted three simple rules that we follow whenever we’re creating a solution that helps:  

Someone, somewhere has done this before.
(or... Don't Reinvent The Wheel)

While there are times when we experiment with ways to solve a challenge, more often than not, someone else has had to solve this exact problem before – and very often the solution already exists in a library.  

For example- we recently needed to build an internal tool to resize images. We could very easily have built a tool to do this from scratch, but so many third-party libraries existed that we were able to take one and build our solution using that.  We were able to bring our tooling to use faster, with less to worry about when creating our test suite.  

Don’t overcomplicate things – simple is better.
(or… Use the right tool for the job)

The simpler the solution is, the faster it will make it to production, the easier the testing will be and the more comprehensive the documentation will be. Not overcomplicating a design can be challenging, especially if you’re trying to ‘cover all of your bases’.

Does the solution absolutely need this?  What is the minimum viable solution that we need to provide? What parts will need to change for future growth or additional features? Will these changes break existing logic? There’s often no way to truly avoid technical debt, but thinking ahead can help mitigate some of it. It's all in the planning!

Of course, this depends on ensuring that you’re solving problems that actually need to be solved, and not inviting “The Scope Creep” to your coding party.

Which leads us to the third rule:

Beware “The Scope Creep” – Define Done
(or... do we really NEED a nuclear powered toaster?)

The Scope Creep is a nasty little guy. He climbs into your project and starts adding things until what you wanted to do at the start no longer resembles what you’re actually doing.  Avoid him at all costs!

At the onset of your project, define your end state – and stick to it. There’s nothing wrong with adding a new feature or function in a later release, as long as the initial goals are met in the initial project.

When we plan out an integration, one thing we avoid as much as possible is replicating the functionality of a third party tool entirely. Some things can be simply iFramed in, others might require an API call for summary information or partial functionality. In some cases, the simplest solution is simply to link to the third party application or service. Considering they’ve invested considerable time, effort and energy in developing their service, it would in many cases be foolish to attempt to reproduce it. They’re the experts!

Even when looking at extending Igloo’s native functionality, one of the first questions we ask is “Can we not do this out of the box?” – as it’s sometimes simply a matter of demonstrating how to accomplish something using native, supported tools.

 Regardless, when approaching a solution- ensure that you define your end goals clearly.

We came by these “rules” quite by accident – they’re typically best practices for any developers, but we invoked these so often that we made them our team’s “mantra”.

In an upcoming post, we’ll describe a Proof Of Concept we’ve built, and how we applied these three rules to the project.