Agree with the headline. Good written communication is a requirement for a software development project. But I am not sure about all of his ideas in all circumstances. In particular in relation to a very small dev team and small client group. In terms of something different like for example an open-source piece of software on github, issue trackers are key.

However, for a small sort of private project. For example, if you have a very small team and can get people in a chat room consistently so that you can have solid conversations every day in there, that has worked better for me than using some kind of issue tracker. Especially in terms of dealing with clients or business-related team members. And maybe its really only for very small projects, like one or two developers, I don't know.

But for me, with most of the projects that I have been on my own building a product or tool for a client, the issue trackers and things like that worked against me and the project as far as I could tell:

- People would seem to think it was their job to fill the board/tracker up with as many things as they could think of. This caused extra stress and tended to make me want to rush through things to get them out of the way. The biggest problem with that was that it took time away from the really important things. And it is very difficult to get people to give realistic priorities.

- Sometimes, people would write critical information in the issue tracker or board, and I did not realize it had been updated or how critical it was. And so they operate with the assumption that they have communicated something, but actually I didn't see it until two days later.

- When they have a place to put an infinite number of tasks, it encourages them to increase the scope of the project, without having a real discussion or necessarily even thinking the feature through.

For me when doing projects on my own (or maybe with a designer) for a specific small group, there is just a limited amount of stuff that I can realistically finish in a given time frame. So I actually will not allow an issue tracker or board and try to get everyone to show up sort of simultaneously in a chat room. Sometimes people cannot or will not do that, and in those cases sometimes a phone call can work. Or maybe they actually are capable of reading and writing async messages in the chat room (not very common).

Basically every few days I meet in the chat or phone or whatever with the client and discuss what I have been working on in the last few days, walk them through the updates to the application. So something is being delivered and tested by the client every week or even every few days. Then we specifically talk about exactly what is the priority for the next few days. If there is development work that needs to be caught up on, then there may not be any new features to work on. Or there may be a feature that has been in progress, and the client gets an update on that.

Often the client has ideas for new features. Instead of putting them in a board or issue tracker to pile up, when they bring them up, we decide whether they are now higher priorities than other existing items and will fit into the work load of the next few days. Or, I tell them to remind me later. There is no such thing as a task that I will "get to when I have time". I have the client focus on the next most important priority and/or I explain the ongoing dev work, and we work out like 2-5 days of work and that's it. There is no infinitely expanding list of things to get to later. If something he has been thinking about is really important, it becomes a priority as soon as the previous task is completed. We check if I implemented something correctly as soon as it is implemented. We don't have to refer to a database of things, because we just talked about it a couple of days before.