Software Development and the Gig Economy
These days, it's common to hear arguments that software development is becoming gig-based. However, for companies whose core product is software, this makes little sense.
Join the DZone community and get the full member experience.Join For Free
These days, it is common to hear arguments that software development is becoming gig-based. In other words, companies will not hire programmers for permanent positions. Instead, they will put together temporary teams of independent contractors from anywhere in the world to complete projects.
This is no doubt true for some software development tasks. However, for companies whose core product is software, this model makes very little sense.
Outsource All the Things!
I recently listened to Software Engineering Radio Episode 245: John Sonmez on Marketing Yourself and Managing Your Career. Starting around 13:15, John talks about how he believes software development will move to a system of entrepreneurs and freelancers and away from permanent positions.
Last summer, I read Deep Work by Cal Newport. In the first chapter, on page 25, Cal writes:
“It no longer makes sense, for example, to hire a full-time programmer, put aside office space, and pay benefits, when you can instead pay one of the world’s best programmers, like (David Heinemeier) Hansson, for just enough time to complete the project at hand.”
I agree with John Sonmez that it is important to market yourself as a developer and to build your brand. I also really enjoyed both Deep Work and the podcast episode. However, I think both are mistaken in their conclusion that programming will become mostly gig-based.
Before explaining why, there is one caveat. For some companies, the core product — the competitive advantage — is software. These are companies like Google, Facebook, Microsoft, and Spotify. Note that to consumers, Spotify is about listening to music, not about software. Nevertheless, Spotify is, at its core, a software company.
Then, there are companies where the main product is not software — for example, Ford, Boeing, and Walmart. Even a company that makes physical products uses a lot of software. While the software is augmenting and supporting production, it is not the main product. However, the lines can be a bit blurry. For example, is Tesla a car company or a software company? Probably both.
My arguments below apply mostly to the first categories of companies, where the core product is software. I don’t know what proportion of all programmers work at such companies, but I believe it is a substantial part. The Stack Overflow Developer Survey 2016 suggests 40% (adding together software products, web services, internet, and gaming).
Successful Software Is Never Finished
The idea that all software development will be outsourced partly follows the idea that software is developed in projects with a beginning and end. When the project is done, the software is finished, and the developers move on to other projects.
However, this just isn’t true. Successful software, i.e., software that is used, is continuously updated and improved. The more it is used, the more ideas there are for how to improve and extend it. To me, this is surprising, but it has been the case at every company I have worked at.
For example, when I worked at Symsoft, I developed software for routing and delivering of text messages (SMS). The base functionality is extremely simple: deliver the message now if possible; otherwise, store it and try again later. It was an existing product when I started there and it was continually developed and refined for the six years I worked there. Three years later, the product is still developed and enhanced.
Because of this continual development, there is a constant need for developers to work on the product — not just for the duration of a project, but permanently. Thus, it makes more sense for these companies to hire developers directly and permanently instead of constantly staffing development with freelancers.
Code Knowledge and Domain Knowledge
The other advantage companies get from hiring permanent developers is tacit knowledge. Even though all of the capabilities of the product are captured in the source code, a lot of what is needed to modify it is in the heads of the programmers. As a thought experiment, imagine that all developers of a product quit today. How long would it take for a new group of developers to get up to the same speed of development as the old team?
Also, even if you have all the source code, it is often useful to know why things are done a certain way. Often, the only way to know is to ask one of the original developers.
In addition to code knowledge, programmers also continuously learn more about the domain as they develop and extend features. All of this domain knowledge mostly resides in their heads. This domain knowledge (and the knowledge of the code base) is the other reason for companies to prefer permanent staff over a group of contractors.
A large part of software development is done at companies where the core product is software. For these companies, it makes more sense to have permanent developers on staff instead of using external developers. This is because the product is constantly developed and because of the advantage of keeping the knowledge gained while developing within the company.
This does not mean lifelong employment at one company. It is natural to change companies regularly, say every five years or so, in order to learn and grow as a developer. So, these companies still need to recruit new developers. However, bringing new hires up-to-speed is easier with an existing core of developers already there.
What are your thoughts? Do you agree or disagree? Let me know in the comments.
Published at DZone with permission of Henrik Warne, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Is Podman a Drop-In Replacement for Docker?
Microservices With Apache Camel and Quarkus