reference: Add terminology #93
Conversation
| ## 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. | ||
|
|
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
I think your 'for example' here is probably the only purpose (try out an idea).
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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"
There was a problem hiding this comment.
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. | ||
|
|
There was a problem hiding this comment.
I think an MVP can be in production too
There was a problem hiding this comment.
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. | ||
|
|
There was a problem hiding this comment.
You can bring that 100x more complex down if you have a 10x engineer though right ;)
There was a problem hiding this comment.
10x the engineers introduces 10x the complexity :p
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.