Media Query Source: Part 23
The responses I provided to a media outlet on December 18, 2019:
Media: Software changes so rapidly, but do developers think about the implications of this in the back of their mind while developing? For example, do they lose motivation when they think about how whatever they're developing might be replaced with a new version in months or years? Or does this prospect excite developers because they know once they ship something, they can work on improving it? What are things that developers working with rapid release cycles need to keep in mind?
Gfesser: I've found it much more common for junior developers to think about deprecation of software that they build than those who have established themselves in the industry.
From my experience, this is largely due to their being relatively new to the industry, an in many aspects still in the early stages of their learning path, regardless of whether they've actually received formal education in the field. Their learning experiences and sweat equity, often consisting of long hours at the keyboard, are attached to the code that they build, and they are typically often not only looking forward to their code being used in production, but used for an extended period of time.
However, the lifespan of what is built by any developer is uncertain because requirements change and stakeholder interests change. While some developers get accustomed to their work being deprecated sooner than others, it is a milestone for any given developer when they get past any concerns about this matter, and focus on what is needed now and in the future.
Most developers that I know, including myself, are most excited about new development efforts, including those which involve replacement of software written by themselves or others in the past. These offer a chance to assess the latest programming libraries and frameworks and whether these might be a good fit for what they are trying to build, all without concerning themselves with legacy dependencies that may have held them back in the past.
While most developers enjoy new development efforts, many also enjoy working on incremental improvements to a given code base. However, many value incrementally improving code that they have written, not necessarily the code written by others, because they know their own code and oftentimes don't want to concern themselves with differing styles of coding by others, or worst case, the buggy code written by others.
Media: Also, how do developers react when there is a backlash from users over new features, and how can they come to terms that not every user can be won over?
Gfesser: Ideally, involved with the development of software is a product owner who can speak on behalf of other stakeholders, or speak on behalf of research that has been done to influence what is being built in an educated manner. For completely new products, usage of software features is ideally logged in a granular manner so that it can influence the priorities of the product owner, and therefore the development team. In such cases, developers need to understand that new features should be treated as experiments that may not meet what users want. In many cases developers are more interested in the act of building rather than how it is actually being used, and so don't have a vested interest in reacting.
An example of this from my own experience is when I was working as a junior developer for a Fortune 100 meat processor to write software with my team to control machinery installed in their plants. We largely wrote this software remotely from our consulting office, and would periodically visit client plants to test our software. And this testing was done in production because our client wanted it to reflect realistic workloads. On every such occasion, client personnel working on the floor to administer the machinery alongside a given set of conveyor belts would verbally express their dissatisfaction of our coming to test, because of the backup that might result due to software error.
My experience on this project led to significant personal growth in terms of willingness to experiment, and to not be emotionally affected by users who only had a single workday in mind rather than the longer road ahead which we were attempting to pave with better software. For what it's worth, our software was a success. Our work at this client can be seen as an early version of what is now called "canary deployment", because we deployed on a small fraction of production conveyor belts to check the quality of our software. This same practice is now used in modern application development efforts so that new features can be first tested out with a small subset of users before rolling out to the entire user base.