Ask HN: Remote workers, how do you avoid rework?

[yang10pan]

Am I the only one that sometimes thinks “someone must have done/thought about this before - this is such an inefficient use of time”?

I’ve had this feeling particularly working for established teams or businesses, but I imagine this may also apply to newer organisations too.

Have you felt this too? How do you deal with it or address it? What tools or methods do you use to solve this problem?

[explorigin]

How is this question relevant to remote work? In any sufficiently large software shop, this problem is universal. How does one end of the company announce what they are working on to the other end?

At my company, we have monthly organizational meetings where a few senior devs go to represent their teams and share what we're doing that could be dogfooded on other teams.

[octokatt]

This becomes data archeology quickly, and leads to necromancy. Project necromancy is fine, but is fraught with danger and tends to be about as popular as normal necromancy in a D&D game.

The more shared documentation that exists at an organization, the easier the archeology portion will be. Even old Slack threads and half-finished README docs can point in a direction, and help with hidden requirements that would have taken more time or painful failures to find on your own. The steps I usually see are:

1) Identify a problem

2) Create a useful documentation infrastructure, like a GitBook or Sphinx, and write down the problem in a well-thought out matter

3) Explore old sources of documentation, and rewrite them into the new structure you created; include the original material and perspective on what's happened between then and now

3a) Find references to other sources of documentation (from when everyone moved from Hipchat to Slack three years ago), get copies of the logs, and search further.

4) Repeat step(s) 3 until you feel mostly fine, and/or other people on your team start to ask you questions about the problem because you've written the docs

5) Architect a solution to the problem, and add your reasoning to the documentation

To do this well, your documentation system from Step 2 should be one that the rest of the team actually uses, and will hold up for a while. At the very least, when your Step 2 is someone else's Step 3, try to be more useful than terrible.

Remote work makes this harder, because it means that you can only use digital archives; a lot of people use paper, and if there's no paper, you don't get random lucky bits of paper that turn out to be exactly what you needed. Instead, you'll have to ask people, hope their archiving system of choice is working, and they are willing to share.

Prevention of these problems involves consistently using the same tools over time, indexing all documentation in a central location which is widely accessible, and meaningfully valuing project document creation as actual work within the organization.

[PaulHoule]

Normally 'rework' is when you screwed up the first time and have to do more work to fix it, and is not 'reinventing the wheel'.

[downerending]

Perhaps OP means "duplication of effort"?

In any case, I rather enjoy "rework" in the sense of fixing things. It's kind of fun changing a data structure and getting an important piece of software to run in minutes instead of weeks, or to add a bit of locking and get a flaky piece of software to become rock solid.

In some ways, I've become the mythical old guy that fixes things by turning a single screw. The trick, of course, is to know which one.

[explorigin]

"rework" doesn't have to be so negative. Requirements change, the markets change...and thus software must change. It doesn't mean it wasn't done well the first time.