When I started programming, it was a solo skill, performed by individuals, with little or no sharing and virtually no collaboration. A culture was built around those facts. 1
-
-
Going from one person coding something, to two persons coding something is not just a 100% increase in staffing, but it changes programming from a solo practice to a team sport. 7
Show this thread -
When you program in pairs, you have to communicate your ideas, you have to explain your thinking, you have to agree on intent, and your work gets checked and checked again. If this bothers you, you can’t sustain it at a high enough level to be professionally competent. 8
Show this thread -
So, it should not come as a surprise that the single most confused, abused, and refused aspect of agile development is the collaborative part. That’s because it alters what many consider a foundational part of the culture of programming. 9
Show this thread -
I’ve tried to program in pairs and it fucking hurts this old graybeard’s sensibilities. It assaults my deeply ingrained—nearly instinctual—notions of what programming is all about. I have nothing but respect for contemporary programmers who can work collaboratively. 10
Show this thread -
So, from my vantage point, there is a massive, yet nearly invisible, war taking place in the world of software development: The fight between the self-made men of yesteryear, and the new generation of team players. 11
Show this thread -
There is so much ink spilled about agile practice and it is all so much camouflage for the real battle, which is: Are developers working in an external, public dialog or in an internal, private monolog? 12
Show this thread -
I don’t think it matters one whit if your shop uses scrum or jira or stand ups or burn downs. Only one thing truly makes a difference, and it’s a huge difference: Do you code in a group? 13
Show this thread -
And not at all remarkably, if you ask around, you will find intense debate in development circles of every single tiny insignificant aspect of agile, but almost no discussion of coding in pairs or groups. It touches the heart of the matter a little too precisely. 14
Show this thread -
And yet, the development community is actually grappling with the cultural upheaval that collaborative development introduced. Meanwhile, another community has emerged from dev, and still embraces the old values. Yes, I’m talking about billionaire tech moguls. 15
Show this thread -
Having a lot of code to write, & a lot of users to satisfy, are reasons why devs eventually discovered agile methods. Having a lot of money, OTOH, is the reason why tech tycoons can ignore agile methods. They are only interested in agile if it somehow reduces their dev costs. 16
Show this thread -
My goal here is not to debate agile or agile methods, but to highlight this atavistic cultural divide that—I believe—originated in proto-programming years ago. 17
Show this thread -
I have faith in practitioners. I believe that we will innovate and improve our methods and eventually get better at building software. I’m not so sure about those tech tycoons who adopted our old, discredited religious practices. 18
Show this thread -
In unconstrained free-market capitalism, those older, bogus beliefs pay off in the billions. There’s no mind harder to change than one that has been hugely rewarded for not changing. 19
Show this thread -
If our goal is to get rich, or to avoid falling through the ever-widening cracks in the floor of the middle class, then we will always look longingly at the old ways of solo creation. Those ways grant us permission to crush other people as we climb to the top of the heap. 20.
Show this thread -
If, on the other hand, our goal is to be a good ancestor, then we have to understand that everyone is poor while anyone is poor. Thus we see that collaboration is necessary for a sustainable culture and not just a tool for more efficient programming. 21
Show this thread
End of conversation
New conversation -
-
-
Always viewed programming like writing a book and you don’t get many good books written by teams.
-
Good analogy as there’s also a colossal amount of terrible books written and great books are rare in the grand scheme of things. The difference is there’s no cost to badly written books, badly written software can have huge impacts.
-
Analogies are dangerous when you use them to explain or understand software, which is not the same as anything else. And BTW, it’s called Sturgeon’s Law: https://en.wikipedia.org/wiki/Sturgeon%27s_law …
-
I agree, only intended to demonstrate to
@neitherspanish that even if we used *his* example of writing a book as a good analogy for software design then the individual approach would still be less beneficial than the collaborative one wrt software engineering
-
Depends on what you mean by collaboration, it’s such a vague term. Pair programming, to me, is just nuts, hence the book analogy. Talking to your colleagues around a white board is essential. Both could be described as collaboration. Perhaps it’s just my personality of course.
-
I think you’re right that some personalities just aren’t cut out for it though and then the question becomes should the process change around them or they change around the process? I would say the latter.
-
Fascinating reply. Isn’t Agile supposed to embrace difference and encourage people to be themselves?
-
I don’t think agile has anything to do with “embracing differences” and “encouraging people to be themselves.”
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.