The first week of August has come and gone. This week went by in a blur; I actually can’t remember where the bulk of my time went, but I know it wasn’t idling.
It’s a reminder to slow down a bit and take inventory. Being busy isn’t the same as being productive. (And to me, “being productive” means making cool stuff happen)
This week there are some noteworthy happenings. I reached phase 1 of my blog redesign, my next technical post is just about ready, and I have some topics lined up to write about.
For today, I have the redesign to share and an interesting article on software debt.
Redesign Soft-Launch 🚀
Over the last month, I’ve redesigned my website, which includes adding a newsletter and feedback form. I launched that this weekend and plan on improving it as time goes on. It will be a web garden of sorts.
Designing the site myself has been a nice experience. It’s rebuilt some of my confidence in putting a site together from scratch. Spacing, font sizing, and color pallets give me a bit of stress.
There’s a bit going on behind the forms too. They have some extra measures put in place in an attempt to make them fault-tolerant. We’ll see how that works out.
If you can’t tell, I have a fondness for a certain shade of green. I use something similar for my Diablo III flag.
I’ll change up the homepage sometime soon so that it’s easier to find relative content. As it is right now, there’s a lot of scrolling involved in seeing what content is available.
Software Debt 💰
This week I came across an interesting article titled “Technical Debt Is Not Debt; It’s Not Even Technical” by Mark Greville, and it got me thinking.
Technical debt has been a prominent thing for me over the last year. Last year, there was the EOL of Python 2.7, server upgrades, dependency upgrades (including frameworks), and the upcoming Drupal 8 EOL.
This has been my life for the past 9 months. 😱
So first off, I think Arvid’s first sentence is tricky. I believe it’s meant as “Technical debt does not mean bad code, but bad code is a type of technical debt.”
If some code is poorly designed and left alone, it definitely will accrue “debt.”
Types of Debt 💳
So is it technical? This depends on whether we consider only the originating action, or the consequences that follow.
Technical Debt Is Not Debt; It’s Not Even Technical, Mark Greville
I think this is really important to consider and explore. It’s actually a piece of reasoning that you need as an engineer to communicate to non-technical managers/product owners/others to help them understand why maintenance needs to be done.
If maintenance isn’t done, how does that affect the business? Is it a detriment to the customer’s experience? Does it become an impediment for other teams?
It’s actually really easy for software debt to creep up and either slow down the delivery of a feature or even cause the project to be put on hold or canceled. 😢
This article includes a reference to a study titled “A Systematic Mapping Study on Technical Debt and Its Management,” which includes a really interesting break out of debt types:
- Requirements
- Architecture
- Design
- Code
- Test
- Build
- Documentation
- Infrastructure
- Versioning
- Defect
(Section 4.4.1. TD Types)
I think security (incl. cybersecurity) should also be in there, but it could also fall under infrastructure.
What I find really neat about this break-out is that requirements, design, build, and documentation are included.
I think it’s always good to look beyond just the tech and see what you’re building as a product that a customer will use. Like the libraries and frameworks, we work with that are always evolving and changing, so is the business landscape. And it can do so very quickly too, which makes it important not to get snagged by things like debt.
What’s Next
I’ll be pivoting away from maintenance (finally) and putting more time into development. I’ll most likely be getting further into microservices.
Picks
DefCon 29 was last week, and there’s a collection of talks and workshops available online. The talks appear to be up on the DefCon YouTube channel while workshops are on Eventbrite.
This is the first year I’ve really looked into the DefCon content; I’ve thought it was more of an IT thing, like networking, cybersecurity, and other non-programming things.
I have a few I plan to check out and will share if I find they are relevant.