Software developers created the idea of an “antipattern” to warn others what not to do. Think of the “Dragons Be Here” label on old maps. Whatever you do, don’t sail your ship here.
Years of hard-won experience are boiled down to a concise description of how not to structure your code, how not to imagine your architecture or how not to design your database schema. These antipatterns have become so useful that they’re passed around among developers with as much reverence as functional design patterns that describe how one should do things.
Software project management has its own “antipatterns”: Seemingly sound practices that hard-won experience suggests we shouldn’t actually do. Running a project and managing a team is less of a science than spinning up code, of course. Some antipatterns are mirror images of each other: They command you to embrace and eschew the same thing. But what they’re really asking for is moderation. Too much of any idea — no matter how good it might be — doesn’t work so well in managing teams.
Read More from This Article: 11 leadership practices that could sink your software project