#Issue23
3 posts

How to start a software project with a quality mindset

Start documentation from Day 1. Begin with a README file for other developers: introduce the project, explain how to run it locally and/or contribute to it. Develop a separate product manual for end users.
Read more

How to start a software project with a quality mindset

  • Define the development process comprehensively, including tools & technologies you will use, strategies for issue tracking, and who can add & merge new code.
  • Start documentation from Day 1. Begin with a README file for other developers: introduce the project, explain how to run it locally and/or contribute to it.
  • Develop a separate product manual for end users.
  • Define and enforce coding standards for consistency.
  • Set up static analysis tools to detect code smells of deeper structural problems, such as dead code, code duplication, etc.
  • Develop a strong automated test suite. This can also serve as documentation for all possible use cases.
  • Automate the setup of a local environment as close as possible to the production environment. Make sure dependencies are updated in this setup as features get added or new versions deployed.
  • Build a stable and automated delivery pipeline with the requisite checks before you can deploy.

Full post here, 14 mins read

The Law of Leaky Abstractions

All non-trivial abstractions, to some degree, are leaky.
Read more

The Law of Leaky Abstractions

  • Abstraction hides something complicated going on under the hood and presents the user with apparent simplicity.
  • Sometimes the underlying layer, which is problematic or complex, leaks through the abstraction.
  • The law of leaky abstractions (as defined by the author): All non-trivial abstractions, to some degree, are leaky.
  • The only way to recover from a leaky abstraction is to know what is being abstracted in the first place.
  • This means you need to learn about the underlying complexities or the logic of some of the unreliable layers, and how to work with them the hard way, without the abstraction.
  • An abstraction does save time when you are working. But if you take learning shortcuts, and have not mastered the layers and procedures behind the abstraction, any bugs from a leaky abstraction will be difficult and time-consuming to catch, let alone fix.

Full post here, 10 mins read

SOLID principles every developer should know

Single responsibility, open-closed, liskov substitution, interface segregation, dependency inversion
Read more

SOLID principles every developer should know

Single responsibility: Every class/software component/microservice should have only one job. Do not let them become coupled with others.

Open–closed: Classes/modules/functions should be open for extension, not modification.

Liskov substitution: A sub-class must be able to substitute for its superclass without errors.

Interface segregation: Make interfaces client-specific. A client function should not have to depend on an interface they do not use.

Dependency inversion: Depend on abstractions, not concretions. Do not let high-level modules depend on low-level modules, let both depend on abstractions. Details should depend on abstractions, not abstractions on details.

Full post here, 12 mins read