Luke Plant:
The “pile of technical debt” is essentially a pile of knowledge – everything we now think is bad about the code represents what we’ve learned about how to do software better. The gap between what it is and what it should be is the gap between what we used to know and what we now know.
↬ ∙ Tagged in Software Engineering.
]]>Sean Goedecke:
This is why tiny software companies are often much better than large software companies at delivering software: it doesn’t matter that the large company is throwing ten times the number of engineers at the problem if the small company is twenty times more efficient.
Why don’t large companies react to this by doing away with all of their processes? Are they stupid? No. The processes that slow engineers down are the same processes that make their work legible to the rest of the company. And that legibility (in dollar terms) is more valuable than being able to produce software more efficiently.
↬ ∙ Tagged in Software Engineering, Work Culture.
]]>Vojtěch Rylko and Werner Jainek:
Our legacy Things Cloud service was built on Python 2 and Google App Engine. While it was stable, it suffered from a growing list of limitations. In particular, slow response times impacted the user experience, high memory usage drove up infrastructure costs, and Python’s lack of static typing made every change risky. For our push notification system to be fast, we even had to develop a custom C-based service. As these issues accumulated and several deprecations loomed, we realized we needed a change.
They chose to rewrite using Swift on the server.
↬ ∙ Tagged in Software Engineering.
]]>Some nice tips in this.
↬ ∙ Tagged in Software Engineering, Tools.
]]>Jeremy Morrell:
Adopting Wide Event-style instrumentation has been one of the highest-leverage changes I’ve made in my engineering career. The feedback loop on all my changes tightened and debugging systems became so much easier. Systems that were scary to work on suddenly seemed a lot more manageable.
↬ ∙ Tagged in Software Engineering.
]]>Fascinating deep dive into hitting and overcoming the scaling issues affecting the sync engine Linear built.
↬ ∙ Tagged in Software Design, Software Engineering.
]]>Tony Stubblebine:
Many things at Twitter were broken to the point that they could bring the entire site to a halt. Greg’s strategy, now distorted through multiple retellings and my own foggy memory, was to focus on short-term triage rather than long-term fixes.
Essentially, he realized that a collection of temporary, duct-taped fixes was the only thing that would give the Twitter team the breathing room to start working on longer-term fixes.
I think of this in school grade terms. Greg went looking for all the Fs and then turned them into Ds. Then he turned all the Ds into Cs and then all the Cs into Bs, etc.
↬ ∙ Tagged in Processes, Productivity, Software Engineering.
]]>Skills that lead to good code stewardship.
↬ ∙ Tagged in Management, Software Engineering.
]]>Miriam Posner:
You could say, then, that by the late 1960s, software development was facing three crises: a crying need for more programmers; an imperative to wrangle development into something more predictable; and, as businesses saw it, a managerial necessity to get developers to stop acting so weird.
↬ ∙ Tagged in Software Engineering.
]]>Dan North:
The five CUPID properties are:
- Composable: plays well with others
- Unix philosophy: does one thing well
- Predictable: does what you expect
- Idiomatic: feels natural
- Domain-based: the solution domain models the problem domain in language and structure
Also this belter from Martin Fowler.
“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”
↬ ∙ Tagged in Software Engineering.
]]>Dan North:
The purpose of testing is to increase confidence for stakeholders through evidence.
…
You are testing if and only if you are increasing confidence for stakeholders through evidence.
↬ ∙ Tagged in Software Engineering.
]]>A look at how Etsy tailored their search results to individual customers.
↬ ∙ Tagged in Software Engineering.
]]>George Fairbanks:
There are two parts to software development: creating a design and expressing it as code. The code is tangible but the design is conceptual. Keeping a project healthy means doing both well. Here’s my concern: whenever you mix the conceptual with the tangible, it’s easier to neglect the conceptual. When you miss a tangible target, it’s obvious, but when you miss a conceptual target, you might not recognize it, or might rationalize that, because it’s impossible to measure, you were really quite close.
Blindly applying a factory process to software development will drive improvements to the tangible part (the code) at the expense of the conceptual part (the design). We see plenty of examples of this today, where teams have great feature velocity at first, are puzzled when velocity slows, and eventually the project is abandoned. As Cunningham warned, if we bolt features onto an existing codebase without consolidating those ideas into the code, the design will suffer, and over time “[e]ntire engineering organizations can be brought to a standstill under the debt load of an unconsolidated implementation.”
↬ ∙ Tagged in Software Engineering.
]]>A curated collection on the missing aspect of managed time in programming.
↬ ∙ Tagged in Software Engineering.
]]>Lovingly craft those commits, friends.
↬ ∙ Tagged in Software Engineering.
]]>