Posts on Yet Another Dev Blog

The real AI threat - it doesn't need to be good to destroy your business

Thu, 30 Apr 2026 12:16:33 -0800

Disclaimer I’ve used AI coding tools daily for two years. I used ChatGPT to help write this series. If you think my conclusions are a skill issue, I suggest you ask Dr Flattery The Compliment Robot what that might say about you

Given the stakes, it’s perfectly natural to be concerned about AI. Given the stench, it’s perfectly natural to suspect bullshit. In this first part of a two-part rant, I will take a look at the bottom of our collective shoes to find out just what we’ve stepped in, and what we can actually do about it.

The customer isn't your babysitter

Tue, 13 Aug 2024 16:05:32 -0700

Note: An edited version of this article was originally published on the Samsung engineering blog

“The customer doesn’t care about that” is a poor excuse to be sloppy

In my experience, one particular conversation seems to recur frequently: discussions around whether customers value certain technical practices, such as automated testing, sensible logging, or keeping dependencies updated. It’s not uncommon to hear arguments that these practices are unnecessary because “the customer doesn’t care about that.” This perspective is a lie. More than that, it can be harmful, as it dismisses the intrinsic value of good engineering. Whether it’s automated tests, sensible logging, or keeping dependencies up-to-date, “the customer doesn’t care” is often used as an excuse to not bother.

The Six Questions

Wed, 24 Jul 2019 16:40:29 -0700

Even if you don’t care about the answers, you still need to know what they

Capitalism, at its core, is all about supply and demand. You have a Thing, and somebody else wants the Thing. So, you arrange a trade. Doesn’t matter what you get in return – services, chickens, dollars, the giant stone coin of the Yap islanders – you each have something the other wants, so you agree on a mutually beneficial exchange.

Blame

Mon, 27 May 2019 16:11:33 +0000

A pointless, destructive way to vent anger when you’ve got a real problem

Oh crap. The BAD THING happened. There’s red flashing lights, alarm bells are going off, one of the junior devs is hiding under his desk, the devops guy is breathing into a paper bag, and the project manager is catatonic. You’ve got a problem.

Or, instead of an all-hands-on-deck emergency, the BAD THING is a day-in, day-out background radiation of annoyance and frustration. It hasn’t turned into an immediate, critical problem, but it threatens to turn the office into a Lord of the Flies scenario. Any day now, the QA team is going to fashion office supplies into crude weapons and start hunting the marketing team for food & sport. One of the senior devs will declare themselves a god and start a cult. You’ve got a problem.

Chesterton's fence

Wed, 03 Apr 2019 17:25:52 -0700

The “why” of code

A while back, some (way smarter than me) guy named G. K. Chesterton wrote this:

In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, “I don’t see the use of this; let us clear it away.” To which the more intelligent type of reformer will do well to answer: “If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.”

Fibonacci estimates

Thu, 21 Mar 2019 00:31:59 +0000

The meeting where everything’s made up and the points don’t matter

In Agile™️ software development, it’s common to give a Fibonacci estimate for a task. Exactly what a developer is supposed to be estimating is a subject of debate. In theory, it’s supposed to be estimating how difficult a task will be in relation to other tasks. In practice, many project managers use these estimates as a substitute for time. This substitution is foolish and counter-productive.

Rocket science, by any other name, would be just as hard

Mon, 11 Mar 2019 20:31:45 -0700

Unfortunately, the reality of a project doesn’t get easier just because it’s called something else

I’ve been in this scenario more than a few times in my career:

Product owner: Hey, we wanna do this Really Hard Thing™, how hard will it be?

Me: It will be really hard, but it can be done

Product owner: What if we call it Really Easy?

Me: Sadly, calling it something else won’t change what you’re doing

About Me

Wed, 27 Feb 2019 14:51:18 -0800

My name is Steven Allen, and I’m a Vancouver, Canada based software developer with over 10 years of experience. Working as a full-time employee and freelance contractor, I’ve seen many companies in various stages of success and failure first-hand. Even if I can’t remember all their names, I learned something valuable at each one.

You can find me on Github here: stevenallen05

KeyBase

RSS

Waterfallgile

Wed, 27 Feb 2019 14:36:00 -0800

The worst possible way to manage a project

Every organization manages their projects differently, even if they use the same terms to describe their strategy. “Agile”, “scrum”, “kanban”, “waterfall” - these are all just labels, often misapplied. This can make it very difficult to quickly convey how your organization handles itself. However, a pattern I have seen far too often is a Frankenstein-esque mutant hybrid of waterfall and agile I call Waterfallgile

Stretching the "Tech Debt" Metaphor, Part 2: Escaping the hole

Wed, 27 Feb 2019 11:51:34 -0800

Click here for Part 1: Calculated Risk vs Desperation

So you’re in trouble. You’ve looked around, asked your experts, and you’re in the tech debt hole. Depending on how you respond, this could either be very bad, or the best thing that ever happened to your company. After lots of experience, conversations with colleagues, and study, I’ve found some strategies that tend to work.

Be ready to accept defeat

I’m not being dismissive or pithy - I do mean “accept that success might not be possible”. I’ve seen companies that acknowledge they’re in deep trouble, do everything right from that point on, and still fail. That’s the nature of business. Doing things “right” is only a modifier that makes success more likely. Take a sobering and honest assessment of the situation. This will get you in the mentality that the future of your business is on the line. This is not the time for optimism or grandiose thinking. This is the time to fight like your business depends on it.

Stretching the "Tech Debt" Metaphor, Part 1: Calculated Risk vs Desperation

Wed, 27 Feb 2019 11:47:47 -0800

Sometimes, you gotta take on tech debt to keep the lights on

As a software developer with over a decade of experience, I’ve heard the “sometimes you gotta keep the lights on” refrain many times. Often, it’s from people within a company struggling to ship features. Or worse, people who believe they can’t slow down and clean up a mess because they’re already slow because they’re knee-deep in years of accumulated mess. This is short sighted thinking, and misses the entire point of why it’s called tech debt in the first place. So I’m gonna expand the metaphor for the benefit of people who think developers are just complaining or whining when we say “tech debt”.