3 ms·
What worked for us was to do two versions of the program at the same time. Version one had simple functionality. Version two had all the bells and whistles dr
by mrlyc 12y ago
What worked for us was to do two versions of the program at the same time.
Version one had simple functionality. Version two had all the bells and whistles dreamt up by the programmers and the customer while we were working on version one. Those were added to a todo list for version two. They were not implemented in version one.
That kept up the flow of ideas but didn't disrupt the project. It made the programmers feel appreciated while giving us an outline for the next version so our competitors couldn't keep up.
What surprised me was that the whole team got into the spirit of the thing. When someone came to me with an idea, cries of "Version two! Version two!" echoed around the programming room.
- gsands 12y agoI love this. For a couple of reasons. 1/I often discover new things and have new thoughts and ideas along the way of an implementation which hadn't presented themselves previously. 2/I think it's a great way to avoid overthinking a feature or arguing too much for or against it. If nearing a majority consensus (with oneself or team) and there is time to spare, add it to Version 2 -- advantages being point #1 above, and having it prepared should it be deemed worthy to be merged to Version 1. I've heard that having features in the chamber ready to release is something big corps commonly do.
- Kiro 12y agoWe were doing something similar but the result was a mess. Sometimes version 1 needed something that depended on unreleased stuff in version 2. It lead to fragmentation where we developed two implementations of the same functionality.