🏁
Best Practices
  • Introduction
  • The Big Picture
    • Principles
      • Software engineers solve business problems
      • Programming is a social activity
      • Attention is the most precious resource in a project
      • Simplicity is the best ally in the long run
      • The only problem to solve is the one we have today
    • Architecture
      • Domain
      • Services
      • Persistence
      • HTTP
      • UI
    • Naming
  • Constraints
    • TypeScript
    • Monorepo
    • Monolith
    • Versioning
  • Source code
    • Declarative programming
    • The README
    • Modules
    • Folder structure
    • Code formatting
    • Code comments
  • The Outside World
    • Runtime configuration
    • Logging
  • Testing
    • The purpose of testing
      • End-to-end tests
      • Integration tests
      • Unit tests
  • Tools
    • Git
  • Resources
    • Resources
Powered by GitBook
On this page

Was this helpful?

  1. The Big Picture
  2. Principles

Software engineers solve business problems

PreviousPrinciplesNextProgramming is a social activity

Last updated 5 years ago

Was this helpful?

There are many reasons to write software: for fun, for learning, as a hobby, often as a job. In our context, as an application developer team, we write software to solve business problems.

Few people care about the intricacies of programming outside the developer community. What people crave are solutions, regardless of the implementation details.

When it comes to decisions about technology or processes, the fundamental question then should be: how will this move the project towards the ultimate goal - delivering a solution?

This type of thinking can prevent technology choices that are motivated only by curiosity (also known as "CV Driven Development") or the imitation of others.

Create a minimal end to end journey as soon as possible. Treat it like a skeleton and add the "meat" later. A working draft brings clarity by serving as a roadmap towards essential goals. Knowing where to go helps avoid getting bogged down in details (over-engineering), leaving no time for crucial features (under-engineering).

Code is a means, not a goal. Writing more doesn't necessarily help. Adding code is not always the answer - keep the priorities in mind.

Clients expect software systems to work for an extended period and also to evolve as requirements change. So we can't be too myopic. But .

today has priority over the uncertain future