The document discusses 50 things that software teams should avoid doing related to architecture, code design, testability, documentation, team maturity and process. Some examples include treating a monolith as inherently bad, using microservices as an escape plan from technical debt, dogmatically using design patterns, insufficient test coverage, messy source control history, developers working in isolation, artificial sprint goals, and long-running stand-ups. The document is written by Dennis Doomen, an architect with 25 years of experience in the .NET space.

1. …on architecture, code design, testability, documentation,
team maturity and process
50(ish) things software teams should not
be doing…
Dennis Doomen

2. About Me
Hands-on architect in the .NET space with 25 years of experience on
an everlasting quest for knowledge to build the right software the right
way at the right time

4. Architecture

5. Treating a
monolith as
something bad

6. Micro-services as
an escape plan

7. Rebuild to break
with the past

8. Misalignment
with (non-)
functional
requirements

9. Cool technology

10. Extension points
and the
responsibility
that comes with
it

11. Misalignment
with team
organization

12. Tactical vs
strategic
inbalance

13. Layered
architecture

14. Code Design
#

15. Dogmatically
using design
patterns

16. Adding
complexity to be
future-proof

17. Organizing code
by technicality

18. Code structure
misaligned with
architecture

19. Code optimized
for writing

20. Obfuscating the
algorithm

21. Applying DRY
outside
boundaries

22. Too little or too
much logging

23. Using YAML for
anything but
simple stuff.

24. Testability
#

25. Not practicing
TDD

26. Insufficient test
coverage

27. Using code
coverage as a KPI

28. Using test-per-
class by default

29. Not
understanding
the internal
boundaries

30. Using DRY in test
code

31. Showing what is
not important

32. Hiding what is
important

33. Asserting against
production code

34. Not treating tests
as specifications

35. Testing more
than condition
per test

36. Testers doing
structured
testing

37. Tolerating
flakiness

38. Unrealistic
performance
tests

39. Not
understanding
what “concurrent
users” means.

40. Documentation

41. Maintaining a
central UML
model

42. Treating code as
the
documentation

43. Not
understanding
the audience and
actuality

44. Not
communicating
about internal
design and
pattern changes

45. Not capturing the
why, how and
what

46. Messy source
control history

47. Team Maturity
#

48. Use the right tool
for the right job

49. Ignoring the
phase of a
system

50. Developers
working in
isolation

51. Not refactoring

52. Ignoring
technical debt

53. Building the right
thing the right
way at the wrong
time

54. Messy pull
requests

55. Superficial or
delayed code
reviews

56. Not learning from
open-source
development.

57. Process
#

58. Treating user
stories as
requirements

59. Doing Scrum to
be agile

60. Being pedantic
about a stable
team velocity

61. Trying to assign
business value to
every user story

62. Artificial sprint
goals

63. Not burning
down your chart

64. Loosing sight on
the global
priorities

65. Long-running
stand-ups

66. Ignoring the WIP
limits

67. Not getting
things done-done

68. Intrusions that
hamper
productivity

69. Boring
retrospectives

70. Not using a well-
defined
branching and
merging
strategy.

71. Q&A