Being able to write large swaths of code from scratch quickly to spec and with few errors is very valuable in software companies that want to move quick. Especi

Being able to write large swaths of code from scratch quickly to spec and with few errors is very valuable in software companies that want to move quick. Especially when experimenting or prototyping. But if you are building a larger, longer lasting product with even a modest sized team you will run into trouble quickly. Not many developers practice throwing their code away and taking a different approach when requirements change. If every release the codebase changed completely other developers wouldn't be able to keep up. This is especially true if this developer is working on the basic arcitecture of the program. You can't re-write everything every release. Planning has its merits. So if the developer was we-writing it every time, but came closer to a better, more permanent solution each time, then he is learning and evolving and this practice will slow down. However, if he is simply producing low-quality code and cheap tricks to ensure proper behavior, while it works now that talent doesn't scale well and will impact the performance of other team members. You want to promote code stability - and this isn't held in the state of the codebase and passing tests as much as it is the net effect of developer behavior over time. I agree that we all can't just go to the unicorn store and solve our problems. But be conscious of the side effects you buy when you start thinking about it as managing a team and not building one. *edit: Matt Rogush said it better