Hacker News Reader

Comment by nkozyra | Hacker News Reader

Write everything (generally, new features) twice has turned out to be really good strategy for me, but it doesn't sit well with bizdev or project managers and tends to be perceived as unnecessary slowness.

But if you plow through a feature and get it "working," you'll do much of that work cleaning up the logic and refactoring through your first pass. What rewriting allows you to do is crystalize the logic flow you developed the first time and start cherry-picking in a more linear fashion to meet the blueprint. It also tends to reduce the urge (/ need) for larger scale refactorings later on.

View on HN

A project manager or bizdev person writes, rewrites, and rewrites again the document they produce do they not? Or do they write the perfect document at first go?

Worst kind of jira ticket is just a link to a document that can be edited anytime. In that case I just replace the link with a new link pointing to the fixed version of the document and inform the author of the ticket/document about it.

Depending on what kind of document it is, I often resort to extracting its contents with pandoc by converting it into markdown, and then replacing the original description. Makes search work properly too.

If I'm writing something, I'm writing it once. That "prewriting" stuff they teach in schools just slows down the process and makes you overthink your choice of words. I take the same "1 take" approach with code with the idea being to write the best solution on the first try. Why waste time writing something bad just so you can fix it later? That doesn't make any sense.

As I'm writing, I do go back and make changes as they pop into my head. But once I'm done writing it, I'm done unless I notice an obvious mistake after the fact.

1. You don’t take any notes or make any bullet points?

2. > As I'm writing, I do go back and make changes as they pop into my head

This contradicts the idea that you only write once.

3. You don’t get feedback on your first finished version and make changes?

Don't think of the first iteration as "prewriting" and instead think of the subsequent iteration as "editing."

How would they know? Are they monitoring your code writing?

Depending on how the dev environment is setup, yes. Maybe you need something to go through a CI/CD pipeline. If you can't test it on your local machine, it can easily be visible to many people.

> it doesn't sit well with bizdev or project managers

To be fair, it makes everything twice as expensive. Managers are always going to reflexively push back against that, even if the new feature covers that cost and more.

The second time doesn't cost as much as the first.

And the first is cheaper than a ‘regular single version’ bc you build it with the thought that you will throw it away.

You throw it away but in truth much of it survives in a much better design.

> To be fair, it makes everything twice as expensive.

The article argues it makes it less expensive to reach any specific quality level (above some threshold).

The threshold isn’t really addressed in the article, but it is implied that for any realistic quality need, the write twice approach will be cheaper.

To conclude it makes everything twice as expensive, you have to ignore any cost except the initial write. That’s not realistic.

What hits hard is realizing that most features are not worth it. They just shouldn’t be developed.

Unfortunately biznes wants features and more of them and if possible for free.

I find half my job as a developer is writing code, and the other half is advising clients on which features not to implement.

From the article:

> Rewriting the solution only took 25% the time as the initial implementation

Seems reasonable.

> Seems reasonable.

Not to the manager, which is the point, not how long it takes to rewrite it.

> Write everything (generally, new features) twice has turned out to be really good strategy for me, but it doesn't sit well with bizdev or project managers and tends to be perceived as unnecessary slowness.

Silo-isation compounds this. If the maintenance costs are borne by another team or if any rework will be funded out of a different project, the managers are not going to care about quality beyond the basic "signed off by uat".

I spent some time doing consulting with an engineering manager who would keep requesting different (correct) implementations of the same functionality until had seen enough and then he'd pick one. This did lead to some high quality software for what needed to be a high reliability product.

I should probably mention that I was doing consulting engineering here because no employees work work for the guy...

Reply on news.ycombinator.com