Engineering Ideas #10
Graph colouring to reduce data dimensionality, minimize alert rate, practice concentration, strategic technical debt
Graph Coloring for Machine Learning
Vlad Feinberg shares a simple technique to reduce the dimensionality of data through greedy graph colouring.
This can be quite a powerful tool for working with structured data, whether doing diagnostic analysis, supervised learning, or modeling.
What's not Actionable & Business Critical Shouldn't Ring: Building the Right Alerting System
The title of Fred de Villamil’s post says it all. I experienced exactly the same problem at one of my previous jobs. Fixing alerts is not just nice-to-have, it must be a top priority:
After a few months, I can tell reducing our alerting rate should have been a top priority before things got out of hands, for a few reasons.
Constant alerts prevented the team to focus on what was important. Being interrupted even for things that can wait for a few hours lowers our productivity when we work on things that can't wait. [Reminds me of focus erosion as one of the top software development’s mistakes]
Being awaken every night, several times a night exhausts a team and make people less productive at day, and more prone to do errors.
Too many off hours interventions cost the company a lot of money that could be invested in hardening the infrastructure or hiring someone else instead.
I would also add to the above list, is that when there are too many alerts, real problems are ignored.
Replace backend-oriented alerts with functional probes
For every component, we asked ourselves a simple question.
If we lose this, can it wait until the next morning or next Monday?
When answer was "yes", alert thresholds were lowered. A "no" often meant we lack functional probes, so we added them.
Sir William Osler’s Advice to Students: Practice Concentrating on Hard Things
Cal Newport brings up an inspiring quote:
“Let each hour of the day have its allotted duty, and cultivate that power of concentration which grows with its exercise, so that the attention neither flags nor wavers, but settles with bull-dog tenacity on the subject before you. Constant repetition makes a good habit fit easily in your mind, and by the end of the session you may have gained that most precious of all knowledge—the power of work.”
— William Osler
Newport continues:
Modern educational institutions care a lot about content: what theories we teach, what ideas students are exposed to, what skills they come away knowing. But we rarely address the more general question of how one transforms their mind into a tool well-honed for elite-level cognitive work.
Myself, I don’t try to deliberately train concentration, which I should probably start to do.
Managing Technical Debt
Steve McConnell notes that technical debt is not always a bad thing:
Just like financial debt, some technical debts can serve valuable business purposes.
Strategic technical debt
Strategic technical debt is a visible chunk of debt (e. g. suboptimal solution which causes developers inconvenience every time they develop some task or keeping supporting old system which would properly be replaced with a new one) which is taken intentionally.
McConnell identifies three reasons for taking technical debt strategically:
Time to Market. When time to market is critical, incurring an extra $1 in development might equate to a loss of $10 in revenue.
Preservation of Startup Capital. If it can delay an expense for a year or two it can pay for that expense out of a greater amount of money later rather than out of precious startup funds now.
Delaying Development Expense. Once a system has been taken out of production, there’s no difference between a “clean and correct” solution and a “quick and dirty” solution. [Reminds me of Tyree’s and Akerman’s idea of delaying architecture decisions as much as possible.]
Articulate why you are repaying technical debt
If a team’s level of technical debt is such that it can’t promise specific business benefits from paying off the debt, then it’s always possible that the debt isn’t worth paying off.
Reminds me of the idea of always working on the highest leverage things from The Effective Engineer, and the idea of “programmer’s mindfulness” from The Pragmatic Programmer:
Reflect on your work, every decision you make, every project. Never run on autopilot. Critique your work in real time. Mantra: “Think”.
Unfocused technical debt is never worth taking on
… debt accumulates from taking hundreds or thousands of small shortcuts—generic variable names, sparse comments, creating one class in a case where you should create two, not following coding conventions, and so on. This kind of debt is like credit card debt. It’s easy to incur unintentionally, it adds up faster than companies think, and it’s harder to track and manage after it has been incurred. We’ll call this “Unfocused Short-Term Debt.” […] this kind of debt doesn’t pay off even in the short term of an initial development cycle and should be avoided.
This reminds me of an idea from The Pragmatic Programmer:
Don’t leave “broken windows”: bad designs, wrong decisions, poor code. If there is no time to fix them immediately, board them up: turn off functionality. Neglect accelerates software rot faster than anything else.
Don’t cause collateral damage: unmanaged, unaccounted technical debt in times of deadlines or firefighting.
Try to find a “golden mean” third alternative
Teams often turn the technical debt decision into a simplistic “two option” decision—good path vs. quick and dirty path. Pushing through to a third option is important because often the best path is the one that is fairly quick, albeit not as quick as the pure quick and dirty path, and whose adverse effects are better contained than those of the pure quick and dirty path.
This is a false dichotomy.
Steve McConnell’s ideas seem to be coherent with Ron Jeffries’ ones in his article ↓
Technical Debt
Jeffries argues that “benign” technical debt comes from our realization of suboptimality of our previously chosen design, or when requirements change, but we decide not to change the code (immediately, or ever) because the benefits don’t justify the cost of a switch.
Jeffries seems to agree with McConnell (and also Thomas and Hunt) that deliberately writing poor code is never a wise decision:
Unfortunately, today, “technical debt” has often come to mean something like “judiciously skimp on design today, so that we can go faster; we’ll clean it up later”.
In my view, there is no useful meaning for “judiciously skimp on design today”. Every design flaw we leave in the system today will slow us down tomorrow.
To go fast, we have to go clean. Dirty code isn’t technical debt. The surgeon can’t usefully save time by only sterilizing some instruments. We can’t usefully save time by writing sloppy code. That’s not technical debt. That’s sabotage.
Thank you for reading!
You can subscribe to new Engineering Ideas via RSS (e. g. using Feedly) or e-mail.