CSS 390: Notes from Lecture 1 (DRAFT)
Administrivia
-
Monday & Wednesday 8-10pm UW1-030
-
office hours: Sunday afternoons from about 1pm
-
course web site
-
syllabus
-
grading: 100% assignments
-
no midterms/finals
-
roughly 1 assignment per week
-
assignments due Tuesdays 11:30pm
-
try to get them done by Sunday to take advantage of office
hours
-
assignments should be small enough to be doable in the
timeframe but challenging enough to be interesting
-
latter assignments will build on earlier ones
-
for assignment
n,
you may start with someone else's solution to assignment
n - 1,
with their permission
-
assignments are to be individual efforts
-
comparing notes and helping each other out is encouraged,
but
know where to draw the line
and don't make me have to file paperwork (they don't pay
me enough to be a narc!)
-
if you copy from the internet,
cite your sources
-
don't expect to find exact matches for the assignments, so
you will still have to demonstrate real comprehension
-
limited feedback due to class size
-
re. wikipedia: the web site is peppered with references to the
wiki, but don't mistake that for academic-quality research
-
it's generally no more than a good starting point
-
go
is installed under
/usr/apps/go/hg/
on the Linux Lab machines
-
nonstandard location: make sure you set
GOPATH
&
GOROOTx
environment variables
-
metasyntactic variables: Greek/Roman and Norse Gods
Introduction
-
focus on implementation as a core skill
-
it is an
appalling
reflection on the state of the industry that the
fizz buzz
problem is considered a useful screening tool
-
basic assumption: you want to do this stuff for a living
-
i.e. you will be building stuff that someone is willing to pay
money
for
-
i.e. they are paying you to solve
their
problem
-
goal of this course (and university in general): to provide enough
background information to get started and tools to build upon the
foundation
-
if you don't know what
autodidact
means, go look it up
-
there is stuff you need to know that you can only learn on
your own
-
there is stuff you need to know that you can only learn on the
job
-
self-learning is necessary but not sufficient: purely
self-taught individuals often have
gaps
in their
knowledge
-
consider the Venn diagram
-
new, somewhat experimental curriculum:
mid-course
correction is possible, likely even
-
covers subset of
things I think you should know
-
I have some idea where I want to
go
with this course, but will adapt:
-
other topics you want covered
-
need to spend more (or less) time on some topics
-
assignments may be adjusted
-
you're beta-testing this, but I hope it will be worth
your time and effort
-
"Tactical Software Engineering": raises at least 4 questions:
-
what is "engineering"?
-
what is "software"?
-
what is "software engineering"?
-
what is "tactical"?
What is Engineering?
-
applied science to build stuff
-
collected wisdom ("best practices") to build stuff
-
before harmonic analysis, people still built bridges
-
sometime they stayed up,
sometimes not
-
bridges stayed up because the were
over-built
by substantial safety margins
-
engineering is about making tradeoffs to build stuff
-
resources are finite, including
-
requirements for a life-critical system are different than the
requirements for, say, a video player
-
pressure to build it faster and cheaper is leading to the
walmartization
of software
-
a cheaper, lower-quality solution
may
be the right choice
-
compare the $40
Snap-on
and the $2.99
Harbor Freight
pairs of
diagonal cutting pliers
-
if you're a typical homeowner, the cheap pair should
last a lifetime (you certainly won't go through 10 of
them!)
-
if you're a professional mechanic, you probably want
the more expensive pair
What is Software?
"Programs and other artifacts intended to be used and maintained by
persons other than the original programmers"
This definition highlights several key points:
-
more than just the program code
-
user manuals
-
requirements documents
-
design documents
-
build/test/deploy systems
-
configuration data
-
scaffolding
-
you're getting paid to solve a problem for
someone else
-
the problem is
usually
a moving target
-
requirements evolve, additional features added
-
the existence of a solution may create new problems
-
styles evolve (revamp that web site!)
-
software/hardware environments change
-
new releases of operating systems
-
tablets/mobile-aware services
-
multi-core systems
-
regulatory environments change (tax/healthcare)
-
bug fixes (generally a relatively small part of maintenance)
-
if successful, software systems will be maintained by people who
did not do the original development
-
maintainers did not make the original design decisions and may
not even be aware of all of them
-
loss of tribal knowledge
-
legacy systems
-
by definition, successful systems
-
typically mission-critical
-
if they fail, the organization goes down
-
irreplacable capital investment
-
progressively more difficult to maintain due to
accumulation of patches, workarounds, and kludges
Scale matters: the world is qualitatively different at different
granularity:
| Lines of Code (LOC) |
Required Discipline |
| 1000 |
math |
| 10,000 |
science |
| 100k |
engineering |
| 1M |
politics |
| 10M |
mob psychology |
-
a 100-line stand-alone program is completely different than 100
lines embedded within a large-scale system
-
the later requires awareness of dependencies and consistency
of style
All that stuff you learned about classes and modules and decomposition:
-
irrelevant
for 1000-line programs
-
essential
for 100,000-line systems
If a developer can maintain a sustained rate of 100 lines of
debugged code per day (hard to do!), a 100,000-line system requires
1000 person-days, approximately 5 person-years.
-
on a good day you might be able to write 1000 lines or more
-
on a really, really good day, you might be able to
delete
1000 lines or more
-
simplify complexity, e.g. data structure/algorithm
-
many days you may find yourself writing 0 lines
-
meetings
-
debugging
-
writing requirements/design docs
-
rework
-
meetings
