Fundamentals

Software Lifetime

Before we start, we should understand that a practical software lifetime is always following these 6 stages of life:

• rapid prototyping
• reborn
• growth
• maturity
• retired / sunset
• scrapped

Rapid Prototyping

This stage is all about proof-of-concepts. You got a business idea/model and you want to prove something is working. This is the point where you hack and smash every available components to produce a prototype quickly without considering much. At this point in time, a lot of in-detailed development efforts can be skipped such as unit-testing, etc.

The objectives here are:

1. To prove an idea/model is working or otherwise
2. To gather first-hand data to support the idea/model
3. To test existing technologies' integration is working for the idea

Things to consider:

1. Construct the full pipelines out, including benchmark measurements, metric tracking, technologies listing etc, not just the prototype. Remember, the process is also important here.
2. Prepare to discard the entire prototype completely and rewrite from scratch.
3. Push the prototype to the following checkpoints:
   • proof the concept - whether it works/failed
   • investigate new pointers - use it to discover new pointers for developments and design direction
   • stress it out - stress the prototype to find its design limitation for defining design constraint in later stage.

Talent to Look Out For:

• Interested Maker / Prototype Enthusiast
• Interested Contributors

Exposure:

• Privately Internally - Yes
• Publicly - No

Reborn

This stage is to properly design the first version of the product based on the data gathered from prototyping stage. Based on experience and a lot of skunk works observations, it is best to discard the prototype at all and start from scratch. The reason being not to inherit any underlying hidden mistakes created during the rapid development of the prototype.

Depending on the complexity, system designer can start considering software design patterns OR proceed to create the new product.

The objectives here are:

1. To create the first working product
2. To establish the first working development and production process
3. To establish basic communications for all stakeholders
4. To acquire first-grade customers (dare to try)

Things to consider:

1. Concentrate on development, production, and continuous support processes FIRST. Then proceed to redesign the product into its first version.
2. Use placeholder to layout the software design structure if you must.
3. Design the product to have the critical features only, as in, minimal viable product.
4. Launch the product as it is to the market, start acquiring the first-grade customers (loyal, daring, and tech savvy folks).

Good indicator for release:

• Steve Jobs - if I personally won't use it, others wouldn't as well.

Talent to Look Out For:

• Architect
• Developers
• Support Units (legal, IP, etc.)

Exposure:

• Privately Internally - Yes
• Publicly - Yes

Growth

This stage is to grow the product based incrementally based on the defined development process in "Reborn" stage. Anything can change overtime as long as the user consumption pattern data are agreed accordingly. This is where all forms of continuous integrations, continuous development, release strategies are applied here. Software design is subjected to change accordingly as well.

The objectives here are:

1. To improve the product to the point of vision, and based on user consumption pattern metrics
2. To acquire second-grade customers (beta testers, etc.)

Talent to Look Out For:

• Marketers
• Developers
• Architect
• Support Units (legal, IP, etc.)

Exposure:

• Privately Internally - Yes
• Publicly - Yes

Maturity

The stage is the indicator where the product has grown close/achieved the design vision. It does not need further design complexity and is considered stable. The only developments in this stage are mostly environment fitting (e.g. OS integrations, security patches, etc).

The objectives here are:

1. To maintain the product as it is
2. To let the product fly on its own.

Talent to Look Out For:

• Marketers
• Developers
• Support Units (legal, IP, etc.)

Exposure:

• Privately Internally - Yes
• Publicly - Yes

Retired / Sunset

This stage is the indicator that the product is entering its support discontinuation/deprecation process. Usually, the product is substituted by a greater product. The only development efforts in this stage are mostly communications to all users to use the alternative solution before the deadline.

The objectives here are:

1. To inform all users about the death of the software
2. To help all users mitigate the risks of using an outdated software
3. To make sure the user base is back to 0.

Talent to Look Out For:

• Marketers
• Support Units (legal, IP, etc.)

Exposure:

• Privately Internally - Yes
• Publicly - Yes

Scrapped

This stage is about removing the software from its existence and its life supports. At this stage, the owner can either archive it or delete it to recover its resources for other usage.

The objectives here are:

1. To archive/salvage the product.

Talent to Look Out For:

• Support Units (legal, IP, etc.)

Exposure:

• Privately Internally - Yes
• Publicly - No

When to Consider Software Design Patterns

You can consider software design patterns as early as Rapid Prototyping stage. However, starting there might introduces a significant risk of resources wastage if the prototype turned out to be a failure.

Practical Practices

From experience, it is at best and practical to consider the design patterns in Reborn stage when the entire product is re-designed from scratch based on the prototype.

Business Cases

Almost all the software products since 2000 are using this product lifetime, like the way Fuchsia OS, Go programming language, Gmail, etc did in the past.

Also, it is very common to see a lot of software did not reach maturity or substituted. Just look at Google Graveyards (or its official site). Example of death products are:

• Google Chrome Apps (SCRAPPED - no user base)
• Google+ (SCRAPPED - failed to reach user targets for consumer level)
• Google URL Shortener (SUPERSEDED - replaced by Google Firebase Dynamic Link)
• Google Inbox (SUPERSEDED - feature prototype merged into Gmail)

Notice that all of their dead products were using this product lifetime stages.

What Triggers Consideration for Software Design Patterns

Normally, these are the pain points that triggers one to consider a software design patterns for needs:

• Writing algorithm, data structure from scratch ➔ reusable libraries / framework
• Functional input/output ➔ asynchronous reactive design / pipeline
• Sequential and logical computation ➔ parallel and distributed computation
• Full functional specification ➔ partial, composable, targeted model

Achieving The Software Quality

Normally, when you consider software design patterns, you consider to get the following values:

1. Sufficiency / Functional Correctness - satisfies all of the specifications
2. Robustness - crash when needed, recoverable
3. Flexibility - easily replaceable parts
4. Reusability - keep things DRY (don't repeat yourself)
5. Efficiency - achieve output within the time and resources limit
6. Scalability - usable in large and board demands
7. Security - penetration shielded and stable system

Software Design Pattern vs. Naive Development

The main differences between software design pattern vs naive development is:

1. think before coding vs. straight into code
2. consider quality attributes vs. get things working first
3. consider other design alternatives vs. brute force design later
4. make conscious design vs. go with the flow

Design Principles and Patterns

Hence, designing a good software pattern needs principles and patterns.

• Principles are the best practices
• Patterns are codify experiences like establish a solution for common problem; building blocks for vocabulary