đź“ťThere are no boundaries in software development
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 List of 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
is standard library a part of language?
foreach (syntax) integrates into Iterator interface (library)
why not other libraries?
especially visible in small languages like Lisp or Smalltalk
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/-
scrum
team lead
running meetings
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.