olly - Fotolia
There was a time when if you wanted a soda, you went to the soda fountain inside a corner drug store and an employee called a "soda jerk" would mix up ingredients to make the soda. As the years went by, soda making became automated and subject to commodity packaging. Also, the role of the soda jerk had to change.
We saw a similar progression with software development. Programmers once made the software, QA made sure it worked to specification, sysadmins managed the infrastructure, operations put the code in production and project management controlled the schedule. It was very segmented, very manual and very tidy.
But modern software automation has brought a changing dynamic in software development. As such, software developer responsibilities moved far beyond the original, basic coding functions. With these changes, developers now wield more power than ever before. It also raises new questions about how corporations should manage that power.
The internet changes everything
How did this happen? With internet access came more online activity and an ever-increasing demand for code. Businesses recognized the need for process automation and reorganized workflows. As businesses dealt with the changes, the DevOps mindset started to infiltrate corporate software development. Services became repeatable patterns to be transformed into commodities. Infrastructure became more self-service.
Developers began to use provisioning software to access virtual machines. QA departments were transformed into software developers and overseers of automated tests. Static code analysis tools were used to determine if software would work as intended.
What was once a collection of distinct disciplines is now a mass of software development practitioners. Modern software developers needed skills far beyond the ability to code. The full-stack developer was born.
For the work that was yet to be automated, managers needed a global view of their environment so that developers could be assigned the correct tasks in an orderly way.
The real-time big picture
But today, information about that global view once closely held by project managers or department heads is made available instantly to developers. For instance, a technology such as Language Server Protocol (LSP) can deliver runtime performance information about code in production directly to a developer's IDE at "line of code" granularity.
When a developer installs certain LSP-enhanced extensions, they can go to a line of code in Visual Studio Code and see how that line of code performs in the most recent production environment. This immediacy can change how developers think about their work.
Since the developer can now see the totality of the information, here's where it raises issues about power in corporate governance, and where power should sit in the software development hierarchy. More to the point, should developers hold more power to make decisions?
A question of developer responsibilities
On one hand, you have the perspective of business theorist Peter Drucker. He asserts that the front-line contributor is the most expert about the tasks at hand, so let them do what they need to do. After all, you wouldn't want a hospital administrator to dictate to a brain surgeon how to perform brain surgery. On the other hand, you wouldn't want a brain surgeon to negotiate a labor contract with a healthcare worker's labor union.
Still, as access to information increases, developer responsibilities will only grow in kind. At some point, every company that makes software will have to come to terms with the developer power and scope question. Power without constraint is chaos.
My answer to the question is that developers should have as much power as possible. Progressive organizations understand that when you push power down as close as possible to the contributor, it creates an efficiency similar to a restaurant server bringing a customer a soda.
But this shift then leads to another question: What's to become of the manager?
Redefine the role of management
In a software development world, managers must move away from the command and control mindset and focus on observing operational activities and controlling access to the enterprise's resources. Access resource control can be as trivial as limiting the number of VMs a developer can use for development purposes to something as significant as access to a paycheck. If the developer is responsible and competent, they need to have the resources to do what they think needs to be done.
If a developer were to fail in their tasks or exercise poor judgement, management's role would be to cut back resource access and constrain the disgruntled developer accordingly.
With great power comes...
As developer responsibilities expand to encompass more access to the software development lifecycle, the considerate use of that information will become an aspect of their professional competency. Management's role shifts to one of true overseer -- ensuring that developers use their power wisely.
Ultimately, it will be the individual contributors that will call the shots. As such, developer responsibilities will go beyond the lines of code they write. They must exhibit the maturity and wisdom to use power in a responsible manner.