Hacker News Reader

All of these are great except (depending on what exactly you're thinking of):

> 5. "We need bespoke software because our Product is so unique." -- Nope -- use all the tools you can until you have scale, then start to build whatever is least economical to buy.

You're talking about software startups, right? If their product is not "so unique" then why are they building it? If you don't need custom software, why the hell are you hiring software developers? This one is just weird. While I understand the dangers of Not-Invented-Here syndrome, the pendulum is currently WAY too far the other direction. Almost every "modern" software project is way too reliant on dozens of libraries that are philosophically incompatible, spending more time on adapters and API-specific integration than they would spend simply writing what they actually want to begin with.

You can build bespoke software without using bespoke software (other than your own to test or dogfood if applicable of course).

E.g. if it's basically a webapp, the chances that it's such a snowflake that existing frameworks are inappropriate and you need to roll your own are extremely slim.

(On the other hand, you won't think you're making a game and accidentally create Slack that way...)

I used to work for an automated property valuation platform. It was basically a property valuation workflow tool that presented valuers with the right data at the right time so they could drastically reduce the amount of time spent valuing each property and theoretically produce much more accurate results.

We spent so much time working on features and workflows to interact with clients rather than building the platform for our actual users, the valuers. We could have picked any CRM off the shelf, adopted its way of working, and saved ourselves a lot of time. There is no scenario in which the CRM subscription would have exceeded the cost of the developer's time to produce the cobbled-together half-baked solution we ended up with.

When I arrived at the startup I'm at now, we used a "bespoke" backend for interacting with AWS SQS. It was a pile of code that was written that had no value to the function of the startup.

Switched it to an OSS bus and dumped a bunch of bespoke code. I regret not pushing harder for the CTO to avoid even more bespoke code for some of the admin interfaces that we ended up building for internal tooling which probably would have been better in something like NocoDB.

The value of the startup is rarely in the bits and pieces themselves (very few are), but the process or data flow that the startup models with those bits and pieces and some pain point or business value that gets added in doing so.

One thing I have come to appreciate in startups is that it's better to even spend $10,000 to learn fast rather than to wait 3 months to come to the same conclusion. To put it another way: if you could see 3 months into the future for $10,000, would you pay it? Instantly. So if there's a shortcut that can -- with a high degree of certainty -- remove obfuscations of the path to take, you take it.

What I meant by bespoke can be illustrated by thinking about an example...

Why are we still hand writing HTTP JSON APIs out of base language primitives in 2023? You can generate correct docs and a skeleton implementation in with JSON Schema and Open API for example. Why spend weeks-months writing endpoints + validation code + docs, when you can define a JSON Schema in slightly more time than it takes to discover what the PM wants to build. You can take it a step further and add the validations to the JSON column in your datastore and now you're correct all the way to the DB.

I feel similarly about most folks who think they can write a better queue than their favorite cloud platform (eg AWS SQS) . Just use the tools that you can buy for pennies on the R&D dollar. The reason a team cannot compete with that is due to amortization. AWS can amortize the cost of development and maintenance across 1000s (millions?) of customers.

This is what I mean by writing bespoke software. not sure if that lines up with everyone else's interpretation.

i don't think gp is talking about building business logic or core product. but like maybe don't roll your own monitoring or log uptake or kanban board / task management solution.

i worked at a company that decided they needed to build their own rdbms because none of the off-the-shelf solutions were going to be able to manage their unique scale. come on.

While we're at it, let's talk about what Technical Debt really means. A mess is not technical debt.

Ward Cunningham explains Debt Metaphor https://www.youtube.com/watch?v=pqeJFYwnkjE

transcript at http://wiki.c2.com/?WardExplainsDebtMetaphor

A mess is debt, because you have to pay interest on it. If you don't pay your interest, it will compound and completely kill your velocity. Nothing in Ward's transcript disputes that, nor would it matter if he did (Death of the Author).

Ward seems to be clarifying the difference between useful technical debt, which gets your product out the door faster, and wasteful technical debt, which is writing your code poorly when you could have done better.

If it's slowing your velocity down, making things harder than they should be, it's technical debt. I suppose if you had a "mess" that was self-contained, bug-free, and not slowing you down at all, then that's not debt -- but is it even a mess?

you've described a mess correctly, but misused the term/jargon.

What you've described is poor quality implementation. There are many (infinite?) implementations that could satisfy the product manager, but each has it's nuances of correctness in non-tested cases (if you have tests), in runtime effects, race conditions (across processes), thread safety, ease of refactor, readability etc.

All these are markers of software quality, but failing to do them is not "techdebt". Tech debt is a very specific thing as described in the video above

I've hear this before and I found it nonsense. In short, I don't see any advantage to distinguish responsible) deliberate debt from irresponsible/involuntary debt. A debt is a debt.

You take a loan to buy a house, knowing your salary will allow for the extra expense and you have backups plan. That's a responsible debt. Like, hardcoding some variables in a prototype - eventually that needs fixing. Everyone agrees this is technical debt.

But you can also take an irresponsible loan, eg for some far away vacations you can't afford to. Is that debt? Sure it is, and you better figure a way to solve it once you realize your mistake!

The reason for the distinction is that you basically cannot do anything about what you do not currently understand about the product (besides ship and iterate).

But you can do a lot about learning how to write quality software. And the more you do it the faster you'll get at it. It's only rational if you believe you'll have a long career programming to train how to make quality software, because many quality implementations are equivalently difficult to implement than low quality ones. For the same resources you get greater returns, and those returns compound as you are able to out ship your competitors and get more and more product knowledge/feedback.

From the transcript:

> I'm never in favor of writing code poorly, but I am in favor of writing code to reflect your current understanding of a problem even if that understanding is partial.

Oh I see: the distinction is to stop people frome shipping lousy code and saying "it's technical debt, we'll handle it later".

Ive been at the other end, when we're looking back at code and talking about technical debt, and there's been some semantic arguing about whether it was technical debt or not - I thought giving everything the name of debt would make the mission clearer (improve the code and reduce debt, which is a nice metaphor to communicate with others).

I'm still not entirely convinced by the distinction (we can just say: avoid taking debt if you can avoid it!) , but it makes more sense now.

> Stop the cult of "build faster with tech debt" -- internal quality matters and costs you velocity.

Well, internal quality costs, and the price is expressed in time.

As someone else said: "shipping is a feature", and especially for first versions! The quality of the code is only important for that code that actually brings value to the user, and you need to ship in order to know which is which.

The problem with technical debt stems from the diffused myth that the development of a functionality ends as soon as it is released. No, you must continue to work after the first release, in order to polish the code while integrating the feedback from the user. This is the core of Agile.

>The way I assess where lines cross is by canvassing the opinion of skilled developers that I know. And the answer surprises a lot of folks. Developers find poor quality code significantly slows them down within a few weeks. So there's not much runway where the trade-off between internal quality and cost applies. Even small software efforts benefit from attention to good software practices, certainly something I can attest from my experience.

https://martinfowler.com/articles/is-quality-worth-cost.html

If you expect your business to exist more than a few weeks from now, opt for quality implementation over "ship it" hacks that cause compounding costs into the future.

There are hacks like "everything in a huge global object", and technical debts like "no unit tests for internal detail and no detailed software structure documentation until we know which code is actually worth to maintain".

> Developers find poor quality code significantly slows them down within a few weeks.

By the way, I'd like to know which kind of software those "skilled" developers are used to work on. If it is the umpteenth CRUD web application, several weeks can correspond to a few releases. In other fields, a few releases is a matter of years, and even only a few months of customer feedback is a treasure that smart developers don't give up easily.

I think both the rebuttal and the original articles are good, but talk about different things. The original one seems to talk about the way Agile tends to be done, especially via the world of corporate, consultant agile, certified scrum masters and so on, whereas the rebuttal is talking from the point of view of what Agile should be. Two very different things, both very valid, and in a sense the discrepancy between the two tells you a lot about the state of agile itself.

That said I love the thing about ending Sillicon Valley bullshit - IMO it has led to a lot more hurt than good.

>What'd I miss from the list?

Fucking "Hustle" -- a word used by scammers and conmen that now somehow means "work smart" but actually means spamming people and doing other sleazy things to get money