Things you should never do in software

TL;DR notes from articles I read today.

Things you should never do

• There is always a temptation to code from scratch rather than improve existing code because you may get a lot of excitement in building something grand. It is also harder to read code than to write it.
• You may assume the difficulty of reading and understanding how the old code works implies that you can write it better. This assumption is usually wrong because the old code worked and was tested and repeatedly debugged. New code will not automatically be better than old. What makes old code look messy is the patches.
• And there are things you can try to improve in messy code. Work on improving architectural problems that require refactoring, moving code around, better defining base classes and sharpening interfaces carefully and work on smaller inefficient parts of a project which you can speed up.
• Rewriting code from scratch is one of the worst mistakes companies/developers can make and should avoid. 


Full post here, 6 mins read

Seven deadly sins of a software project

“Maintainability is the most valuable virtue of modern software development.”

Do these seven things to make maintainable software.

1. Learn about elegant coding to avoid anti-patterns allowed by languages that are too flexible.
2. Ensure all changes are traceable (what was changed, by who, and why), by always using a ticket to flag any problem, referencing the ticket in the commit, and preserving its history.
3. Follow an automated process of testing, packaging and deploying for all releases to execute them from a single command line.
4. Enforce static analysis rules so no build can pass if any of the rules are violated.
5. Measure and report test coverage and aim for at least 80% coverage. This coverage metric also lets future developers see if coverage is affected when making changes.
6. Beware of nonstop development. Always release and versionalize software so future developers can see your intentions and roadmaps from a clear release history (typically in Git tags and release notes), and have each version available for download.
7. Ensure user interfaces are carefully documented to let the end-user see what the software does. 


Full post here, 7 mins read

When DRY fails

• DRY (Don’t Repeat Yourself) is about avoiding duplication of effort when writing the code. It also makes sure that when a bug is found it’s fixed across the board. Like many other principles, this one doesn’t work all the time.
• If DRY fails, it’s a good practice to reconcile. The simplest way to reconcile is to write a test that reads data A and data B and fails with a diff if they are out of sync.
• Try having a great test suite that’s ideally 100% coverage and 100% mutation tested that you can run on both pieces of code.
• Reconciliation does not mean synchronizing, overwriting,  comparing or even being disciplined and manually changing both places.
• Reconciliation means checking all the data regularly and reporting all discrepancies, including fine-grained discrepancies.

Full post here, 3 mins read

Get these notes directly in your inbox every weekday by signing up for my newsletter, in.snippets().