Creating a Financial Foundation for Shared Infrastructure

Over a decade ago, I was one of the founding members of the Dallas Makerspace. My major contribution was designing the financial models that allowed the group to have a solid financial footing for renting it’s first dedicated space.

an antique drawing of three candelabras
Giovanni Battista Montano. Three Candelabra, 1534–1621. The Art Institute of Chicago.

The other founders were more involved in all the growing pains of starting an organization like that, and I moved to another city and didn’t lift those boulders. But (as far as I know) the original membership models kept the group bootstrapped long enough to attract more members and grow into the organization they are today.

A member of the ThePrepared Slack recently asked how I did this, and in retelling the tale, I realized that I’d never written down the methods I used. I think sharing them here might be helpful to other people looking to start either their own hackerspace, makerspace, or other opt-in, volunteer-driven group that seeks to have a single costly piece of shared infrastructure.

The Problem, Or What Not To Do

First let me lay out the problem. A volunteer organization starts with zero money. It can ask for donations and have some non-zero value of money, and then they can spend that money on projects. This model works fine if the projects are less frequent than how often you can ask people for money. If the organization wants to rent a space, they will now have a monthly operating cost that extends into infinity. There is no time when you’ll have raised enough money to pay for all the rent forever. You can only raise enough money for some number of months. You can think of each months rent as a “monthly project” you need to raise money for. If you organization has a regular meeting once a week, that means you will be either about to ask for money, asking for money, or telling people how much money you raised three out of the four weeks of the month. A primary task of the volunteers who have donated their time to keep the organization running will be to figure out how to collect enough money each month.

Suffice to say, unless your organization is a group of people who love to ask other folks for money, this will not be an activity that is long term sustainable by volunteers. They did not join the ranks of your group to run around asking folks for money.

Continue reading

Comparing Engineering and Design

In an earlier post I wrote about the similarities between engineering and design. After discussing the concepts with a few engineers and designers, I thought it would be helpful to explore the differences between the two disciplines.

a crushed empty soda bottle on the ground
Photo by Roberto Sorin on Unsplash

Known solution versus unknown solution

In the introductory chapter of Designing Your Life, the authors point out the most salient different between engineering and design problems.

… [E]ngineering is a good approach to solving a problem when you can get a great deal of data and you’re sure there is one best solution.

Designing Your Life (Evans and Burnett, 2016)

They position design problems as not having a known single best solution.

[Creating the first laptop with a built-in mouse] was a design problem. There was no precedent to design toward, there was no fixed or predetermined outcome; there were plenty of ideas … but nothing was working.

Designing Your Life (Evans and Burnett, 2016)

In other words, engineering explores a problem space with a clear well-defined solution, while design explores a problem space without a well-defined solution.

Solvability

A professor introduced me to the idea of asking whether a problem is “solvable by design” or not. This is a question a designer should ask when identifying a problem to solve. I found it incredibly helpful to break out of an engineering mindset. I was in the early stages of a project, exploring a problem space and being a bit overwhelmed at all the different facets of a large and complicated situation. My process was to try and create a framework for understanding the entire problem space, and then using that framework to come up with “the solution”. The framework was helpful – it provided a way to organize my group’s thoughts and gave us a common language to talk about the different facets of the problem space. But it did not point to a “solution” – instead it made clear that the tree of problems we were looking at had a root problem that was simply not solvable by design. The best we could do is mitigate some of the effects of the problem and provide a tool designed to help the people affected cope.

I’m not sure that engineering has such concept as “not solvable by engineering”. Certainly there are problems that aren’t, but I don’t recall that being part of any engineering course or discussion I ever participated in. It is perhaps a blind spot in the way engineering is practiced. Or perhaps such problems are dismissed as “not solvable by engineering yet“.

Continue reading

Building a small team

When starting a new venture, your team is often small due to timing, budget, or uncertainty. Growing a team from a small starting point takes careful thought about both the current needs and the future. When only a handful of people are on the team, each hire has a dramatic increase in the communication costs and cognitive load of relationships. There is a combinatorial jump as N goes from 2 through 6 that is unavoidable.

Photo by Wolfgang Hasselmann on Unsplash

On a small team, each member has to cover a wider spectrum of topics, even if the depth of understanding or time commitment of each topic is small. Someone needs to do all the little administrative tasks but they do not all sum to an amount of work that represents a full position. And that is often the case for many other topics. You do not need specialists yet.

But the software and technology industry is geared towards specialists. The cynic would say it is because it is easier to put people into a box with a label and disregard the other skills someone has. I think it is simply the nature of a tech industry culture dominated by huge players that are assembling large teams that are looking for very specific specialized roles. Those companies’ influence sets the tone of the discussion. When someone might get a job at a 10,000 person company or a 100 person company, which framing are they going to gravitate towards for themselves? It seems the gravitational pull of the big players wins out.

So building a small team is difficult. It is intrinsically difficult to do, and the hiring marketplace is slanted against giving you the information you need.

My advice, and the techniques I use follow.

Continue reading

The Overlap of Engineering and UX Design

While simultaneously working in software engineering and completing my masters degree in HCDE, I started to notice a few overlaps in both the practice and conceptualization of engineering and design.

Both involve solving the problem of what to build. Both rely on a set of heuristics built by experience in the individual practitioners. Both are concerned with trade-offs.

two giraffes facing away from each other
Photo by Vincent van Zalinge on Unsplash

What to build

Solving the problem of what to build in either discipline is about understanding the gap the solution needs to fill.

In engineering, this is usually framed as requirements gathering. They are typically structural requirements of the embodiment (how many cycles in how much time, how much work done with how much resources), restrictions of performance envelope (an upper limit of acceleration, a lower limit in total capacity), or functional conditions (some response must occur whenever an event occurs).

In design, deciding what to build is based on satisfying the judgement of a person. This could be the design themselves (intuitive design), an end user (user-centered design), or a stakeholder (a mixture).

Heuristics

These appear to be poised opposite each other on a spectrum of hard and soft requirements. But that assumes solving the problem of what to build is simply mechanical. Problem solving is creative and involves synthesizing existing solutions in appropriate combinations as well as introducing novel solutions to the context. Both a designer and an engineer rely on a set of heuristics to build a solution, including the introduction of any sort of formal design process.

Trade offs

It is this aspect that ties engineering and design together. Both require space for ideas to be pieced together and evaluated. In any non-trivial situation, the addition or subtraction of an element affects the performance of the solution in a complex way.

A user experience design is not simply a set of steps to walk through. It must consider the holistic experience of many different types of people. It needs to take into account what is practical.

Similarly, an engineering solution is not simply the set of components involved. It isn’t even the much larger set of combinatorial ways that the components could be arranged. It must consider flexibility to meet future conditions and extensibility. A solution must address maintenance and the skills and abilities of the team who will maintain it.

Continue reading

Book recommendation: Turing’s Cathedral by George Dyson

If you’re interested in the early history of computing, check out Turing’s Cathedral by George Dyson. It covers an interesting middle phase between the original electronic digital computers and the wide commercialization of computers in the late 50s.

The cover of the book recalls a punch card.

Specifically it examines the people and development around “the IAS machine” at the Institute for Advanced Study at Princeton. Big and not as big names make an appearance, and it is a detailed account of the forces at play: academia, industrial, military, and political.

The design of the “IAS machine” was the pattern for dozens of machines around the world. More than one country’s “first computer” was one built using the design developed by the people at IAS. I think of it as the first practical computer – the construction needed to solve a lot of problems that the original electronic computers didn’t need to address because they were just struggling to exist.

I’m not going to lie: there are a lot of “white men in ties” involved.

It’s been a while since I finished the book, but I do refer to it when I need details of how some design constraint was surmounted. It also includes enough biographical information that I use it to jog my memory of exactly who was who. The world of computing was still small enough that people who contributed to the IAR project show up in other places pretty often.

It’s widely available. It looks like Thriftbooks has it for under $5, so you could get it for free if you’ve got some reward points there.

Recommendation: “Citizen 13660” by Miné Okubo

The American internment of Japanese Americans during WWII is one of the many shameful things in my country‘s past that I didn’t really learn about growing up. Only when I moved near a park in Seattle that was on land taken from interned people did I begin to grasp the horror of it.

Highly recommended

Miné Okubo was interred herself and details the account in Citizen 13660. The title comes from the number assigned to her by the government as she went through the whole injustice. Citizen 13660 is autobiographical and told in a combination of words and images that are brief and poignant. It’s a book I revisit occasionally when thinking about the sociopolitical forces that have gotten is where we are.

The edition I have includes an introduction by Christine Hong which helps explain the portions of Okubo’s journey in the creation of the work. The book is inextricably connected to her release from internment.

The author is present in most of not all images – reminding you that this is autobiographical

I should also mention Okubo’s art. I find it brilliant and engrossing. There are very specific details in some images – someone’s expression or just the way some space is drawn. I can’t help but consider how emblematic certain things would become.

I’m not really qualified to relate the gravity of the experience of Japanese Americans imprisoned during the war. Miné Okubo’s Citizen 13660 is the primary source I suggest starting with.

Book recommendation: Cathedral, Forge, and Waterwheel by Frances & Joseph Gies

If you’re interested in know “How did we get here?” then I highly recommend Cathedral, Forge, and Waterwheel by Frances and Joseph Gies. It dispels the myth that Europe of 500 – 1500 CE was some mud-filled backwater just waiting for some brilliant Renaissance thinkers to come along.

The cover of my copy

Don’t get me wrong – it wasn’t a glorious time either. But CF&W explains the development of specific technologies and how they changed society in a way that led directly to the (more celebrated) events of the Renaissance.

Probably one of the most important developments was of a merchant class as a center of power that could rival dynastic royalty. These developed into guilds and families that were patrons of those famed Renaissance artists as much as royal and religious wealth.

It also marked some of the first mechanical industry due to the shift of a source of power not dependent on animals (or people).

Is that person making a glass vase or jamming a wicked trumpet solo? Who can say?

The history of technology as recorded by Western historians is usually Euro-centric and that does leave out the larger context of how knowledge was flowing from Asia and Africa. It’s been a while since I’ve read CF&W, but I recall it doing a good job talking about how the origins of many things came from outside Europe. (And the back cover says so too, so I’m probably remembering right.) As you read any history, it’s worth keeping in mind the bias and agenda of the authors.

It’s an approachable and interesting read about a time you might not know a whole lot about. It looks like ThriftBooks has it, too.

Showing Some Work

I recently read Show Your Work by Austin Kleon. It is a short read and I recommend grabbing an electronic copy from your local library and reading it over your lunch hour. Ryan sent it my way and that has been helpful

Kleon provides some practical advice, some of it perhaps a little conflicting, but overall it’s solid. I wrote up some notes and drafted a short review/musing that I’ll post later.

“So what?” as he says.

Well this post is coming from the WordPress app on my phone as a test of an easy way to get my process documented. To fully simulate what I will be posting more of, here is a picture of my workbench.

My workbench, covered in stuff

Starting from the bottom right and going counter clockwise:

  • A Sun keyboard I got for cheap at the recyclers. Unknown if it works
  • IBM Model M that auto switches to XT keyboard protocol
  • Z80 single board computer that I added a second board to… so I guess it’s a TBC not an SBC
  • My eBay power supply next to a power supply I built from parts
  • soldering iron, tools, a little tool holder I designed and 3D printed, oscilloscope
  • LCD monitor for experiments
  • A bunch of project trays. I’ll have to talk about these at some point but the short description is that a project that isn’t finished goes into a tray so the parts don’t get scattered but also doesn’t get hidden and forgotten
  • My KayPro XT compatible retro computing project.
  • My new hot air rework station amongst a pile of junk and parts
  • And finally in the center are my “current” projects: RaSCSI drive emulator and some prototype modular synth modules

In an effort to follow his advice in story telling – This photo tells a story with a three part structure. The tool holder is a completed project and represents the beginning of my ability to design and print useful objects. The RaSCSI and synth modules are what I have completed so far. Their promise cannot be fulfilled until I add their final prototyped features and send them out into the world as complete ideas. The KayPro XT is the future. It is a fully functioning computer with a case and upgraded features. It will become a virtual museum piece, accessible by KVM over the Internet – the first of a handful of machines I want to add to my virtual museum.

So I will be writing more posts from now on. I’ll be integrating this site with my personal site. I’ll be adding links to references and other works. Thank you for reading and feel free to contact me if you’d like to work on something together!

Mission Statement

I have many reasons for starting this blog.  I need a place to document my projects for myself.  I want to have a way to share my projects with others.  A blog seems like a chance to learn to write better.

But the most important reason is that I want a way to encourage the topics in which I am interested.  I hope this blog can be that collection of projects and ideas that I seek.  As someone once told me. “Make your work what you’d like to see out in the world.”