3 ms·

How do you make prototypes top-quality? Unless you know what you want, isn't it hard to make the best shape for that thing?

ChrisMarshallNY 4y ago
I have to be willing to throw away a lot of code, and use implementation techniques that afford flexibility. I've been working on a fairly large-scale iOS app, for the last couple of years. It's about 40 screens (Most of my apps are 2-5 screens). It also has a fairly substantial backend (that I also wrote). One of the reasons that it has taken that long, is because I have thrown away -literally- months' worth of work. I spend a lot of time on each screen, leaving placeholders, or disabled selectors, for unimplemented ones. Each screen is done as "ship" Quality. People aren't testing a prototype; they are testing the actual ship code. I call this "constant beta." The app is always at ship Quality. Localization, accessibility, and "white glove" testing are being done, right from the start. This means that integration testing (the most important type of testing, in my opinion) starts almost immediately. Since this is iOS, I can use Apple's TestFlight beta-testing system, to distribute the builds to the non-technical stakeholders. I generally do a couple of releases a day. I have done over 600 releases, so far. Bugs get found quickly. It's important to find bugs as close to the point they were created, as possible. Since this is integration testing, whole subsystems get tested; not just individual modules. Also, the testers are much closer to the actual target audience, than you would get with professional QA teams. I tend to prefer the use of test harnesses, as opposed to unit tests, for this reason[0]. A lot of times (it has happened numerous times, in this project) we "get what we want," and realize that it isn't actually what we want, or it's unusable/impossible. A lot of times, you can't get to that point, unless you have built the app pretty completely. The absolute worst thing that can happen, is that you get exactly what you asked for. That's one of the problems with using outsourced shops and loosely-coupled distributed development. These techniques require heavy-duty specification, and those specifications often end up as rock-hard cement. No one wants to change them; even when it becomes clear that the result will be less-than-satisfactory. I've been through that, a number of times. But the crap-quality MVP isn't (in my opinion) an acceptable solution, either. Every now and then, one gets a home run, but, more frequently, we end up with foul balls. The brand gets damaged, the engineers quit in disgust, the money gets used up, and it becomes difficult to pivot. One thing that I often do, is spin off code that I'm not gonna use, into subprojects, for reuse in other projects. Here are a couple of examples: https://github.com/RiftValleySoftware/RVS_Spinner https://github.com/RiftValleySoftware/RVS_Spinner https://github.com/RiftValleySoftware/RVS_CalendarInput https://github.com/RiftValleySoftware/RVS_CalendarInput I'm not using these in the project (they were written for the project, but we decided they weren't appropriate), but they are available for other projects. [0] https://littlegreenviper.com/various/testing-harness-vs-unit/ https://littlegreenviper.com/various/testing-harness-vs-unit...

ChrisMarshallNY 4y ago

I have to be willing to throw away a lot of code, and use implementation techniques that afford flexibility. I've been working on a fairly large-scale iOS app, for the last couple of years. It's about 40 screens (Most of my apps are 2-5 screens). It also has a fairly substantial backend (that I also wrote). One of the reasons that it has taken that long, is because I have thrown away -literally- months' worth of work. I spend a lot of time on each screen, leaving placeholders, or disabled selectors, for unimplemented ones. Each screen is done as "ship" Quality. People aren't testing a prototype; they are testing the actual ship code. I call this "constant beta." The app is always at ship Quality. Localization, accessibility, and "white glove" testing are being done, right from the start. This means that integration testing (the most important type of testing, in my opinion) starts almost immediately. Since this is iOS, I can use Apple's TestFlight beta-testing system, to distribute the builds to the non-technical stakeholders. I generally do a couple of releases a day. I have done over 600 releases, so far. Bugs get found quickly. It's important to find bugs as close to the point they were created, as possible. Since this is integration testing, whole subsystems get tested; not just individual modules. Also, the testers are much closer to the actual target audience, than you would get with professional QA teams. I tend to prefer the use of test harnesses, as opposed to unit tests, for this reason[0]. A lot of times (it has happened numerous times, in this project) we "get what we want," and realize that it isn't actually what we want, or it's unusable/impossible. A lot of times, you can't get to that point, unless you have built the app pretty completely. The absolute worst thing that can happen, is that you get exactly what you asked for. That's one of the problems with using outsourced shops and loosely-coupled distributed development. These techniques require heavy-duty specification, and those specifications often end up as rock-hard cement. No one wants to change them; even when it becomes clear that the result will be less-than-satisfactory. I've been through that, a number of times. But the crap-quality MVP isn't (in my opinion) an acceptable solution, either. Every now and then, one gets a home run, but, more frequently, we end up with foul balls. The brand gets damaged, the engineers quit in disgust, the money gets used up, and it becomes difficult to pivot. One thing that I often do, is spin off code that I'm not gonna use, into subprojects, for reuse in other projects. Here are a couple of examples: https://github.com/RiftValleySoftware/RVS_Spinner https://github.com/RiftValleySoftware/RVS_Spinner https://github.com/RiftValleySoftware/RVS_CalendarInput https://github.com/RiftValleySoftware/RVS_CalendarInput I'm not using these in the project (they were written for the project, but we decided they weren't appropriate), but they are available for other projects. [0] https://littlegreenviper.com/various/testing-harness-vs-unit/ https://littlegreenviper.com/various/testing-harness-vs-unit...