I've been wondering lately about what practices, if changed or improved, will do the most to help a software development team.

Personally, I'm interested in maintainability and automated systems. My question is: how to design so it's as easy as I can make it for someone else to bring my code up-to-date. This is never really just swapping out old stuff. I've been convinced for years that such a nirvana is not only unattainable, but wrong to seek. But having a museum of programming approaches makes technical debt hard to pay. It's not a matter of changing technology, or embracing yesterday's shiny article. It's building into the environment the practice of maintaining old code as a requirement. The adage "if it ain't broke don't fix it" doesn't apply to a software-dependent company (if it applies anywhere). The Japanese word kaizen indicates a better approach: continuous change for the better.

Here are some notes I've made. By doing this, and based on years of experience and study, I came to a conclusion that won't be astounding to most people, but bears calling out.

Improving team communication will yield the biggest long-term benefit in the shortest time.

Key Goals

  • Maintain
  • Automate
  • Test
  • Communicate

Key Principles and Practices

  • Prefer smaller changes rolled out frequently
  • Reduce platforms and frameworks
  • Have routine, effective code reviews to improve maintainability and communication
  • Ruthlessly improve code to be "as if had always been that way"
  • Struggle with naming. To name well requires understanding how others think
  • Have routine strategy sessions away from the workplace
  • Use in-house templates and libraries for consistency
  • Maintain all code as if it were a top-tier open-source project
  • Use smaller projects to try new technologies. Either the new project will get normalized, or pieces from it will be applied to existing projects. (Or some combination of the two.)

Key Areas

  • Personnel Interaction/Culture
  • Security
  • Project Management
  • Continuous Integration and Deployment
  • Source Control
  • Testing
  • Web UI framework
  • Web Api framework
  • ORM
  • Database
  • Architecture (DDD, etc.)

There will be natural overlap in these areas.

Improving which of these yields the most return? I would look at what improves communication first (project mgmt, Agile-based methods, studies on successful teams). Without communication and agreement, it's very difficult to improve other areas. I also think Security needs to be part of everyday work and thinking. Next, CI/CD, Testing, Source Control. Getting CI working will drive a lot of improvements. Then, the stack.

I'll either update this post or follow up on it in a second part.