Craft? Science? Different cultures in knowledge-based activities.
I've seen some people arguing about how software development should be
less "passion" and more science. Others argue about how similar
software development and design is to a craft and how sterile it would
be without consideration for aesthetics and elements of craftsmanship.
If you pay attention to who says it it's easy to notice that both points of view
come from different environments. One person working for a huge company may
be thinking about the benefits of standards and automation and the benefits of formality.
Another person is talking from a different place and looking at software as a means of expression and focused on the creative characteristics of the medium. Starting from an idea and quickly move to crystallization, without formalities is what drives a lot of people to work on software.
Even if both perspectives seem distant, they share something in common.
They both start from the experience of the people doing the work.
We can't ignore the fact that the experience of creating software is very different
if it's for a big organization, for a small group, or as an open-source project
separated from any deadline or commercial incentive.
A relevant quote from GeePaw Hill
There is no valid formal method for making and shipping software. If there were, humans would not be programming, computers would. Software making is irremediably, permanently, thoroughly, and happily dependent on individual humans using judgment."
Isn't it interesting that even with the lack of structure, some of the core tools we use every day
have emerged from Open Source and not from the big companies with the money to use formal, math-based methods of creating software?
It's true that the lack of structure and opportunity for self-expression in Open Source is not a good fit for some areas where formal methods are required, so here we should recognize that there's not a unique "software development" culture, and get used to having different cultures that naturally emerge to tackle different problems. We have a problem with obsolete titles like "backend/frontend developer" that do not reflect the reality of what people do nowdays.
I'm aware that this discussion comes from the desire to transform software development into a more predictable activity and the idea that removing human judgment from the equation should get us closer to that. Take for example ehe way NASA develops its space ship software. It's a very extreme process when just a line of code may need weeks of discussion and evaluation. It's an exceptional process because its usage and failure treshold has very specific constraints and consequences. The culture that emerged from those probelms is very specific too and not easily transferable to other environments. Focusing on the set of code that runs inside a space ship is a very specific and exceptional use case but I'm sure there are millions of lines of code of the supporting tools, administrative and operational stuff that is still used by NASA employees and is not developed in the same way. Different problems with different failure and experimentation thresholds.
I'm excited to see more new cultures develop inside the "software development sphere". Some excentric methodologies may arise that are a good fit to create a certain family of tools or serve some economic interest.
Again, Open Source is very interesting because of its lack of coordination and structure. It doesn't mind deadlines, and for lots of authors, it's not directly tied to commercial incentives.
We could keep going and expand these ideas but the key point is that "software development" will keep growing in different directions at the same time, producing different cultures that are defined more from the problems the authors are trying to solve. The title "software developer" is starting to look like an imprecise definition of what some people do and the new roles should take into account the "culture" defined by the ideas/problems/innovations the group or individual is working on The opposite of a "unified theory of software development" is what's currently happening. This leaves us with more questions, like what can an information worker do to better adapt to this and what companies can do about it, how to define the new roles and why fluidity instead of fixed labels is key, but I'll leave those ideas for another time.