One of the great killers of software projects, its potential and the commitment of (future) assigned developers, is going fast and making a mess in the process. The video at the bottom, describes tactical vs. strategical programming in a nutshell.
What can a developer do to combat this?
A first, would be to educate oneself on topics revolving clean code and clean architecture. More specifically, in the principles and patterns resulting in such practices. Although there are many books and video's to learn from, working with a peer developer who applies the above, can be invaluable.
Think critically about the code you write, "Think twice, code once.". Improvements can range from the usage of logical operators to leveraging external solutions, productivity-boosting tooling, ...
You can often write it with less lines of code and improve its readability for your teammates. Aim to leave a codebase in better shape than you found it. Take it one step or one ticket at a time, separate yourself from the "code monkeys".
Optimize and fully utilize your tooling for increased productivity while minimizing code smells or bug potential. This encompasses the features of your programming language, frameworks, IDE plugins and beyond automated release cycles. Don't "half-ass" or refuse to evolve the above since that will only decrease productivity over time. There are plenty of proven systems to adopt, no need to reinvent these.
I can see how, from a business perspective, tactical programming might appear to be praised in the short term but will lead to technical debt in the long term. Sooner rather than later. As tactical programming has its perks, it's the lesser advisable approach to be used beyond a concept phase.
What can an employer or project manager do to combat this?
Hire proven, quality competence for your back-end systems. As quantity in years might improve your odds, it's unfortunately not a guarantee. Recruiting for battle-tested programming language frameworks might improve the odds. Once obtained, it's an idea to pair them up with rookies on a new project, when possible.
In time, your development team might live by great coding practices, delivering highly maintainable projects which in turn frees up time for bullet-proof technical decision making. Don't allow for bad practices to train your rookies, as described in the video below.
Entertain your developer's requests for improvements or refactoring. Involve them (more) in crucial technical decision phases. Phases to tackle structural or procedural improvements should have a place in any software project. Not to be shrugged off as "unbillable". It pays in the long run by preventing frustrated developers and dissatisfied clients.
If possible, don't take on existing projects another tactical development team already ran through until they could no more. You're likely to repeat the cycle the video describes. If you do, be very transparent about it to your development team or new hires. It's dirty work.
You don't have to take my word for it, watch the video, it describes many software projects. Clean Code - Uncle Bob
If you are interested to see my work, you can find it:
- on my website: kiss-code.com/products
- on my Patreon
- on YouTube
Subscribe to my newsletter to stay up-to-date & receive discounts.
Top comments (0)