Planning
   Purpose
   Insight and foresight
   Justification & feasibilty
   Knowledge of data
   Target audience
   Development time
   Novelty - not reinveting the wheel
Software Architecture
   Algorithms
   Complexity
   Maintainability
   Extensibility - Plugins & Standard software extensions (extensions through derivations, for instance)
   Reusability
   Scalability
   Compatibilty
   Hardware/Platform
   Tech stack
   Use of existing libraries/framework
   UX
Development
   Team work
   Bleeding edge (staying at)
   Iterative development
Testing
   Correctness
   Completeness
   Robust
   Reliability
   Stablity
   Testability
   Performance
   Security
   Privacy
Managing
   Cost
   Marketing
   HR
On-going work/costs   
   Documentation
   Adapting to demand
   Refactoring

Plugin - Architecure
1) Someone else writes it (division of labour)
2) Pick and choose - don't have to use them all - better performance with lesser plugins - venodor can extend their software after original publication 
3) Provides extensibility
4) Requires architectural support - means we need a good insight and foresight
5) The complete architecture could be a set of plugins. Plugins could have plugins. bit like Legos. Need to ensure that the whole thing does not collapse over itself.
6) Should treat plugins with the same respect as other standalone software (security threats, vulnerabilities, performance issues, etc)


Compatibility
1) Software evolves. New version software needs to operate with old version software - maintain functionality.
2) Backward & forward compatibility
3) Using XML (eXtensible ML). Provide perpetual support for old versions. Ignore new functionality that you don't recognize. Ignore data that you don't recognize (data needs to be identifiable). Keep one version (current) but permit conversions. Agreed protocol. Minimize changing names.


Patch - works only for that version. patch is complicated (needs to decompile and recompile). would you trust the 'patched' app? (keygen - runs this on someone else's computer :-)) 

Hardware/Platform
- Use x-platform tech - Using a VM approach (e.g. Java). Wep App rather than native app. Native app with limited functionality making use of web app for other functionality. Choosing multi-platfrom libraries. Using docker images. Having #ifdef (Platform). Abstraction.  Using emulators (such as Wine).

DAXPY  => y = a*x + y

Server gets a lot of load - load balancing required. Server is a single point of failure. Some the drawbacks of a webapp: requires being online. Ensuring consistency (true for all distributed apps). Does not fit all cases - e.g., games. Exact clien-server split depends on the nature of the app. E.g., games more client-side code for responsiveness, off-line playing. Security can be a concern. IP concern. Use of HTTPS: stops MiM but does not prohibit anyone from getting info from the server. 
Security important to proect the channel - authenitcation and authorization - intergrity and privacy. 
Use encryption to protect. Encrypt/hash data at rest as well. Data in transit to be protected with SSH/HTTPS/VPN/etc. Use timeouts. Use CAPTCHAs. Log/monitor transactions to monitor unusual activities (e.g. user logged in from two locations). Watch out for DoS. Use hardehned and up-to-date libraries. Code obfuscations. Using 3rd party logins as opposed in-house ones. GET vs POST. APIKey vs login/password. Employ lower level security (e.g. IPSec). Client and server could both on VPN. Having DMZs. Have own protocols. Have own encrytion (NOOOO). Using firewalls to keep harmful traffic out.

Access: Deny first and allow/grant later. Only grant access that is rrequired. Revoke access when no longer required.
User credentials based access (API key; username/passwd, 2 factor auth). HTTP Basic & Digest auth should be used over TLS. HTTPs end points can be attacked, and unencrypted traffic obtained. Beware of malware siphooning unencrypted traffic. Beware of bogus certificates on (compromised) devices.
Group based access.
Role based access.
Location based access
IP based access
MAC based access
(WPS)
 
Security - Ensuring privacy/confidentiality of users. Using checksum/hashes to ensure integrity. using digital signatures to ensure authenticity/integrity. Using software wartermarking to show ownership.


Testing. Functionality testing - do what it is supposed to; and do not do what is not supposed to do.
Pen-testing. 
Blackbox vs whitebox testing. We need both.
Code review.

Tomorrow: measure performance, profiling.

We have 90% of time taken by code block A, the rest 10% the remaining code.
Code A improved to take half that time. What is the speedup we now get?

Old time = 100
newtime = 90/2 + 10 = 55
Speedup = 100/55 = 1.8

I18N 
Always use Unicode
Left-to-right vs right-to-left
Verbose vs compact (german-like-words)
Avoid text and use visuals.

1 2 3 4 
5 6 7 8

Fortran
1 3 5
2 4 6


Performance - Profiling - CPU sampling vs. instrumentation. Find where the program spends most of its time. Optimize this first. See if we can find a better algorithm and better data structures to support the algorithm. 

Caching. Reuse of results and rsources. HTTP caching. Consistency. Cache invalidation protocols.


i =>> 1;


PATCH; 
if (something) doSomthin(). --> "if (something") => NOP
if (something) doSomthin(). --> "if (!something") doSomthin().
if (something) doSomthin(). --> "if (TRUE") doSomthin().

KEYGEN: Generate fake key pair as and use this to generate fake license.