Skip to content
This repository has been archived by the owner on Oct 10, 2024. It is now read-only.

reference: Add terminology #93

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Conversation

robredpath
Copy link
Member

@robredpath robredpath commented Jan 6, 2021

This adds the terminology from https://docs.google.com/document/d/19GNEwIi0IJtOAGIL18P91cEAcVySPOPZ2e-2ksvAo7I/edit#heading=h.r36n3aysaapv - which can be helpful when setting expectations for potential work, I think.

## Iterative Improvements

Larger pieces of work to make a step-change to a product, that may change the general approach to delivering the functionality of the software. For example - a redesign of an interface, a behind-the-scenes reworking of functionality to be faster or handle more data, the splitting up or combining of existing products to better serve users’ needs.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To me Iterative and Incremental are too similar, you can increment and iterate by the same amount of change. What about Minor and Major improvements?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that the two types of work here are conceptually quite different - it's not just a question of scale. I'm not precious about the words, but I think that the conceptual difference is important.

One type of change - what I've called an Iterative one - is a whole trip around the cycle of assessing needs, exploring options, developing and validating a solution, and putting it into use. Even if it has quite a tight scope (which is often a good thing!), it still requires us to apply some research and design thinking to the work.

Another type of change - what I've called Incremental - is a much lighter process, and is more applicable where there isn't any real doubt about how something should work. Often, that's changes that might not count as bugfixes (because they're not strictly wrong or broken) but that are of relatively little consequence and don't change our overall approach.

The scale of the changes may well overlap, but I don't think this is really about scale.

Does that conceptual separation make sense? Can you suggest a more helpful name for it?


It will:
* Be quick to make
* Serve a single purpose - for example to try out an interface idea, or to test an algorithm
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think your 'for example' here is probably the only purpose (try out an idea).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I specifically say an interface idea (eg the first version of the metadata presentation in 360 CoVE). I think that the algorithm point still stands - maybe we write a commandline tool that takes a spreadsheet and outputs some analysis, as the prototype of a future web app?

Or, would that not be a prototype, in your view?



It won't:
* Deal with any cases that it wasn't explicitly designed for
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No software can deal with a case that it wasn't explicitly designed for ;) I think I get what you're saying though, more like "won't cover all corner cases" or be very limited in use cases implemented, something along that line?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In practical terms, I'd be ok with a prototype crashing the web server when an invalid spreadsheet was uploaded, whereas some software at MVP level or above I'd expect to fail less catastrophically.

Perhaps this would be a good example to use throughout the docs:

  • prototype: it's ok if invalid input results in catastrophic failure
  • MVP: anything other than valid input should result in a simple error (eg "I don't know what to do with this")
  • Production: invalid input should have been thought about and analysis should be carried out to try to help the user

* Have sufficient documentation to help a user who has a good level of relevant skills to carry out their task

It won't:
* Have been designed to scale, be easily altered, or be optimized for performance outside of limited criteria
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure there is an obvious "It won't" for this because it is so product specific. Like you say in the intro it is implementing the minimal number of features that make a piece of software work for the largest single use case. e.g. an MVP for an image sharing website could be 3 features "Image site allows uploads + sharing links + backend storage scales dynamically"

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, although I think that the examples here are very common ones for us, and for lots of other applications. I feel like a lot of the tradeoff conversations we have are around scale (ie, is it worth dealing with parallelisation complexity just to see if this even works), performance (eg, does it matter if it takes an hour to run if it's a big file?) and alteration (eg, "can you just..." syndrome)

* Have been designed to scale, be easily altered, or be optimized for performance outside of limited criteria

An MVP is appropriate when we want to provide limited value quickly; such as in order to demonstrate the potential for future investment or to make a specific task easier.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think an MVP can be in production too

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, maybe we need to either see this as just adjectives rather than a scale, or have some other term for "production". Maybe "Mature"?

I'm conscious that we may well make code architecture changes between an MVP and something that we'd be happy to leave alone for a while / hand off to someone else.

Any particular piece of software might have elements that are at different stages of development. For example, a new feature in a mature software product might be a prototype, while the main software product is production-ready.

As a rule of thumb, it's approximately an order of magnitude of extra work, complexity or cost to move up each level; that is to say that a production implementation of a feature is 100x more complex than its prototype.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can bring that 100x more complex down if you have a 10x engineer though right ;)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

10x the engineers introduces 10x the complexity :p

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants