I break down Software Development down into, roughly, three main roles:
Each role breaks down into sub-roles (see section Roles).
I fashion this breakdown by observing the breakdown in traditional engineering - e.g. structural architecture/engineering/construction.
Coding is done only by Software Implementors. Software Architects produce the initial design, Software Engineers look after details and Software Implementors write the actual code.
Testing requires someone to think deeply about what it means to test the product, and creating procedures for testing.
Thinking about testing means, at least:
Traditionally, all of the above work has been done by implementors, often called engineers (a mis-nomer).
Conflating work is a sure way to lengthen deadlines.
Some people are good at thinking about libraries (and knowing what exists and what to avoid), some people are good at black box testing, etc. Forcing one person, or one group, to deal with all of the issues produces uneven results and scheduling problems.
|
Role |
Sub-role |
technologies |
comments |
|
Software Architecting |
|
|
|
|
|
|
multiple paradigms |
|
|
|
|
|
generalist |
|
|
|
|
must understand multiple paradigms |
|
|
|
|
c.e.g. (counter e.g.) everything is Haskell – no |
|
|
|
|
c.e.g. everything is an Object – no |
|
|
|
|
c.e.g. everything is <xxx> - no |
|
|
|
|
|
|
|
|
whiteboards |
|
|
|
|
diagrams |
|
|
|
|
code snippets |
|
|
|
|
pseudo code |
|
|
|
|
SCLs |
like DSLs, except more focussed |
|
|
|
|
shows ability to view problem from many angles |
|
|
|
Drakon |
http://drakon-editor.sourceforge.net/ |
|
|
|
StateCharts |
|
|
|
|
UML |
|
|
|
|
indirection |
|
|
|
UX Architect |
|
|
|
|
|
UX design is a divide-and-conquer activity |
|
|
|
|
|
design a rudimentary piece of the UX |
|
|
|
|
test it (for UX-ness, not for robustness) before proceeding |
|
|
|
|
(earliest drafts tested by Architect and Engineers ; later drafts tested by Customer (Stakeholder) |
|
|
|
|
once designed, Engineering makes it practical and robust |
|
|
|
Humane Interface |
Jef Raskin |
|
|
|
The Design of Everyday Things |
Donald Norman |
|
Engineering |
|
|
|
|
|
Realization Engineering |
|
|
|
|
|
|
define first-cut of realized architecture |
|
|
|
|
iterate design with Architect until realizable and all I’s dotted and T’s crossed |
|
|
Correctness Engineering |
|
|
|
|
|
proofs, etc. |
|
|
|
UX Engineer |
|
|
|
|
|
|
define parameters & timing for responsiveness |
|
|
|
|
usability testing |
|
|
|
|
feedback to UX architect |
|
|
Error Handler Engineer |
|
|
|
|
|
|
analyze testability of product ( & suggest changes) |
|
|
|
|
create procedures / scripts for Q/A |
|
|
|
Throw / catch |
|
|
|
|
Signals |
|
|
|
|
Events |
|
|
|
|
A.O.C. (Aspect Oriented Programming) |
|
|
|
Maintenance Engineer |
|
|
|
|
|
Refactoring |
|
|
|
|
D.R.Y. |
|
|
|
Optimization Engineer |
|
|
|
|
|
Profiling |
|
|
|
|
|
remove Architectural indirection if appropriate |
|
|
Security Engineering |
|
|
|
|
Test Engineer |
|
|
|
|
|
Incoming Test |
test suitability of all bought-in technologies (e.g. code from GitHub) |
|
|
|
Black Box Testing |
|
|
|
|
White Box Testing |
|
|
|
|
Q/A |
devise ways to break product |
|
|
|
Scripting |
|
|
|
|
Back-to-back testing |
large systems can feed inputs to same kinds of systems |
|
|
|
Sikuli |
|
|
|
Release Engineer |
|
|
|
|
|
CD |
|
|
|
|
Dashboards |
|
|
|
|
CI |
|
|
Implementation |
|
|
|
|
|
Q/A |
|
|
|
|
Maintenance |
|
|
|
|
Testing |
|
|
|
|
|
Hardware production test used HP Trace Analyzers that would generate a GUID for every test (including sequencing over time) for a “golden unit” (known to be good), when GUID didn’t match in production unit, then further testing was used to determine where the fault was (kind of a Canary CI, replacing Unit test with faster/cheaper tests which signalled Go/no-go only) |
|
|
Teaching Software to Children |
|
|
|
|
|
|
different set of concerns than providing tools to Professionals |
|
|
|
|
Rhetorical Question: would you drive across a bridge designed by a gifted child? |
|
|
Software for Business & non-programmers |
|
|
|
|
|
|
Rhetorical Question: would you drive across a bridge designed by a Professional who isn’t an Engineer? E.g. a Dentist? |
|
|
|
Word |
|
|
|
|
Excel |
|
|
|
|
Visio |
|
|
|
|
Scapple |
|
|
|
|
Scrivener |
|
|
|
Software for Domain Experts (not Programmers) |
|
|
|
|
|
people with expertise who see a need and want to learn “just enough” programming to fill that need |
|
e.g. accounting software |
|
|
|
HyperCard |
|
|
|
|
VisiCalc |
|
|
|
|
absolute addressing |
|
|
|
|
grid layout (VisiCalc) |
|
|
|
|
fixed layout (HyperCard) |
|
|
|
|
few options |
|
|
|
|
“obvious” |
|
|
|
|
|
|
|
Software Designs Based on Existing Paradigms |
|
|
|
|
|
|
transitional (only) |
|
|
|
|
will be supplanted by designs |
|
|
|
|
desktop |
|
|
|
|
filing cabinet |
|
|
|
|
typewriter |
|
|
|
|
Netflix |
old, but similar paradigm: TV |
|
|
|
blogs |
old: magazine articles |
|
|
|
tablet, phone |
old: typewriter keyboard |
|
|
|
cell phone |
old: home phone |
|
|
|
Amazon |
old: retail |
|
|
|
internet |
old: libraries |
|
|
|
|
old: do we need an O/S? |
|
|
|
IoT |
old: expensive all-in-one computers |
|
|
|
|
old: desk calculator |
|
|
|
loops |
old: piano |
|
|
|
|
old: recording soundboard (e.g. mimicked by GarageBand, ProTools) |
|
|
|
video+audio, YouTube |
old: audio |
|
|
|
|
old: whiteboard |
|
|
|
WFH |
old: office |
|
|
|
condo |
old: house |
|
|
|
bicycle, fat bike, ebike, public transit |
old: automobile |