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 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.)
- Personnel Interaction/Culture
- Project Management
- Continuous Integration and Deployment
- Source Control
- Web UI framework
- Web Api framework
- 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.