Off-The-Shelf Hacker: Outputs, Inputs and Process
Dennis, my old boss at Intermedia, was a down-to-earth guy. He knew how to organize projects and subtly play the politics to get things done. I was his business analyst and helped him manage our departmental requirements and the interaction between our clients and developers.
He called his development methodology OIP. Outputs, Inputs and Process. He coined the term himself.
OIP is deceptively simple: Establish what outputs you want, figure out what inputs you’ll use, then build the process to satisfy both, in that order. The techniques can be applied in any number of areas from simple utilities, to new features, to a horrendously complex multiuser, networked application with databases. Yes, it scales well.
Dennis applied OIP to software development projects. I think it is well suited for blank-sheet, one-off physical computing prototype work. It forces you to focus on results rather than playing with some shiny new hardware or elegantly crafted algorithm. Those things frequently sidetrack geeks, simply because they capture our interests. It can dramatically slow down getting things out the door or in front of an audience.
Let’s explore OIP methodology with a new off-the-shelf hacker project that I’ll call “Watering the Yard,” using an 8-channel relay board, a week ago.
We’ll begin by discussing outputs and inputs. Next week, we’ll dig into the process section. Later, we’ll use what we find to move forward into project details, the build and evaluating results.
What Are the Outputs?
I want a healthy and nice looking yard. Since plants need adequate moisture and rain is as unreliable as my memory, it makes sense to automate the job of watering.
Just as OIP is simple in concept, so are the two sentences above. Uncovering details isn’t easy. Think of outputs as outcomes, results and goals. Here are a few questions that help define the outputs.
- What areas of the yard should be watered?
- How much should I water?
- On what days should I water?
- What days should I NOT water, perhaps because of county restrictions?
- What is my watering, cost and time budget for all this effort?
- Should we be able to water without electrical power or water pressure?
- Do we need to track the watering?
- Who is authorized to water?
- What happens when it rains?
There might be other seemingly intangible outputs. Sometimes these look like inputs and the overlap might be a bit fuzzy.
- Are learning new skills part of figuring out how to get the lawn watered?
- Do I have or can I get the parts I’ll need to water my yard?
- What other activities or influences can make or break my watering efforts.
Finally, there could be frequently ignored or blatantly obvious outputs.
- Do I even need a watering solution for my yard right now?
- Can I get my lawn watered by simply giving money to some sprinkler installation company?
- Could I get the lawn watered by ordering/paying one of the kids to do the job?
I put these three at the end for dramatic effect. Be advised, asking such results-oriented questions has risks, particularly in bureaucracies. It might be just as perilous not to ask. Somebody should probably do it.
Let’s establish our outputs for watering the yard, as specifically as we can, given our current knowledge.
- I want to plant a few cool weather vegetables this year so will need regular watering in my garden area.
- We just put in a planter near the front of our house, so that area will need to be on a regular watering schedule.
- The east side of the house has great sun in the morning and I’d like to continuously grow flowers there for use in the rest of the landscaping. Buying potted plants is expensive. It will be a pipeline of plantings for around the yard. Watering in this area should be in the early morning just long enough to keep the beds uniformly moist and may change as the plants mature.
- I’d like to use various physical computing devices, sensors and actuators as the basis for articles and talks. This includes existing devices in my parts inventory and new devices that I order off-the-shelf. Whatever I implement has to be flexible and easy to mod.
- Use existing wiring and piping where possible.
- Use off-the-shelf parts, with minimal fabrication.
What Are the Inputs?
Since I build prototype projects then write and speak about them, I should try to limit the inputs to a level that will let me get the first version up and running in a few weeks. So, here are my inputs for this go around.
- I’d like to use a simple list of on/off times.
- The list should be easily modded.
- I should be able to selectively turn on the water to an area remotely and have it automatically turn off after some default amount of time. Think turn on and forget.
- The system should be expandable so that other physical computing systems, on my internal network can control the flow of water.
- A web, Android or application program interface (API), might be a feature for the future. Expandability actually becomes an input, although it might be hard to define.
Experience along with familiarity with your tools and parts guides how you frame your inputs. Keep in mind that with my particular brand of fast-moving, learn-as-you-go, prototype projects I can tolerate flexibility in my method in comparison to a corporate software dev situation. OIP can be as strict or lose as you need, is easy to remember and will keep you focused.
Keep It Simple
OIP works for me and I hope readers find the discussion useful. Come back next week and we’ll look at the yard watering process. I’ll leave you with this thought.
OIP methodology dovetails nicely with integrating hardware and software into real-world actions while creating a coherent effort to satisfy the customer needs. It has a proven track record for success and streamlines the interfaces between often conflicting ideologies while mitigating uncertainty between organizations and business interests.
Yes, that was bad. I worked in large companies for a long time. What can I say? Off-the-shelf hackers appreciate making a point with a little irony.
Feature image via Pixabay.
