Hacker News Reader

> What does ‘Done’ look like?

At least in the software world, I'd say an abandoned project is done. Good enough to ship is something else entirely.

> I’ve learned to adopt an “organic” project process, based on the assumption that it’s impossible to know the end result when I start.

For some things you do want to spend a bit more time planning up ahead, as some decisions can be hard to undo later.

But I think one should definitely try to make code pieces as modular as possible, and as easy to change as possible. As you say, the final product will likely not be as one imagines at the start. Especially since customers seldom know exactly what they want.

So many times I can whip up new features in short order, because I spent some time up ahead making small reusable modules out of functionality, so it's easy to use from elsewhere.

> I think one should definitely try to make code pieces as modular as possible

Absolutely. That's the key. Modules and layers; each with its own project identity and lifecycle. loose-coupling, minimal APIs, and reevaluation phases at the completion of every module.

If you do this right, projects can be almost "Lego" simple, with the ability to rapidly reconfigure to adapt to changing requirements.

Here's an example. Yesterday, I was working on a "UUID scrubber" for the Bluetooth project I was working on (https://github.com/RiftValleySoftware/BlueVanClef). I started by having a private class function to do the scrubbing, but realized that this would be something that could be useful for any similar project, so I broke it off, and added it to my toolbox project (https://github.com/RiftValleySoftware/RVS_Generic_Swift_Tool...). That meant that I also had to write a unit test for it, and then update my Carthage include.

Took, like fifteen minutes, and I now have a permanent tool for scrubbing UUIDs.

Another habit that I developed, was making every project I do, including "one-off" experimental projects, "ship quality."

I simply cannot put too much stress on the need for maximum quality. As a lone developer, I just cannot afford bugs. It's imperative to do it right the first time.

The general argument against a high-quality process is that it is inefficient and slow.

Unless you make it a habit.

"We are what we repeatedly do. Excellence, then, is not an act, but a habit."

-Aristotle (Probably, but these attributions should always be taken with a grain of salt)

In addition to defining “Done” I think it’s also important to define “Enough info to start” and “Enough info to finish”. In a lot of projects the stakeholders aren’t willing to commit to anything which then leaves the dev teams without direction. I have been multiple times in situations where the deadline was ticking but somewhere between project management, project management and development management (too much management?) they couldn’t make their up their minds and critical questions didn’t get answered.

"I was not the “big boss,” during most of that time, so I often had to work in far-from-perfect systems."

I am the big boss of our 12 person company but I still cannot ever get to a perfect system. Yes in theory, I can make all the decisions and impose BUT it is far from it. The challenges of building a perfect system is not only related to how much power you have (yes it helps) but many other factors.

Yup. A perfect ship team is the Philosopher's Stone of software engineering. If anyone gets it perfect, they get to knock Bezos out of top place.

I worked for a Japanese company for most of my career.

It was...challenging.

HUGE team of very, very capable engineers (I regularly worked with some of the finest scientists and engineers in the world), but hidebound like you wouldn't believe.

I quickly learned never to use the word "agile" when talking to my bosses. Frowny faces appeared everywhere. They considered it a "low quality" process.

The main issue, is that I was talking to top-shelf engineers and managers, who had been delivering top-quality products for 100 years. This was not trying to convince impressionable American VCs or play "buzzword bingo." These folks knew how to do something, and they had been having success for generations.

It's just that what worked so well for hardware, went pear-shaped with software, and I was never able to successfully convince them of that.

That made me very sad, as I think that they really lost a lot of benefit, because they couldn't pivot into modern software engineering. I loved that company, and I have tremendous respect for my peers in Tokyo.

Since leaving that company, I have been working on my own, and implementing the ideas that I cultivated while working there.

It's been fairly effective.

Those cranky bastards had one thing right, though. The software industry has a shockingly high tolerance for crap. It's a real challenge to try to advocate for doing quality work.

I was almost ready to start an argument. But the bottom line (verbatim) nails it!

99.999…% of all software is utter crap. If people would build houses like they build software we would generally all live in paper boxes glued together by duct tape. And those paper boxes would explode on a regular basis for unknown reasons…

Still you will hear most people in this business saying: "That's fine". Look, "it works".

I don't think this will ever change. One of the reasons this won't change (besides development costs of course) is imho the overall mindset that "bugs are unavoidable, any software has bugs". As long as it's a "natural" thing to deliver buggy crap, and people declare you outright crazy if you even mention that there's something quite wrong there, no chance that this will change (at least not until software will be produced mostly by machines).

I generally don't bother setting up bug trackers, as I get so few bugs.

One reason is that I keep my scope fairly humble, so it can be argued that software that doesn't do that much doesn't have room for bugs.

But I like to avoid dependencies, if at all possible, and have a number of habitual practices in my coding that I think result in exceptional quality.

Problem is, it's not valued at all. I'm in a semi-retired status, and have found that no one wants decent quality.

It's been rather depressing, TBH.

One of the open-source systems I designed is becoming a worldwide infrastructure, and they have more bugs than ever (I don't code it anymore), and that means they have maybe 20 issues, in all; across about 50 subprojects. When I was doing it, it was a single-digit count, but only about five projects.

It's still of remarkably high quality. The folks who took over are good, and follow good practices. Also, the substrate is very strong.

Edit: skip this. I've read your links and it's clear you wouldn't fall into this trap. Sorry.

I had a boss who relentlessly focused on getting things done, neglecting anything but the immediate cost. If the cost could be pushed into the future (well, that wasn't the calculation - it was more like 'can I ignore this right now') then it was. He built up a whole lot of technical debt that was expensive to deal with, and some never was dealt with, so continued costing permanently. Any thoughts?

It’s cool.

Tech debt is a HUGE deal. Since I work alone (for the most part) these days, it’s an absolute killer.

I can’t afford it at all.

The single biggest guarantor of a massive debt (IMNSHO) is a rigid up-front specification.

>The single biggest guarantor of a massive debt (IMNSHO) is a rigid up-front specification.

Or the lack of any meaningful upfront planing.

This goes in both ways. But I agree of course with the above. Detailed specs, especially done in some ivory tower, will cause massive problems, no question.

This is what I do: https://littlegreenviper.com/miscellany/forensic-design-docu...

I call the upfront spec my "Napkin Sketch." It's often a single diagram.

A problem I've seen a lot of too. In this case, the definition of 'done' is totally leaving out all that technical debt. Hence 'something' has been shipped, but the work has most definitely not been 'done'. Just giving an appearance of done, sweeping other stuff under the carpet. It gets expensive doing that. And gives a very lumpy carpet!

Take a gander at my work. It is quite possible to ship without debt, but you need to be flexible (the word “agile” is almost worthless, these days, so I prefer “flexible”).

Think we've a lot in common. Maybe to do with being older and more experienced; been there, done that, got the t-shirt. I started with Assembler on Intel hardware and problems with coding that in scale aren't so different to today's environments. As for 'Agile', yep that died as a marketing phrase, even though the intentions (and the manifesto) are entirely valid. Flexible is a better choice now. Fragile is what we often get!

> "the word 'agile' is almost worthless, these days, so I prefer 'flexible'

It's kind of sad, though. What you said above ("I’ve learned to adopt an 'organic' project process, based on the assumption that it’s impossible to know the end result when I start.") is literally what Agile was trying to convey when it started out.

Yup. I loved the Manifesto. They had the right idea.

My experience is that things go pear-shaped when those pesky "people" get involved. It's all great on paper, and in the theoretical perfect world, but as soon as people start getting involved, and developing their own mental models, it can cause problems.

A big factor, as well (IMNSHO), is that a lot of folks decided that they wanted to be "gatekeepers" of the methodology, so they started to formalize it, and develop a vocabulary that they "own."

That happens with pretty much everything.

I'm old, grumpy, and very experienced. A great deal of the programming that I do is "instinctual." I don't stop and say "This would be a great place for OBSERVER!". I just go ahead and set up a subscription management utility, and don't give a damn what it's called.

In my experience, every time we come to a "new paradigm," a great deal of it is really just a formalization or rebranding of concepts that have been around for years.

> agile...worthless

True IME. Any time I see the word Agile, I now consider it to mean Clusterfuck In Progress.