software

Excessive complexity is nature’s punishment for organizations that are unable to make decisions. — Gregor Hohpe in The Architect Elevator You can trace its origin to my original blog post on IT complexity from 2018.

Dr. Nicole Forsgren is a developer productivity and DevOps expert who works with engineering organizations to make work better. Best known as co-author of the Shingo Publication Award-winning book Accelerate and the DevOps Handbook, 2nd edition and author of the State of DevOps Reports, she has helped some of the biggest companies in the world transform their culture, processes, tech, and architecture. In today’s podcast, we discuss: Two frameworks for measuring developer productivity: DORA and SPACE Benchmarks for what good and great look like Common mistakes to avoid when measuring developer productivity Resources and tools for improving your metrics Signs your developer experience needs attention How to improve your developer experience Nicole’s Four-Box framework for thinking about data and relationships Chapters...

I fucking hate Jira. Real opinions from real people about a project management system which unfortunately is also real. “Jira isn’t bad if setup in a lightweight fashion” is a 🦄 argument. If something is customisable, people will customise. Jira is the MySpace of issue tracking systems.

Pop quiz about PHP and something we’ve stumbled upon last week, while working on a client’s codebase. ...

A real story of how following good security practices is both easier to do than ad-hoc methods, and it spreads quickly to others.

[{width="410" height="410" srcset="linkedin-2a383b27-dc7c-4632-820f-8d9dab9c576f-large.jpeg 410w, linkedin-2a383b27-dc7c-4632-820f-8d9dab9c576f-large-150x150.jpeg 150w, linkedin-2a383b27-dc7c-4632-820f-8d9dab9c576f-large-300x300.jpeg 300w, linkedin-2a383b27-dc7c-4632-820f-8d9dab9c576f-large-268x268.jpeg 268w" sizes="(max-width: 410px) 100vw, 410px"}](linkedin-2a383b27-dc7c-4632-820f-8d9dab9c576f-large.jpeg) Como você quer o seu projecto? Rápido & Grátis → Lixo Rápido & Barato → Mal feito Rápido & Qualidade → Bem pago Barato & Qualidade → Não pode ser rápido Grátis & Qualidade → Faça você mesmo Escolha duas!… Três ou não existe ou é utopia.

{width=“562” height=“388”} By version 4.11, transitive dependencies have proliferated seemingly unchecked. We are far from the short dependency-chains and few cyclic-dependencies of good structure. A better way… There are many ways to do this, but one way is to practice radial encapsulation . (…) shows the evolution of a radially-encapsulated program that is bigger than JUnit yet has throughout its history retained a structural clarity that JUnit seems to have abandoned....

Programs must be written for people to read, and only incidentally for machines to execute. Hal Abelson and Gerald Jay Sussman in MIT Structure and Interpretation of Computer Programs course (via Brevity vs. Clarity · An A List Apart Blog Post )

{width=“598” height=“337” srcset=“tumblr_nk2ojojvBA1qz82meo1_1280.jpg 598w, tumblr_nk2ojojvBA1qz82meo1_1280-300x169.jpg 300w” sizes="(max-width: 598px) 100vw, 598px"} Nice illustration of the writing process, or any other creative/development endeavor, for that matter. Original Tweet: I love this illustration of this writing process. From Nicely Said book. pic.twitter.com/w5ccIVsrNX — ★ Sean Johnson (@seanuk) February 20, 2015 TODO: Link to the book source?

The problem? For example, 3 guys wrote a paper in 86 and they said that a good estimate is an estimate that’s within 25% of the original estimate, 75% of the time … so, mostly one quarter wrong . Yikes, not a very good prospect at all. The gist of #noestimates to determine how much scope can be delivered by a given date: Select the most important piece of work you need to do (highest value first) Break that piece of work down into risk-neutral chunks of work: (…) small enough that failing to deliver it at first attempt will not jeopardize the project [typically ~1 day chunks] Develop (…) Deliver that work to a production-like environment....