đź“ťThere are no boundaries in software development

§ Software Development #insight Dualities

All software development is the same. The boundaries between management, testing, programming, design, copy, and marketing are imaginary. There are no boundaries in the real world.

This is a subset of the larger Dualities topic.

Here is a list of “edge cases”—something different people may judge differently (or wouldn’t even know how to judge):

  • functional/non-functional requirements

    • sometimes non-functional requirements are functional. e.g., for a hard real-time system, the timing requirements are a function
  • software / hardware

    • firmware
    • microcode
    • is software flashed into ROM becomes a hardware?
    • ROM is actually re-writable nowadays
    • FPGA allow programming the hardware architecture
    • one of the first programming was done with wire jumping
    • software is designed an extension of hardware (configuration of hardware)
    • many features are possible to implement in either hardware or software
    • it is theoretically possible to implement any software entirely in hardware (given big enough hardware)
    • what is software anyways?
    • Hardware description languages (Verilog/VHDL) are very similar to programming languages (functional, reactive)
    • there is a Haskell-based eDSL for hardware description (you literally write haskell)
  • hardware / physics
  • digital / analog electronics

    • digital electronics is based on analog one
    • np-pn gates
    • wire length introduces timings which are not traditionally(?) described in digital electronics
  • design / psychology

    • design heavily draws from psychology
    • many design researches are literally psychology researches
  • software architecture vs design

    • architecture is highly subjective
  • language / library

  • language / package manager
  • language / editor

    • visual programming languages
    • structural editors
  • language runtime

    • even C has runtime library (crt0) (usually)
  • DSP/embedded
  • debugging/adding features

    • “bug” is itself subjective. What one considers a bug, another considers a feature
    • a bug that requires a substantial rewrite
  • testing/programming

    • TDD
    • reproducing an issue to debug
    • quickly checking how app works after implementing a feature
    • complex project require tons of testing code. E2E testing is quite a chord and requires non-trivial amounts of programming. Is it still testing or is it programming?
    • CI?
  • requirements/testing

    • BDD (proper)
    • test cases/use cases
  • design/programming

    • interactive prototypes
    • when I implement an app without thinking design upfront, am I a designer?
    • a programmer adjusting design to allow easier implementation
    • a designer doing html markup? markup in JSX?
  • design/marketing

    • user interviews
    • problem discovery
  • management/-

  • programming/infrastructure

    • local infrastructure? if it is complex and involves clusters (though, local)?
    • automating deployment
    • CI/CD
    • creating installers/packages?
    • when executing shell commands becomes programming?
  • programming/configuration

    • using header files for configuration
    • using shell files for configuration
    • using python files for configuration
    • awesome wm (lua configuration)
    • xmonad (haskell configuration)
    • NixOS (Nix configuration)
  • design/copywriting

    • when design copy becomes a standalone copywriting
  • marketing/sales

    • marketing is thought of as an input to sales
    • it is so hard to separate them, that Denis Dovgopolyi recommends having one KPI for both of them.
    • when sales communicates with the potential customer, they can discover what customer wants, so they can fuel the feedback cycle and actually dictate how product should look like.
  • How design blends together


Want to receive my đź–‹ posts as I publish them?