(Note: this article was previously published in French a few days before this translation –if you have any feedback on the translation made by Gaël Poupard, Nicolas Hoffmann and Tanguy Martin, please let us know.)

On the Web, you find everything. "Google is your friend", as the ancients say. But if you’re working "in" the Web, these findings have a crucial role in your production.

Let us start from a simple premise: we are being faced with a peculiar problem - as they all are. If this is the first time we’re encountering this issue, what do we do? We are looking on the Web. Indeed, the problem will already have very likely been solved in various ways, leaving a mark on the Web.

And this is where our story begins - influenced by various factors such as production time, existing constraints, our work habits or our dedication. Let’s plan for the short, medium and long term in two alternatives of this story of which we’ll be heroes!

Spacetime #1

Let’s start from beginning: searching for a solution. Your guess: our first try returns hundreds of thousands results.

Being finical, we’re now filtering those results. Recent ones only, no location, and let’s put a more accurate search term. Nice ! Only a few thousands results returned.

A quick overview of the first page and some ideas are already appearing. Open a new tab per result. Starting with a fast reading of each one, we can see that some of them looks the same and may quote each other. Moving on, we close a few tabs after reading a bit further a few results that don’t seem to match our need after all.

Among the survivors, a solution catch our attention because it seems to really solve our problem. We’re being lucky: this post is well-written, documented and illustrated. It could have been a thread on StackOverflow pointing to W3Schools! Last overview to confirm that this solution will do the trick, and here we go!

Let’s get on our favorite code editor, and apply precisely the tips our helper gave. We now add suggested scripts and styles, adapt classes and IDs to our DOM and… It works!

Well, this behaves as expected. Pretty nice, isn’t it? However IE8 does weird things… But hey, it still works! A bit overweighted though, but no one will mind when it is minified and gzipped. Relatively to the little time spent, it’s very efficient - and we appreciate it! The project manager too, by the way.

This a real quick win, as we could have spend a long, long time starting from scratch. We saved our time, and the project manager is satisfied, as well as our client. Let’s start the next task!

However

Shipping the project went without any issues. Our client is very pleased, and the project manager close this case. Nevertheless, this way of working exposed us to some Non-Quality Costs (NQC).

• Two weeks later, the client forwards a few mails sent by some users, and their bugs are pointing straight to our solution. It seems to fail in some rare cases, and that’s not easy to patch;
• A month later, the new version of Firefox made a little move backward handling our specific point. We open an issue on the solution’s Github repository, but no answer. This seems odd and pretty hard to fix;
• Six months later, a contributor wants to create a new page with fancy effects. Bad luck, that script he just added completely blew up our solution. We’ll have to digg deep to untangle this;
• A year later, our client needs a new certification but its website has to be WCAG 2.0 valid. Unexpected. This quotation shall be costly as our solution cannot be well-address;
• Two years later, a new project needs the same trick. Crap. Our successive patches are annoying: we’d better go back to the original solution. But where did we find it?
• Three years later, due to a flattering offer, we quit this job. Our successor - while being more qualified than we are - is in trouble when it comes to maintain and fix our solution. It has already been patched four times to improve its accessibility and its compatibility, and is now unreadable, unmaintainable and really heavy. That’s why our dear successor decides to redo everything from scratch.

Spacetime #2

Let’s start from another beginning: let’s test this problem in all possible ways. How is this specific? What do we want to get? Do we have any dependencies, prerequisites, particular compatibilities, blacklist of tricks? Should the solution be reusable?

Now - and before we start our quest - let’s sketch the perfect solution. Ideally, it easily fixes our problem, doesn’t need any extension or heavy modification of our existing structure. Being lightweight and accessible would be a good thing, too. Doesn’t seem incredible, but we’ll see what the Web has in stock.

Well… First results all sound funny. We should precise our search terms: targetted language, "accessible" keyword, and we’ll search in two major languages: rench and english. Here we are! Far few results, and we avoid W3Schools and friends. From now, and randomly because we need to keep moving, we’ll open every first page results for our two requests - and we’re going to read’em all!

Not only are we going to thoroughly read those results, but we shall map them as a mindmapping - in order to gather key concepts of those solutions. This way, we’ll be able to list all the possible solutions, detail their pros and cons, and maybe some of them will be complementary, who knows?

And, indeed, a lot of similarities are emerging, and each search result is being useful in its own way. Time to dig deeper!

We’re not going to mess it all, so let’s start by creating a dedicated file in the targeted language. We now include the file in our ongoing project, and "Voilà" ! We can begin to write some code. We organize our file properly (as usual) then we slowly build the mechanism deduced from our previous researches, sticking to our code guidelines. And obviously, we are commenting every snippet with details, quoting our sources.

First attempt. Nope, we’re missing something. Reading again that code, comparing to our notes and overflying the search results, we now observe that two parts are in conflict. A quick refactoring later, and… It works!

Well. Let’s go ahead. What about other browsers? Firefox: check. IE11 : check. Safari : check. IE8 : check. Not too bad for a first draft! Now let’s compare our file to the perfect solution we had sketched, remember? Yeah, that’s okay. We could improve those two specific points, however. Let’s give it a try. We search again on our favorite search engine about those particlular points. Indeed, some improvements can be made! Here we go, with a bit more thinking we get a better solution.

Let’s do more tests: every targeted browsers, supported screen sizes, disabled scripts and styles, without images, in high contrast mode... Perfect, it works in all cases! We end up documenting our file, specifying the test cases, the date and a few contact points. That’s it!

Secondarily, our solution is merging many other ones and seems more straightfoward and effective at the same time. That is worth to be shared! We upload it to our Github repositories, then after quoting initial solutions in the README file, we can notify their authors.

We’ve certainly spent more time than if we had simply applied a ready-to-go solution, but both sharing our work and the feeling of accomplishment are enough to give us some more serenity.

However…

It’s not a wonderful solution, as we’ve gone through some COQ. Setting this solution up took a whole day of work, when the issue could have tackled in two hours. As a result, even if we could hear the project manager starting grumbling, he was finally persuaded of of the legitimacy of our approach.

By the way, we should consider ourselves quite lucky: if the technical solutions we had discovered were too far from our skills, we would have needed much more time to upskill and come with a decent solution.

Similarly, should our ideal solution have been too ambitious, we would easily have wasted valuable time fighting the wind. And maybe this was the case, who knows?

These tricky bits can be hard to avoid when one feels confident in their work.

Conclusion

This topic is mainly a way of perceiving his work: either a long-term investment during which we eternally improve ourselves (Kaizen), or a continuous questions and answers sequence. Everyone needs to make the choice, but obviously nothing is absolute and sometimes you may have to adjust your position.

To be clear: occasionnaly you may not have the choice. Urgent modifications to be done on a live server, hotfixes for a huge security flaw - or a request to develop a high level in-house solution from scratch as soon as possible. It’s natural, and we all have to deal with these.

However if you systematically choose the same side, you’re probably mistaking from time to time: overquality in case of perpetual research of improvements, or exponential technical debt in case of passive solutions (copied and pasted) over and over again.

Intermediate cases occures and it’s possible - even more, desirable - to set boundaries according to your day-to-day professionnal context. In a small agency, capitalizing on researches can’t be done regularly since new works arrive all the time. On the contrary, in a large-scale company working on a single product, it would be stupid to copy and paste a result found on first page of Google.