Un site qui référence les pratiques utilisés par les sites internets pour tromper leurs utilisateurs.

Un logiciel simple n'est ni intelligent ni stupide, il fait ce qu'on lui demande de faire, ni plus ni moins.
Paradoxalement, les logiciels deviennent stupides lorsque les concepteurs du logiciel tentent de rendre leurs produit «malin». En essayant de deviner ce que veut l'utilisateur pour lui faciliter la vie, le logiciel se retrouve dans de nombreux cas à faire exactement l'inverse de ce que veut l'utilisateur: le logiciel devient donc«stupide».

Le meilleur exemple étant bien sur les correcteurs orthographiques de téléphones, qui causent bien plus de dégâts qu'ils ne rendent service.
La «recherche intelligente» sur google n'est pas mal non plus: pour peut que la recherche porte sur un sujet un peu obscure, Google va automatiquement chercher autre chose.

Le dernier exemple en date de logiciel stupide auquel j'ai été confronté (et qui justifie ce billet) c'est le serveur mailing-list de Google : lors qu'on envoi un mail à une mailing-list à laquelle on est abonné, on ne reçoit pas le mail qu'on vient d'envoyer.
Je ne sais pas qui a eu cette idée, mais c'est probablement l'idée ergonomique la plus idiote de la décennie !

D'une part c'est un fonctionnement inverse de tous les autres serveurs de mailing-list, et rien que ça suffit à en faire une mauvaise idée: en brisant les attentes qu'un utilisateur a sur le comportement d'un logiciel, on se met dans la situation du logiciel stupide. Parce que coup, on n'a aucun moyen de savoir que le mail a bien été transmis, et l'utilisateur habitué des mailing-list sera même persuadé que son mail n'aura pas été correctement envoyé …
En plus, quand on revient sur une conversation vieille de plusieurs moi, le fait de n'avoir que la moitié de la discussion n'aide clairement pas …

Bref, amis développeurs et designer produits, par pitié arrêtez de faire des logiciels que vous pensez «malin», tout ce que vous arriverez à faire ce sont des logiciels stupides !

Dans cet article l'auteur explique que la dette technique n'a pas le même poids en fonction de l'endroit du code qui est codé salement. C'est presque pas gênant si c'est du code qui ne sera jamais touché, alors que c'est très coûteux si ça concerne une partie du code qui est amenée à évoluer souvent.
Sachant celà, il faut passer son temps à bien s'occuper de l'architecture des parties essentielles du code, quitte à aller vite sur les parties annexes.

Je suis globalement assez d'accord avec son propos, par contre je trouve la conclusion de son article vraiment très étrange : «Technical debt is ok, and often a solid product strategy. The importance is getting to market.»

Wtf ?! Non ! Au secours ne faites pas ça ! Oubliez cette phrase par pitié ! Ne perdez pas trop de temps sur des détails, certes, mais surtout ne vous dites pas que la dette technique c'est un levier ! La dette technique (la vraie, celle sur les parties essentielles du code qui bougent beaucoup) a un prix incommensurable ! Et contrairement à ce qu'on pense parfois, vous ne la payerez pas au bout de quelques années, vous la payerez dès lors que le premier employé (ou stagiaire) travaillera avec vous sur le code ! Qui dit code mal pensé, dit code difficile à prendre en main, et propice aux erreurs ! Si vous commencez à avoir du code tordu dans le cœur de votre application vous êtes partis pour des mois voir des années de galère, avec des bugs inexplicables qui apparaissent parce que quelqu'un a touché un bout de code dont il ne maîtrisait pas chaque ligne sur le bout des doigts.

Parier sur la dette technique comme levier de croissance c'est investir dans le druidisme comme système de gestion de la connaissance dans l'entreprise : transmission des secrets par voix orale du maître à l’apprenti … Inutile de préciser que ça ne passe pas très bien à l'échelle …

La discussion sur cette article ici est intéressante : https://news.ycombinator.com/item?id=9541134

Ahaha, une très bonne illustration de pourquoi les carrousels c'est de la merde !

Le service de messagerie Slack dispose d'une appli web, d'une appli desktop windows, d'une appli mobile pour iOS et d'une autre pour Android. Jusque là aucun problème. Comme j'utilise tous les jours leur application web je me suis dit «c'est cool qu'ils aient un appli web, comme ça je pourrai avoir l'application sur mon téléphone FirefoxOS». Je me disais qu'avec un peu de chance ils auraient une interface responsive basique, mais que même si ce n'était pas le cas je peux très bien me contenter ponctuellement d'une interface web de bureau sur mon téléphone.

Seulement voilà, chez Slack il y a des gros malins qui veulent à tout prix dissuader les gens d'utiliser la webapp sur mobile, et du coup ils font un gros blocage par user-agent. Tout ce qui n'est pas un navigateur desktop se prend une grosse redirection 301 des familles qui empêche le téléphone de charger l'application.

Bravo les mecs ! Bien joué !

Un petit coup de gueule contre le dogmatisme en Java : pourquoi vouloir absolument utiliser des attributs privés avec des getters et des setters dans tous les cas ?!

Edit : voir aussi ici http://www.javaworld.com/article/2073723/core-java/why-getter-and-setter-methods-are-evil.html