Yegor Bugayenko, Project Manager & Programmer https://youtu.be/7EytYc7K5JA 48 min watch time Extremely Distributed Software Development
Issues
- Projects end in missed deadlines, over budget, don't fulfil requirements - but why?
- Technical incompetence isn't the issue
- Management is the issue
-
Teamwork: Traditionally, teamwork is considered really important: togetherness, motivation, and "matching" of people together. A lot of time is spent on team-building and team-love.
- People who care about quality & results can be turned off by this focus on team-building
- People who care about fun & security above quality / results are generally into this kind of team-building
Strategy to resolve:
- Give individual tasks to individuals, set clear standards for results. One person is responsible for the success of a project - they are called the "architect". The architect makes all technical decisions for the project - there is no voting on technical decisions. All work is done remotely. All communications happen digitally.
-
Overtime: Traditionally, steams are stress motivated - overtime, deadlines, etc.. In other words, long hours are equated with "well performing" developers.
Strategy to resolve:
- Work less, not more. Give fewer, high quality hours. Have devs only work when they want to, if they want to. Allow devs to say "no thanks" to assigned tasks. Devs can assess whether now is a good time for them or not, whether the task is appropriate for their level or not. Yegor finds that well-performing devs tend to work 3-4 hours per day, on average. Managers assign tasks. Managers don't push devs. Managers must find more devs if they need more work done.
-
Learning: Traditionally, learning in companies takes a long time to "ramp up", and will create "experts" ("subject matter experts") that are integral to the project. However, these "experts" do not typically make clear or open their entire knowledge base - keeping them vital to projects, but preventing others from replacing them or effectively supporting the project. If these "experts" leave the project, the project typically is doomed, or highly compromised. These "experts" can also wield a large amount of influence over the project, dictating how, when, and what, rather than the architect, stake-holders, or customers.
Strategy to resolve: Make a single source of truth that enables new devs to contribute quickly. The document, source code, or diagrams, are the "knowledge base". This will allow devs to contribute effectively anywhere in the project. Devs are rotated throughout the project. The project is responsible for dev results - in other words, if something isn't clear, it becomes someone's job - another dev or the architect typically, will add clarifying information - to improve the project so that future devs do not find a similar hurdle to moving development forward. "Devs can blame the project" -> "we improve the project"
-
Meetings: Traditionally, meetings are face to face over Skype, Zoom, or in person. There is a lot of chatter over Slack, Discord, phone, email, text, etc.. Information is hidden in meetings, scattered documents in multiple places, and people are kept in the dark. More meetings is believed to lead to more results or worker output. The belief is that "meetings > documentation". Information is not evenly, clearly, or directly distributed to all who need it. In other words, 1 explanation will need to be repeated until all who need to know are informed, leading to a "telephone"-type "game".
Strategy to resolve: Exchange information through public documentation, code, and diagrams. No phone calls, no instant messaging. GitHub issues/tickets are OK. GitHub questions are OK. This will feel uncomfortable at first for teams that are not used to this.
-
Salaries: Traditionally, companies use contracts, loyalty, and an emphasis on soft skills to reward people with money (compensation). Hard results cannot be used as a metric for reward because either they are not being measured, or, they are not valued enough by the company to care. Dev happiness is put at a premium. Traditionally devs are paid by the time spent (hour, month) or the final project completion or large milestones (lump sum). In other words, you get paid whether the results are met or not. People who care about quality results, will balk at this - this may seem unfair to those who care. Who talks more, is nicer, is more communicative, who seems cooler, will typically get rewarded.
Strategy to resolve: Pay for results - file tickets or close bugs. Pay in micro-payments - 1 ticket closed or 1 bug fixed results in 1 payment. Devs are compensated by tickets closed, bugs fixed, and tickets filed. Devs are not compensated for time or for lines of code. All tasks are 1 hour or less, typically 30 min or 1 hour.
Main talk presentation stops at 21:22
Teamwork
- Anyone with interest in Athens can come to the GitHub repo and without seeing the Discord or Looms or Roam notes, get started quickly (30 min to 1 hour) to become able to contribute to a feature or bug fix
- Why post questions anywhere but GitHub?
- Eg. Post "I need X info" on the GitHub so that anyone looking for it will see it there
- Instrumental goals vs Terminal goals (what kind of performance metric can we have?)
- What can we do for people who are not acquainted with GitHub?
- We are also doing design work (w/ Figma)
- We are also doing community building, writing, software architecting, project management, education, and outreach, among other things
- Handle gracefully (perhaps with a directory) all potential contributors: eg. linktree, handbook, github readme
- How about pair programming? Why can pair programming be helpful?
- Can lead to increased project knowledge base or skill-upping
- Who is available for coworking? How can new folks easily and quickly find people to pair up with if they want to, and/or learn that pair programming is even an option?
Big conversation: If someone is not to contribute to the project (but wants to), why don't they?
- Options to address: surveys, informal chats, investigative group/pair programming, cursory informational architecture evaluation / analysis
- What information do Clojure beginners need?
- What info do GitHub beginners need?
- What info does a front end dev need?
- What info does a backend dev need?
- What info does a UX designer need?
- What info does a graphic designer need?
"Make the project into the subject matter expert."
What are examples that we can see of XDSD on GitHub?
What are the expectations of contributors? How does meeting participate affect (if at all) people's ability to contribute?
How might we capture important insights or questions that are posted in Discord so that way they are easily searchable/discoverable (for example as issues in GitHub)?
Is our project ethos more inclusive or exclusive?
"Puzzle Driven Development"
Pain point for Avi: I don't want to contribute code that doesn't look professional or meet some "high level" standard of quality.
Avi's learning experience in 3 hours:
- The build instructions are indeed in the handbook (make sure to double check ;))
- Button icons are material-ui and are located in X folder
- New buttons that are added to the top of Athen's interface go in the "app toolbar"
How can we normalize contributing in the face of perfectionism, varying interpretations of "professionalism" or quality standards, and non-strict submission guidelines (?)
Where are the submission guidelines?
Is the handbook up to date?
How can I best confirm whether something in the handbook is correct?
How can I make a change to the hanbook?
Who is the handbook for?
Who has access to modify / update the handbook?
Why is the handbook better?
- Comments? Easier for non-devs to read and navigate? Easier for non-devs to update?
- Create a learner to contributor pipeline / funnel / scaffolding structure