Comment by cad1
3 years ago
“Almost every software development organization has at least one developer who takes tactical programming to the extreme: a tactical tornado. The tactical tornado is a prolific programmer who pumps out code far faster than others but works in a totally tactical fashion. When it comes to implementing a quick feature, nobody gets it done faster than the tactical tornado. In some organizations, management treats tactical tornadoes as heroes. However, tactical tornadoes leave behind a wake of destruction. They are rarely considered heroes by the engineers who must work with their code in the future. Typically, other engineers must clean up the messes left behind by the tactical tornado, which makes it appear that those engineers (who are the real heroes) are making slower progress than the tactical tornado.” ― John Ousterhout, A Philosophy of Software Design
I remember reading somewhere people can be broken down into 3 types. It applies in programming as well as in a restaurant kitchen or your family's garage cleanup.
*I'm probably remembering everything wrong but it was something like:
Cowboy: move fast and break things style. Sorta what you mentioned above.
Duct tape: most people are a form of this. Work on something just long enough to get it working but it's not beautiful and not prepared for the future or edge cases.
Professor: these get very little done because of the amount of planning put in and tend to over think most things. But almost never have to come back to a job since it's done properly and to completion.
Any team without a blend or with too many cowboys or professors is going to have a tough time.
That's why I refuse to touch code made by these tactical tornado. It's simple, you'll get all the blame, and none of the recognition. Anyone who is in that situation: Don't it even if it means you'll get fired. You'll get fired anyway.
The only exception is, if management come to understand what went wrong there and how it should be done. The chances of that are very slim, however.
Peer reviews catch tactical changes that are strategically poor. There are times when it won't get sign-off from reviews. In other times, when it gets merged, at least it is documented that the solution is tactical, people know it, and it was rationalized by the team. A plan may even be put in place to revisit the subject and do a proper job; there could be concrete ticket for that.
Reviews also slow things down. You can't move quite as fast and break as many things if everything goes through a review pipeline.
Test-oriented development helps. Sometimes people find it easier to develop a tactical solution that somehow gets certain tests working and then refactor for strategy. They don't have to feel they have wasted time on the tactical solution because they get to reuse parts of it, and use it as a jig to guide the improved solution.
Ron Garret's space debugging story from NASA has an element of this. They had a custom language in Lisp which made certain guarantees, like deadlocks being impossible. But some coder went around it, possibly due to a tactical reason, using some lower level code outside of that paradigm.
Sometimes people aren't being tactical; they really don't understand the system fully to know that some obvious solution will hit a snag.
This lines up with my experience. The person making constant "tactical" changes looks super productive. But they just deferred the productivity cost. You end up continuing to deal with their fragile mess for the rest of the lifetime of the product.
I fully understand that there are circumstances where true tactical changes do make sense, but the tradeoffs should be considered up front.
The way to handle this, I believe, is to make sure that the bug reports resulting from the "tornado"'s work end up back in their own lap. Don't let someone else fix them, especially not someone on another team. It has to be done non-antagonistically, of course. But it's the only way to make it clear to both management and (more importantly) the dev themself that there is a tradeoff for speed.
The most productive people also tend to write the highest quality code, in my experience