- After ejecting every function except writing code, development teams have been bringing those roles back to the core team, starting with QA, then product management, and now operations.
- The goal is deliver Frequent Functionality (features released more frequently rather than in big 12-18 month releases) and increase the value of the software by getting better and more feedback about how users are interacting with the applications.
- New innovations in automation, Agile development, and cloud computing are making this possible.
Developers are Insourcing
Developers have been in-sourcing tasks they’d previously jettisoned from their core functionality for a few years now and cloud computing has brought one more land-grab: operations. Agile tricked developers into caring about QA and testing, but also requirements and product management. Now, dev/ops is “tricking” developers to care about operations. I put tricking in quotes because the developers actually want this – the good ones at least. The benefits, or at least goals are clear: delivering software that users like with a more frequent cadence. Those are the two aspects of software development that most interest me now: frequent functionality and using rapid feedback-loops to improve the user experience and overall usefulness of the software.
A Brief, Hand-wavy History
At the very beginning, development teams did everything, or at the very least were intimately involved: gathered requirements, writing the code, testing the code, running the code. IT being expensive, organizations sought to divide up those tasks into shred resources, often under different management chains. Developers, of course, also just wanted to write code: not “talk with customers about what they needed” (requirements and product management) or keep their applications humming along nicely in production (operations).
Throw in mainframe MIPs accounting and high costs, and you can see how separating out those rascally developers from expensive mainframe toys makes business sense, at least in a spreadsheet. (Side-note: with the metered pricing of cloud computing, thus far there’s no reason to think that in 10 or so years, cloud computing resources will be any less iron-gripped controlled than mainframe resources – that is, use and consumption of them will be slowed down in favor of controlling costs. We’ll see.)
And writing and running tests? What developer wants to do that?
Agile Starts to In-source: QA
One of the emergent principals of Agile (perhaps an anti-pattern) is that once the core team who wrote the software gives control of that software to another group, overall quality tends to go down. This isn’t across the board, but you tend to see that. As an individual, if you don’t somehow “own” the software, you won’t give it the same love and care that an “owner” will. This applies to QA and operations, usually not so much to product management.
Agile is always trying to get developers to do more process. To own more of the software life-cycle. It never says this outright, but cynical developers will spot it right away: “wait, my job is to write code, not write-up use cases and rank them. Let alone help take care of my software in production, in the hands of dirty users. I mean: are you going to pay me more?”
Somehow, Agile got developers to care about QA. It started small with unit testing by promising, after a huge amount of initial work, to make them more productive. Then functional tests came in, and now if you’ve got yourself wired up correctly, you can test whole use cases (or “stories” to use the term Agile hid the dread “use case” behind).
The bigger win was getting QA to be part of the development team. In reality, good QA people are often the foremost experts on the product – they’re the ones that spend hours, weeks poking and prodding it. Getting their input, starting at the beginning, is a great way to improve software. As with developers who are writing and running tests, the QA person ceases to be “just QA”: they’re one of the many owners of the software.
“I take the requirements from the customer to the developers.”
Seeking feedback and rich interaction with users hasn’t always been a strong-point of developers. They haven’t wanted to do product management (in this context: figuring out what users/customers want and then prioritizing which ones get into which release). “That’s someone else’s job” is what you’d hear. As with QA, that role has seeped a bit into developers hands as well. There’s simply not enough time in the day to write code, test, and also do product management, so it’s probably a good idea to have a whole person filling that role: but, having that person be the sole conduit between developers and users is not entirely helpful.
Thanks to the ability to run software as a service (SaaS) and mature cloud offering, a lot of the feedback teams need to do product management can now be automated. If you’re running your application as a SaaS, you can see what every single user is doing all the time. It’s like you have infinite one-way mirror usability tests going on. Public web apps (Amazon, Facebook, etc.) have known this for a long time, getting into advanced practices like A/B feature testing: let’s release two different ways of implementing this feature to sub-sets of user group and see which one results in more book sales, and then we’ll switch everyone over the better one. What you’re driving at is feeding aggregated user behavior data into the product management process…
