Some teams have “rockstar” developers who only work on “spikes.”
A spike is a story where a developer is assigned the task of figuring out how to accomplish something. The outcome of a spike is a prototype, or roadmap for reaching a prototype. Included in the task might be to evaluate different methods of accomplishing something, do you use one database or another? Or a spike might simply be to try out something that was discussed with the greater group, seeing that a simple end-to-end implementation can be accomplished.
But that outcome is not production ready.
Some managers don’t understand this. They see a working prototype and push to have it deployed ASAP, then push for the next feature to be developed. These “rockstar” developers tend to not understand this distinction either. Which indicates, really, that they’re not quite as talented as they may think.
The problem with prototypes is that you won’t have tests in place, you didn’t evaluate the performance of the solution, you haven’t evaluated how secure it is. You’re not worrying about maintaining the solution over the long term.
If a rockstar developer is only focusing on spikes, essentially they get to do all the fun discovery work, without having to figure out and implement the elements of making something stable, lasting, and secure, and so many other things needed to make the solution production ready.
The problem with having one developer that does this is that they get credit from the “powers that be” that they’re accomplishing, but they’re leaving the rest of the team to do the hard work.
The rest of the team has to squeeze, in between whatever other tasks they’re doing, all of the things needed to make the “rockstar’s” code performant.
This is bad. Don’t let it happen to your team.
Know what else happens, when you let one developer do all the fun things? Because not enough time is invested in making sure the code going out is production ready, there are bugs. Which the rest of the team is saddled with.
Your team will be focused on fixing bugs and they won’t have time to develop features. Your team’s productivity will crawl to a halt. You wanted to go fast, but you’re actually just piling more work on everyone.
The rest of the team will HATE your “rockstar,” your development cycled will crawl to a halt, and your product with suck.