process of Engineering: chronological order
- User Interviews + User Stories
- Requirements Analysis
- Documentation and Specification
- Build the damned thing
- Build and Release engineering (TODO)
Other topics
- Query optimization (TODO)
Fucking acronyms to know
- AAA Method
- SOLID principles
- STAR method: state behaviorals in Situation, Task, Action, Results
fundamental trade-off of Software Engineering
The MIT vs. New Jersey problem: in Software Engineering, you can only choose one of FAST or ROBUST.
| Problem | Fast (“Bell Labs/NJ”) | Robust (“MIT”) |
|---|---|---|
| Specs | Whatever it looks like | screens, states, UI elements documented; transitions |
| Time | “whenever” | precise projections, track work and dependencies |
| Testing | “ran it + didn’t crash” | black, white box, code overage, edge/adv. cases |
| Modular | Giant function | object/data model, grouped function, abstraction barriers |
| Failure | Unpredictable + silent | Graceful, noisy, error reporting + logging |
| Language | Scripting, high level | Low-level, assembly/bare metal, control, can be difficult |
| Proto. | Many/Quickly | Few/Slowly |
| Being Done | Now | Later |
Source: here.
how to choose?
Which is the better approach? There isn’t one. However, here are some critical questions for you to answer:
- Deadline: what happens if you don’t finish today?
- Release cycle: if you ship a bug, how long can you fix it?
- Consequences: if the software malfunctions, how bad is it?
- Life-cycle: how long will the software get used?
So—
As consequences for deadline gets worse, trend towards fast; as consequences for failure gets worse, trend towards robust.