The 400m sprint is a tough race, you essentially sprint for 400m (duh!). That means for a quarter of a mile you are essentially running flat out and this is what we are doing now.
The launch of the camera is about 1 month away and it’s just a flat out sprint. I stupidly thought that once we went to production it would just be about fine tuning and improving the hardware. Ha. How wrong I was. As you may have read we have, a quality control team, two sets of independent testers, , plus Emma to test the cameras. We also have 8 beta testers, 4 resellers, 1 app company, a firmware team, a hardware team, an IT team, and me. In total if you count everyone who has worked/working on this project you are looking at close to 45 people. All of these people will need to be coordinated down to the minute to ensure a very smooth start to the camera launch and something we are having to figure out. This unfortunately takes a lot of time and a lot of preparation, probably more or equal to about 10-12 hours a day. Let me walk you through every aspect. It may jump around a bit but it will all make sense at the end.
1. Quality Control/Assurance/Testing
Our biggest concern for this camera is that the quality is top-notch. You probably already know our quality control processes that we will have in place but I’ll run through them again:
– Factory testing
– Independent testing 1
– Independent testing 2
That’s five levels of testing before you get the product. However, liasing all of this is not easy. Resellers testing is easy (when they receive, they test), but liasing with the factory, independent testers 1 & 2 and Emma has not been easy. We need to book the testers in, but the completion date may alter. So we now have to book a ‘range’ in. However, to keep this independent I do not want to do the testing in the factory, so we need to find a day or twos storage where the testing can be done. We then need to liaise between the 1st and 2nd testers on coming in, and what they will be testing and how. Emma will be there to monitor and observe. We then also have to keep talking to the factory so any faulty ones can be sent back and fixed or replaced. This has so far taken about 2 weeks and we’re just starting to make headway. We have to in essence do the following:
- Originally test the JooVuu X in the factory
- Move the cameras that pass to a nearby storage facility
- Indpendent testers 1 come in and tester
- Report is written up and sent to us. A report for Emma to look at is also written and she decides what to share and what not to with testers 2 to make the testing as thorough as possible.
- Faulty cameras sent back to the factory
- Testers 2 come in and test
- Faulty cameras sent back
- Camera’s sent for shipping
- Emma goes with the cameras and tests them at the shipping offices
- Faulty ones sent back
- Rest of the cameras sent out
- Faulty cameras are replaced/repaired
- Cameras are tested by independent testers 1 & 2 again
- Cameras ship out (if they all pass, if not repeat previous steps)
- Emma tests them one last time.
- Cameras ship.
All this has to be perfect as we have deadlines so everything must operate to a tee.
2. Hardware team
The hardware of the JooVuu X is not like most cameras, it uses high quality components and utilizes everything to make the camera operate as efficiently as possible. Therefore, the hardware team are still making PCB efficiency modifications, power consumption and distribution alterations, node movements, all to make the camera as reliable as possible. Great you think, that’s easy? Wrong. Every change I insist on receiving and approving. Now as you astute people may be aware, I have no background in electronics but luckily I have friends who have PhDs in electronic engineering. Every change is looked at, considered, revised, and sent back. This means this team is currently the quality controls team best friend, because they will update the QC team on timeline, what to look for, what should behave in certain ways, what margins of error there are etc. It also means, every change has a monetary impact, one which I am absorbing through JooVuu currently.
3. The firmware team
This is the nucleus of the JooVuu X. The hardware can be fantastic, the QC can be incredible, but if the firmware is not working properly and optimizing what we have to the best it can be – it’s pointless. This has been the most time consuming part and closely links with the beta team. With 8 testers, plus Emma & me, we have 10 testers, testing the JooVuu X incredibly thoroughly. We got the first RC firmware on 25th September, and we have discovered about 50 bugs and problems, and identified about 15 areas for improvements and changes. We’ve sent these off to the firmware team. Sounds pretty easy? Sadly no for a few reasons.
a. To allow the development of the firmware, we have to give them enough time to focus on the current problems and as such, we stop ‘passing’ over the problems and collate a new list. However, it’s not as straight forward as that, as the firmware team have to focus on each problem we have to make sure the problems we collate after we have ‘handed’ over the list, are also known to the developers. This is what we call a ‘soft’ handover where we tell them and describe the problem but they do not replicate it. This means on the original QC of the firmware they will look for it.
b. We have to replicate every problem. I one time spent 2 days replicating a problem (thank you very much Chorlt), however, I have to. This is so I know it is a problem and two show the firmware team how to replicate it so their work is quicker and more efficient. However, this takes a huge amount of time.
c. What the firmware does, affects, the testing and the hardware. If we want to implement a function, we have to look at power consumption, heat, and a variety of other factors. We will be working past the release date on the firmware, as we’ll never stop. We already have a roadmap of features we want to implement so we have one eye on the future and the other eye on the present. We have to build for today whilst building for tomorrow.
The hardware and firmware team are like conjoined twins, they are both the same but at the same time completely different. The hardware and firmware team must move in sync and unison but at the same time, must focus on their tasks to finish the task to the highest ability.
4. The Beta Testers
Each tester uses the camera as they see fit, and as such each tester has found different problems. This has meant we have found more bugs, and implemented more improvements than I had ever imagined. However, we have to know when to stop passing on the problems and get them to focus on other issues. At the moment these guys are doing such a good job they’re virtually no work and make our life 100 times easier!
5. The App Team
Emma & I have a new game we play: Firmware or App. Which one is the problem. We have debug information and what not but sometimes no amount of information will help you. Take for instance a bug we have discovered: when you connect to the camera with the app it should read the data on the camera, then when you make any changes it updates the camera. This means if you go to another tablet/phone etc the app will have the same settings as it just reads the settings from the camera. However, we had a problem where all the settings would be blank. So we had to play the fun game of, is the camera not allowing the app to read the settings, or is the app just not reading the settings. This took about 2 days to find out. However, we then have to replicate this, and send over to the app team. The app team will also need to liaise with the firmware team to check camera and app interactions, whilst the firmware team will liaise with the app team as they will need other aspects implemented through the app so they can test on the firmware to make sure everything is okay.
6. The Resellers
At the moment, they’re just fielding questions and informing me of pre-orders (we’re getting decent demand so far). But closer to the time, we’ll have to completely brief them on the camera, every function, every problem that can occur, how to solve, troubleshoot. Obviously they will learn about some problems themselves, but we want to give them a great head-start, but we cannot do this until firmware and hardware have ‘gone to production’.
7. The IT People.
At the moment, they are just overhauling the back-end to make sure we can expand horizontally if demand surges, however, we’re asking them to do other things as well which will all need to be done before launch day.
As you can see, there’s a lot going on, with most of our resources focused on firmware, hardware, and the app. However, as priorities change, and situations alter, so will our resources, but at the moment it’s all systems go…we’re about 150m round the track…not far to go now.