Yes, you heard that right, I am old, well over 40. I can remember the wild west of software development when developers could do anything to a production database and deploy their own code by copying files from their computer.
Developers were able to break and deploy production systems with ease. Environments were never the same and developer could
skip test. However code would still get deployed to production in a quick manner.
During this early period in my career, I was given the nickname “patches”, because I would say I have a patch and can fix that. I was far from perfect, because I probably caused the bug 50% of the time. Again, not everything was all roses, we did break stuff in production frequently.
The Enron and WorldCom accounting scandals ruined the parties. We ended up with legislation commonly known as SOX and companies started to control what developers could and couldn’t do. Companies hired consultants and outside accounting firms made a killing telling companies what rules they have to put in place. These were draconian and a knee jerk reaction, which created an oppressive amount of control that did little to nothing but allows others to shift blame.
Gone were the days of developers deploying code to production. Now they had to type up massive deployment scripts in word to pass along to the “release” team. A lot of time there is errors and frustration on both sides. Developers watch someone else click a button. There is also really no protection for the organization because the “release” team is just done what they are asked to do.
Developers had barriers everywhere they looked to getting code in production. If I needed a datasource configured for a database, then I needed to contact middleware admin, same for things such as namespace bindings, and all sorts of settings. The middleware admins didn’t understand the application and in large part the developers did not understand the nuances of the production application server. Because of course, we used Tomcat to develop locally and not WebSphere because it was too slow.
Over the course of time additional teams were added to protect the business. Adding additional teams such as security, you ended up with more churning than delivering. I remember working on a project that put in over 200+ tickets for other teams within a 3 month period. Developers became ticket chasers and created little or no business value. Frustration levels rise, staff leave and nothing gets done.
Software is not building widgets and the dependencies between groups are not always linear. Developers need to experiment before they know what they may or may not need. Once they figure it out they need to be able to move quickly to make sure code is merged and moved to production so the next thing can be worked on. Developers have the ability to write unit, integration and functional tests to make sure their code won’t cause harm to a production system. Developers pairing with another developer can help catch syntactical bugs and collaborate on possible solutions before the code is even committed. This is not the same as the wild west, but small tested changes going into production. The use of CI/CD platforms and testing frameworks makes this possible.
Cloud technologies have allowed developers to experiment, with new services and infrastructure without long term capital expenditures. Companies only pay for what they need. Most cloud services and infrastructure can be scripted using tools such as Terraform. This means developers have the ability to create their own infrastructure without involving other teams. Disciplines such as high availability and disaster recovery can be implemented with simple configurations. Code and infrastructure can move up the region or environment pipeline together in concert avoiding the “it works in development” problem.
SOX never stated that developers cannot deploy their own code, instead is stated the CFO and CEO had to sign off on the company financial statements and be held accountable. Having seperate teams of folks that just process tickets didn’t bring any accountability. It just lets the developer say, Brandon or Tim processed my ticket, while I messed with the books. But its not my fault, because I didn’t put the code in production. If you want to protect your organization, have developers pair or approve each others pull requests. If they write code that is taking the partial cents and profiting, then they have committed collusion and there is a digital trail.
So you have a security team and a middleware team and a dba team, etc.. Aren’t those special skills needed?
Isn’t this an opportunity for those folks to learn new skills? Maybe setup a career path within your organization.
Technology is ever changing, as a developer I started out my
Folks should embrace this change as an opportunity. It would also be great to have a security person on the team, someone you could ask about best practices. What about an operations person that can help you decide what to monitor?
Organizations that don’t experiment quickly, decide what is viable and move on, won’t be around in the future. We have seen this over and over (BlockBuster, Kodak). Not everything you do will be profitable, but if you don’t get it to market quickly you will never know and someone else will! If it isn’t profitable and taking resources you need to also be able to pivot quickly and try something new. Your organization can adopt this mindset and can do it quickly when forced to do so. Look at how the last several weeks have changed all of us. You are probably working from home or a remote office, holding meetings via Zoom and wearing pajama bottoms at the same time! I bet 2 months ago you didn’t see yourself doing that.
I keep seeing posts about how Dyson was able to create a ventilator in 10 days and get it to market. That didn’t happen in just 10 days, it happened with an agile mindset and the ability to pivot without destroying the company in the process.