Introduction

I break down Software Development down into, roughly, three main roles:


  1. Software Architecture
  2. Software Engineering
  3. Software Implementation


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

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

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.


Roles


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
based on computing-driven
paradigms



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