larlet-fr-david/david/blog/2017/resilient-web-tools/index.md

title: Resilient Web and Tools
slug: resilient-web-tools
date: 2017-01-14
lang: en
chapo: That’s part of my job to produce resilient websites.

> Changing a workflow or a process can be particularly challenging if it clashes with the tools being used. A tool is supposed to help people get their work done in a more efficient way. The tool should be subservient to the workflow. All too often, tools instead dictate a preferred way of working. Whether it’s WYSIWYG editors, graphic design programs, content management systems, or JavaScript frameworks, tools inevitably influence workflows.
>
> If you are aware of that influence, and you can recognise it, then you are in a better position to pick and choose the tools that will work best for you. There are many factors that play into the choice of frameworks, for example: “Is it well‐written?”, “Does it have an active community behind it?”, “Does it have clear documentation?”. But perhaps the most important question to ask is, “Does its approach match my own philosophy?”
>
> Every framework has a philosophy because every framework was written by people. If your philosophy aligns with that of the framework, then it will help you work more efficiently. But if your philosophy clashes with that of the framework, you will be fighting it every step of the way. It might even be tempting to just give up and let the framework dictate your workflow. Then the tail would be wagging the dog.
>
> Choose your tools wisely. It would be a terrible shame if you abandoned the resilient approach to web design because of a difference of opinion with a piece of software.
>
> Differences of opinion often boil down to a mismatch in priorities. At its heart, the progressive enhancement approach prioritises the needs of people, regardless of their technology. Tools, frameworks, and code libraries, on the other hand, are often built to prioritise the needs of designers and developers. That’s not a bad thing. Developer convenience is hugely valuable. But speaking personally, I think that user needs should trump developer convenience.
>
> When I’m confronted with a problem, and I have the choice of making it the user’s problem or my problem, I’ll make it my problem every time. That’s my job.
> 
> <cite>*[Resilient Web Design - Chapter 7](https://resilientwebdesign.com/chapter7/#Tools)* ([cache](/david/cache/c2ef2e0b15f1c7cd77e3740d06362a0b/))</cite>

The [Resilient Web Design](https://resilientwebdesign.com/) ([cache](/static/david/blog/ResilientWebDesign-portrait.pdf)) web book by [Jeremy Keith](https://adactio.com/) is inspiring, to say the least. I knew that it would be a good reading so I savoured it, one chapter at a time. Nothing really new but there is a moment in your life you realise that everything is cyclic and very old concepts are just going to be the next trend. Let’s call it maturity to stay polite and because I think [I reached it](/david/blog/2016/senior-developer/) :-P.

That particular extract of the chapter related to “Challenges” hit me. That’s part of my job to ease processes and reduce frictions. That’s part of my job to take into account from the early beginning of a product its lasting qualities. **That’s part of my job to produce resilient websites.** Resilient not only by the underneath concepts but by the technologies we put into practice to achieve our goals. That’s why I’m more inclined to use [Falcon](http://falcon.readthedocs.io/en/stable/) over [Django](https://www.djangoproject.com/) these days. It’s not anymore about [using the right tool for the job](/david/blog/2016/tools-teams/), I can do whatever I want with both frameworks. The difference will be building on one hand and deconstructing on the other. You have to be confident enough to start building and you have to deconstruct a lot to acquire it. This is a process you have to accomplish by yourself to be able to [identify complexity at first sight](/david/blog/2016/simplicite-defaut/).

> Good engineering involves finding simple solutions to sometimes complex problems. Repurposing code may make development easier, but ease of development is not the end goal.
>
> Developers need to continue to learn to code before they learn to include frameworks.
>
> <cite>*[You don’t need a framework for that](https://calendar.perfplanet.com/2016/you-dont-need-a-framework-for-that/)* ([cache](/david/cache/0b05758e1cf8bc51acba9e540e433278/))</cite>

As a [starter](http://jlongster.com/Starters-and-Maintainers) ([cache](/david/cache/0d7137e32d5ec9d0c301a72282e97c01/)), I have a responsibility to choose my tools wisely. I have to care enough about the maintainer and the [future team](/david/blog/2016/team-building/) as a whole. When you are coding public facing interfaces — like websites — you obviously have to care about your users too. It means identifying their needs and adapting constantly your product.

Even if I’m seduced by the [three‐step approach](https://resilientwebdesign.com/chapter6/#three%E2%80%90step%20approach) (I’m so jealous of these “clever” hashes!), I think it misses a fourth one: Mesure and remove. We spend our time adding features without considering *at the same pace* the removal of useless ones. And still the true resilience (or is it perfection [Antoine](https://en.wikiquote.org/wiki/Antoine_de_Saint_Exup%C3%A9ry)?) is when there is nothing more to take away. What are you removing on Monday to make our Web more resilient?