Lecture 03 Iterative Design

Obj As a SWE when delivering product

• Deliver Value

• prod dev is twofold challenge

  • develop the right product and the product right

• Focus on

  • What the product is doing

    • Features offered to end-users

    • are these the right ones

  • How is the product being developed

    • is it safe enough to be used

    • will it support evolution/maintenance

What happens when you fail to address both aspect

• Focusing on business value only

  • subpar performance

  • maintainability issues

  • no evolution

• Focusing on technical value

  • great code, poor product

  • product does not meet expectations/requirements

Focusing on both business and technical value

• can be had to keep up with tech value, when facing short deadlines

How Is Value Characterized

• Just explain this graphic

• Things that are visible, that are negative and positive

• things that are invisible that are negative and positive

  • what are they

Different approach’s to delivering value

• Continuous Delivery approach

  • As time passes constantly delivering something of value

• Release Approach

  • Spending a bit more time on each increment, but still delivering value

• YOLO

  • not releasing anything until the very end, LOL

Risk management in relation to deliverable

• the risk is the area between the cost and value line, when graphed against time

• The more value delivered early one, the less the risk

What is Technical Debt, what increases technical debt

• implied cost of future reworking, caused by suboptimal design

• Increasers are

  • subpar design decisions, code smells

  • simplifications, doing things that are quick-n-dirty

  • Untested code

  • Prioritizing expedience over long-term design

Repercussions of technical debt

• Analogous with monetary debt

  • if not “repaid” can accumulate interest

  • charges are harder to implement

• when unaddressed

  • increases software entropy (degree of disorder)

  • increases cost of further rework

    • defect fixes and new feautres

Unit of technical debt

• measured by time

• days are normal

• years are not

• can depend on factors (LOC, % of legacy code, business case)

Some instances where it is inevitable to accumulate technical debt

• Proof of concepts

• MVP
  beating competition to market

• move project forward, in general

Criticism of Technical debt metaphor

• the debt metaphor downplays ramifications of poor code

• results in insufficient prioritization of needed corrective work

Boy Scout Rule

• Leave the campground cleaner than it was when you arrived

• (Refactoring)

Broken Window Principle

• If you don’t care for your code no one will

• keep it readable, easy to maintain

• identify what debt is and have a plan to fix it

Explain the Iterative and Incremental Graphic

Why Iterations good

• allow for gradually gaining more understanding of the context and requirement

• minimal increments help mitigate risks

• Technical debt can be addressed early on

MVP, what is it

• An MVP is

  • [Minimal] The bare minimum to

  • [Viable] validate the viability of the

  • [Product] engineering artifact in support of the business proposition

• Contents of an MVP

  • essential features for the user

Goal of the MVP

• demonstrate MVP to end-user and stakeholder

• get feedback

• rinse and repeat

What are the key enablers of iterative and incremental design

• Maintainability

  • the ability to add new features and refactor code while keeping the functionality intact

  • knowing how to asses/measure maintainability is key

• Proper Test Coverage

  • Gives you confidence that you won’t break things

  • knowing testing techniques adn tools is key (3S03)

• Mastering Version Control

  • Manually maintain version is stupid

  • Knowing git is key