Traditional dev process stifles collaboration
I’m not going to justify why software development needs collaboration - if you don’t need a team or customer opinion to write good software then great for you. This blog just explains why chat, tickets, specs, code reviews, and meetings are not going to get it done.
Bias acknowledgement: your new dev process should run on Uclusion.
The problem with specs and code reviews
Writing an entire spec before coding, even with questions and suggestions addressed in it, is a “waterfall” approach. Reviewing a spec is the equivalent of a code review on a much less precise language, with much less certain assumptions.
Where a code review is too late in the process for real collaboration, a spec is too early. Spec approval locks you into an approach and timeline before even having the learning exercise of actually starting.
The other problem with waterfall is planning fallacy:
In 2003, Lovallo and Kahneman proposed an expanded definition as the tendency to underestimate the time, costs, and risks of future actions and at the same time overestimate the benefits of the same actions. According to this definition, the planning fallacy results in not only time overruns, but also cost overruns and benefit shortfalls.
The key phrase there is “benefit shortfalls”. Once you write an entire spec it’s difficult to turn back from doing a project with insufficient ROI just as with a code review of code that addresses the wrong problem.
The problem with meetings and chat
Ongoing team opinion is the best defense against code factory. Not rubber stamp the PM, not customer X supposedly wants it (more on this later), not this project was socialized before we started it, and not fait accompli.
Chat and team meetings break up the day in a way that makes coding difficult, get back unprepared answers, and incomplete assistance is not recorded for status.
Planning meetings have a number of problems, described here, that usually result in just rubber stamp approval.
Of course meetings have a place in software development, but not as a collaboration panacea.
The problem with tickets / Kanban boards
Kanban boards were designed for 1970s Japanese factories. They prefer a strict progression through stages, and work best in the absence of collaboration. You can collaborate inside a ticket, just as you can in a long email thread.
Unfortunately, that kind of unsupported messaging is the definition of stifling; you won’t engage in it unless there are no other options.
The problem with most customer feedback
Many developers hope “release early, release often” is a magic bullet, but not if it is guided solely by customer complaint. Coding the wrong thing or the wrong way has an enormous impact on a development team or sometimes an entire organization.
The best case is directly and asynchronously collaborating with customers. Chat, of course, is not asynchronous; when it dings the expectation is that it be answered soon.
Have the occasional live meeting, but not as your only means of contact. And, in our opinion, do better than communicating in email or a ticketing system.
Towards next generation developer collaboration
The software ROI problem has no easy solutions, but using a tool with formal approvals, questions, suggestions, reviews, estimates, and blockers is better than generic solutions that end up discouraging collaboration.
Project management systems are designed to track certainty. This ticket with this date and no mechanism to change that date, another requirement of a good dev process. Such systems aren’t built for collaboration, because they don’t admit ambiguity exists.
What next generation developer collaboration requires is a system designed to track and reduce ambiguity. Such a system generates notifications for the team to voice opinions and make decisions. Keeping track of all of that administrivia in meetings, chat, and ordinary tickets is not only unpleasant - it’s impossible.
