In previous posts I’ve talked about the importance of planning and how to determine which features are essential vs. nice to have. Using my project Hoshi as an example, I’ll now go into how we go from a very high level overview into something we can implement.

Remember that in the previous installment I generated the following MUST and SHOULD list for my sensors:

We MUST have sensors that can detect events in the physical world. The sensors MUST also relay those events to the central system for processing.

The sensors SHOULD be small and inexpensive. The sensors SHOULD be able to be battery powered or use wall power. Users SHOULD be able to have an arbitrarily large number of sensors.

The way the sensors communicate back to the central server SHOULD be robust, easily extensible, and, to be convenient, not require extra hardware to increase range.

Looking at each line, there are some obvious questions that we need to answer. We MUST have sensors that can detect events in the physical world – so what events do we want to detect? In this case, I want to detect motion. I also probably want to detect light levels since I’m building this to control, among other things, lights, and maybe I want to not turn on my lights if it’s broad daylight and I’m getting plenty of sun in a room. So now, my “we MUST have sensors that can detect events in the physical world” becomes:

We MUST have sensors capable of detecting motion and capturing the ambient light level in their environment.”

The next MUST – the sensors MUST also relay those events to the central system for processing – gets me wondering HOW the sensors will relay those events. I could just have the sensors wired directly to the central server, but that seems really limiting – I’d have to run cables all over. So, a wireless connection it is.

This leads us down a further avenue for inquiry – what KIND of wireless connection? And what does having a wireless connection imply for the construction of the sensor – what kind of hardware will I need to support that wireless connection?

For the kind of wireless, I’m going to look at my SHOULDs. I want the sensors to be small and inexpensive, I want them to be able to be battery powered, I want to be able to have an arbitrarily large number of them, and I want my network of sensors to be robust and easy to add nodes to.

So breaking it down into details: I need something that is capable of handling logic for networking as well as reporting back a payload of sensor events over that network – this is clearly a job for a microcontroller such as the Arduino. Looking at my SHOULDs – I need small and cheap, and that means an Arduino Nano, which at ~$3-6 and about 1″x2″ or less, is both small and cheap.  Even better, the Nano is readily available in bulk – if I decide I really want to scale up, I won’t need to source rare or difficult to get hardware. For example, if I wanted to use a Raspberry Pi zero – which is much more capable than a Nano and only $5 – I would have a hard time getting my hands on enough of them.

I will need to connect the motion and light level sensors to the Nano, so I’ll create a module for that which can be added to the Nano. This would require a few inexpensive components – a motion detector (about $1), light sensitive resistors/a light sensor (pennies on up to $1-2 for something fancy), and a small proto board (pennies) to put it all on. That qualifies as cheap!

I will need to add wireless networking to the system. I could do wifi – there are $2 chips for that and they can run pretty well on a battery for a fair amount of time. I could look at Bluetooth low power modules, though those run $5-10, which isn’t very cheap. I could use a RF transceiver, which I can get for under a dollar, but which might also have range issues – in order to get those and also solve the range issue, a little research shows they would cost $5-10 per part. So, I will probably go for the wifi chips.

I will need to make sure that range isn’t a problem and that the network is easy to extend – I want to be able to put my nodes wherever I like and they should be reliably able to communicate back to the central system. To me, this says I need to look at a mesh network, where each node in the network helps extend the network range farther. It also makes me think I might want to consider whether or not making some nodes in the network just function as extensions – I could have two models of nodes, one with sensors and one without…

Breaking THAT down, I realize that the sensor module isn’t very expensive, and maintaining two different types of nodes would be a pain, so I’ll just have one type of node. Ultimately, this gives me:

Sensor nodes will use standard parts that are readily available in bulk, and will all share the same design – all nodes will be functionally identical. The nodes will be based on an Arduino Nano. The sensor module will include motion and light level detection. The node will run on battery and use a wifi chip and will be configured to use the least amount of power possible. The node will be configured to work as part of a mesh network, which will allow the network to be extended as new nodes are added.

By breaking things down into the detail that I did, it prompts me to ask questions I might not have thought about when I was only looking at the high level overview. There are still some questions that were raised that I’ve left unanswered – lots of questions about the mesh networking, specific parts I’d want to use, requirements on range for the sensors (detecting motion within 2 meters vs 10 meters, for example).

My feeling is that, for a personal project, I now have an idea of what parts I want to use and can start doing a bit of research & basic implementation to get them working. For V1 of my project, this level of detail is sufficient – it’s a starting point that can be refined through trial and error into something that works. I’m now ready to get it done!

In business, there’s the idea of a “minimum viable product” or MVP. The MVP is the least expensive (in time, money, and risk) version of a product or feature that you can put in front of potential users to test whether or not there’s a market for whatever it is you want to do. MVPs should be simple, but get the job (gauging interest) done – I know of a startup that literally just went to potential clients with static images and a way to explain their potential product, and it was enough to get early investment so they could actually make the product. MVPs tend to focus on the “golden path” as in, the features and use cases that 90% of the potential market will want to use, rather than niche cases. An MVP should be the bare essentials needed to get started. Extra features – nice to haves – can be put in a backlog of things to get at once you have your first version out the door and it gets traction. Why spend time on things that aren’t essential when you don’t even know if there’s any interest in them?

For personal projects, I’m not very worried about what people will want, as usually I’m just intrigued by an idea or technology and want to play with it. Even so, I want to create something similar to an MVP, getting my project working end-to-end with the bare minimum of extras, and THEN I start adding those nice-to-have features that are such tempting distractions. I do try to get my idea as well specced out as I can so that I don’t suddenly find something that I overlooked that leads to distraction and derails the whole thing.

For an MVP, I think in terms of MUST and SHOULD. MUST items are absolutely essential features, without which nothing works, while SHOULD items are ones that I think can wait until later. While I usually don’t implement SHOULDs right away unless they are absolutely trivial, the important part of thinking about those SHOULDs is that they can influence the way the MUSTs are carried out. I just describe things in terms of what a thing MUST do to be functional, and SHOULD do to be delightful to use or viable as a potential product.

Continuing to use Hoshi, a home automation project that will make my smart home proactive vs. reactive, as our exemplar here, I will provide an example of MUST and SHOULD descriptions.

We MUST have a centralized system that is fluent in multiple external APIs when it receives notifications of events. That system MUST have some kind of rules regarding what to do when a given event happens. To do that, we MUST have sensors that can detect events in the physical world. The sensors MUST also relay those events to the central system for processing.

The centralized system SHOULD be easy to administer. Rules SHOULD be easy for a user to create. It SHOULD be very easy to add both new types of sensors to the system. It SHOULD be very easy to add new APIs to the system.

The sensors SHOULD be small and inexpensive. The sensors SHOULD be able to be battery powered or use wall power. Users SHOULD be able to have an arbitrarily large number of sensors.

The way the sensors communicate back to the central server SHOULD be robust, easily extensible, and, to be convenient, not require extra hardware to increase range.

From all of the above, for this example, I will be digging into the MUSTs and SHOULDs around the sensors rather than everything else. In this case, the SHOULDs about the sensors will strongly influence my initial choices in the MUST section. Because the sensors SHOULD be small and inexpensive, I’m going to look at implementations that don’t rely on stupidly expensive hardware.

If I didn’t pay attention to my SHOULDs, I might say hey, I’ll buy a bunch of pre-made sensors off the shelf which would certainly do for the MUST part. However, they tend to run $30+ which isn’t inexpensive enough for my tastes. The ones that do have a lot of range tend to be more expensive and also don’t last long on battery power. So if I only considered my MUSTs and not my SHOULDs, I’d wind up with a bunch of expensive hardware that doesn’t fit in with my longer-term plans. I’ll need to look at rolling my own sensors, which in addition to being less expensive and more likely to meet my exact needs, will also be a lot of fun.

One thing to note is that I’m not going into the technical details, but in the next step I’ll show how we go from MUST and SHOULD to a functional plan.

We’ve all been there – you have an amazing idea for an ambitious personal/hobby project that will leverage a ton of interesting technologies and so something incredible. You start working on one aspect, then realize there’s something else that needs doing first so you switch to that, then another issue comes up and you realize you need to do THAT, and then you just find yourself thrashing and context switching so much you don’t get anything done to the point where you just bail on the whole thing.

At least, I’ve been there. I won’t go so far as to say I have ADD, but I do tend to get easily distracted by flights of fancy and the like when I’m working on stuff that isn’t, you know, work. Like, even as I was typing that sentence, I was thinking about 8 different things, one of them being “should I make the obvious joke where I interrupt myself and say ‘squirrel!'” and you can see, I’m digressing. In any case, for me, having a GOOD plan when I start working on a personal project is absolutely essential to getting things done.

If you haven’t had that problem, then this post is not for you – if you’re one of the rare people who is naturally very disciplined and focused, I’m jealous, but you can skip on past. For everyone else, here’s a technique that has helped me.

Here I’m presenting the methodology I use when working on a personal project that helps keep me from being distracted. I will use Hoshi, the home automation project I wrote about previously, as my example, since I’ll be doing these steps anyway while I work on it.

The steps of my process are pretty straight-forward:

0. Come up with an idea for a project
1. Figure out what my product MUST do and what my project SHOULD do
2. Break a high-level description of the project into very small, detailed, pieces
3. Turn those details into specifications
4. Implement the specifications
5. Put everything together

It’s not rocket science – people will look at the steps I’ve outlined and say “well, DUH” – but the point here is to provide a lightweight conceptual framework that lets you Get Stuff Done, and honestly most of that is just common sense.