I’m going to a lot of software development conferences and working in some program committees trying to select sessions about the hottest new trends. If you do this for a few years you see hypes come & go like SOA, ESB, MapReduce, BPM and so on. But once in a while there is a revolution that changes the way we work and think about development like Object Oriented programming in the 90’s and Agile in the 2000’s. I can see a next revolution happening right now. Unfortunately it doesn’t have a couple of smart people coining a term, it’s just me calling it Empowering Developers.
Care More
The old generation
I had some managers in the past that thought adding processes and having specialists was a good idea. It was not! Fixed processes stopped us from improving the way we work, working together and fostered specialism. We had requirements, database, design, QA & It-operations specialists. Developers were just supposed to take their task and code it. They were responsible for the code itself, but not for the functional quality, the usability or the operation part. It was comfortable but also frustrating.
The next generation
I can see the trend that developers are testing their own software. Not just TDD but also through exploratory test.Most of software developers nowadays knows the writing automated tests & let them run on every code change is important to know if we introduced a new bug. As Zach Holman says “You can have the best, most comprehensive test suite in the world, but tests are still different from production.” Having a staging environment and let the team members test the code manually is another way the secure that you have less bugs. Don’t wait until your QA team have time to try the new feature. Let your team members try the new features as part of your development. In the JIRA team we actually have around 65 developers and just 6 QA people. Here’s a presentation how they deliver Quality at Speed.
Technologies like Microservices in combination with Docker helps us to be responsible for the operation of the software. We can deploy & control small chunks of code and be responsible for the whole software development chain. Breaking work down into smaller services from the requirements over quality checks to the operation side empowers the developer to care more about the software he created.
Also if developers don’t use these new fancy technologies it is still important to care more about the software we build. If the design shows flaws it is our responsibility not only to blame the designer but to jump in and fix it. Care more!
Fail Faster
The old generation
I’ve been working in organizations where I got blamed that a customer reported a bug. Bugs were not acceptable. I think one of the reason why people were afraid of making mistakes was that it was a long procedure to update the software even though it was running on a central server (these days we call it the cloud). Testing new versions took a day, the whole system had to shut down for 20 minutes, it was hard to merge the patch into the current development source code and so on. Failure was not an option. A mistake meant angry customer, 2 days dragged away from the current development and normally the whole team got involved.
The next generation
Failing faster means to catch possible bugs earlier in the process before the code hits all customers. The next generation developer have tools to optimize code debugging and have a process in place that fosters peer reviews of every new written line of code. To avoid obviously failing code on your main line, source control systems like Git in combination with a workflow that allows you to review code before it hits the production branch. Tools like Gerrit, GitHub, Bitbucket, Gitolite and Stash helps you to easy discuss code changes with the team and to fail faster.
But sometimes bugs hit the production server no matter how sophisticated your dev process is. To make that impact as small as possible the next generation developers know that they have to create a system where they can roll out patches automatically very fast, have good tools to monitor the performance of production systems and can deploy changes just to a subset of their user base so a new bug can just be experienced by some users. These developers know that they are responsible for the running software, their performance and scalability. They work close together with operations to put the best systems in place to catch bugs early and to roll out changes fast with confidence.
What people holds actually back from deploying with confidence is the automation part. The Atlassian build engineering team have created a system to grew this confidence for developers. Peter Leschev talks more about the details about this in his “Infrastructure as Code” video. Tools like Vagrant, Packer & Puppet helps us to encourage people to deploy software more frequently and to fail fast and fix things faster.
As you can see failing faster has a lot to do with automation but also with giving people confidence. If developers are afraid to put code in production they will do it less frequently and therefore it’s always a big event instead of a job that we do 10 times a day. The next generation developer has the power to deploy software & update it fast themselves without waiting on others people.
Be Creative
The old generation
It was hard to put a new idea into production. Developers were just working on features that a product manager has added to the backlog. There was no slack time to try out new things & coming up with creative ideas. There was a process for customer requests but no process for spiking ideas from developers.
The next generation
Developers get time to be creative. Managers knows that their developers can balance their time themselves and that developers know how important it is to solve customer problems and how much time they can spend on working on new creative stuff. Concepts like 20% time, hackdays and innovation weeks helps the next generation of developers to work on new innovative features.
But creativity is also needed when developers needs to create planned features. The next generation of developers are involved in feature design & user story mapping. They understand the problem, the different personas that will use the feature and discuss solutions with designer, product owner and other stakeholders. They play an important part in finding the right solution and understand deeply the needs of the business. We at Atlassian use Personas to keep our developers engaged with the functionality they’re implementing.
Go Team
The old generation
We were collecting specialist in a team. Teams that were responsible for the performance, another team for the database, and another one for the front end. Feature planning needed to be done across those teams which was often very frustrating. Communication between those teams were done in regular meetings or through emails (without all team members on the thread). This all led to big bang releases where we were trying to put the different development threads together.
The next generation
The next generation developer still work in a team. But their responsibility is for a whole functionality. The teams doesn’t only consist of just experts. Every developer in those team have the power to change the database schema, write front end code, design the UI, test the features from other team members and talk to customers about requirements. They are just specialized for their certain feature set like ‘Making it easier for new customers to work with the software’ or ‘Scaling the software for a huge customer base’. Sometimes teams are just formed for some time to develop a certain epic that contains of a couple of user stories. They care deeply about this feature. Of course: Microservices are making it possible that those teams can deploy their features independently from other teams.
Communication is very important for the next generation of developers. Everyone has all information at hand. Team members are using chat rooms for communicating transparently. This helps for people staying in the zone for a while but never miss a team conversation. These devs grew up with Facebook & Instagram, so sharing knowledge and experience with technology is natural for them. At Atlassian we connected our team chat rooms with our automated systems, so everyone can see when we deploy the software to staging or production, when a customer reported a serious bug, when code is ready to be reviewed or when the build failed. These information are essential for us to move forward quickly and keep everyone informed.
Every team can decide the way they want to work. If the current process doesn’t fit for the actual task they have the power to change it themselves. Teams are more like small lean startups within the larger organization. There will be of course still interacting with other teams but it will much less than having 100 people working on the same monolithic code base and application.
The Next Generation Developer
Developer will have more freedom but also more responsibility for the features they’re developing. Even though some companies like Google, Apple, Atlassian and Spotify are starting to work this way it’s still a long way until this hits the majority of companies. But this way of working results in happier developers and better products, so I’m looking forward what we can accomplish with the next generation developer.
Sven Peters 