Articles – Page 7 – Upverter Blog

Resistance to Schematic and Layout Review

The team lead or line manager enters the room and calls a department meeting or a design review session. Suddenly, almost everyone on the team starts mumbling or reacting with groans.

You’ve probably all experienced this situation. As a hardware guy, you have little tolerance for interruption, especially for long and tedious meetings that impede your productivity. The idea of having to sit and listen to other people discussing a blurry projected schematic, or working through a printed PDF booklet just so that your design-challenged colleague at the other end of the room can find out what he’s doing wrong, can be really upsetting.

The concept of design review has been around for a long time. Everyone knows the value of double-, even triple-checking your work (think back to elementary school). Every discipline has worked out a formal or informal collaborative process for checking and validating work: Writers have editors, accountants have auditors, and software engineers came up with pair programming a decade ago.

Software’s got it right.

There used to be a time when the conceptual design phase for software development lasted much longer than it does today. But it eventually became widely recognized that the static, non-iterative model of development (school teachers call it the waterfall model) was not effective in producing quality products on a competitive schedule.

So software development evolved to what it is today: agile and iterative. Its rapidly-changing nature creates continuous opportunities where peer code review is valuable and necessary for quality results.

In the same light, regular peer schematic and layout reviews should be seen as a logical component in the hardware development process. Some direct benefits to incremental design review include:

Fewer defects and errors in final design
More errors caught early on when they’re cheaper to fix
Improved communication and knowledge about design content (bus factor)
Mentorship of junior members of the team

And some longer-term, indirect benefits:

Lower number of revisions & re-spins
Faster time-to-market
Less time spent on debugging

Egos, isolationists and crappy toolsets.

Reading those lists of benefits, it should be a no-brainer to implement design review into the development cycle of every project. And yet, many hardware companies still don’t have peer review as a regular and mandatory part of their design process. Why? There are two very straightforward answers when you dig into the basics of human psychology.

Ego
Outdated reviewing methods

Let’s start with ego. We’re talking about hardware engineers right now but this applies to a vast majority of people at their workplace. We naturally feel like our work is an extension of ourselves. Someone judging our work is like having them judging us.. Two different types of people/engineers emerge at this point: The first class consists of collaborators, team players, and those who see it as constructive. When confronted with a problem they can’t solve, they will naturally turn towards a peer who knows the answer. For these guys, peer review is a beneficial process.

The second class is made up of isolationists. When confronted with a problem they can’t solve, they would rather unproductively try to find a workaround for hours (even days) rather than reach out to their peers for help. These guys can’t admit that someone else may know something they don’t.

Attitude over aptitude

In 2002, it was reported that the average career in high-tech lasts around 8 years. The isolationists are doomed for a shorter one, as their body of knowledge exclusively lies in what they are able to figure out on their own.

Overinflated egos can’t be good team players because their faculty to share with and learn from others is impaired. On the other hand, collaborators showing a continuous interest in learning will increase and sharpen their skills, remaining productive (and employable) in a constantly-changing field.

Design review can be painless.

Reviewing hardware designs has not been commonly included in the standard development cycle in a majority of companies for another reason: The tools are not adapted. PDFs, projectors, meeting rooms and highlighters are completely outdated ways of reviewing design. Back-and-forth email threads and over-the-shoulder methods are also inefficient and a waste of time. The key is to introduce a technique which allow each member to contribute to a review when they’re focused and willing to do it. It also shouldn’t include an archaic, middle-step that slows down the execution of fixes.

If you’re thinking about implementing an efficient design review process within your team, let us know. We’re happy to help. There’s no longer an excuse to not review designs!

Doin’ It Right: Engineering hardware like you engineer software.

Engineer hardware like you engineer software

When software engineers have a problem with their engineering process, they solve it by writing software. Other engineering disciplines have it harder. Lacking instant automation, other fields accumulate ‘rules of thumb’ that they hope to maintain throughout the design process.

So it’s hardly surprising that the tools and processes software engineers invent for themselves emerge years before they enter mainstream engineering design thinking.

Tools like version control were among the first systems created by software engineers out of sheer necessity. Others have defaulted to elaborate workarounds, exchanging updated documents by email and tracking changes by adding version numbers to the file name.

But software engineering has so much more to offer: a culture of re-usability, team-based development, test suites, and code review. Few of these have seen application in full-force outside the discipline of software.

Why?

Because the rest don’t know what they’re missing. If the epitome of hardware engineering is to single-handedly design an entire board or module over several weeks and send it to manufacturing, it’s easy to forget what the world might look like if other talented colleagues were a part of the process. What if others could start incorporating your module into their design while you complete the layout? What if
they could run your latest test suite – or design rules – against their design to guarantee compliance? What if everyone on your team could continuously review the unfolding design, layer-by-layer, from their desk, and highlight problematic areas?

Did it ever occur to anyone that the idea of printing a picture of every layer of a circuit board on paper was ridiculous?

More than ever, hardware today requires engineers with wide expertise to be successful. Your RF guy, video guy and processor guy need to be able to work meaningfully together, in real-time. Because it’s not 1997 anymore.

Forward.

Upverter’s product suite is designed to address this problem. How can we lend hardware engineers the same empowering boost that software engineers were able to construct for themselves thirty years ago? How can we enable hardware engineers to be more agile?

Of course, they are different domains. Shipping software to the web is a considerably less risky prospect than shipping a prototype to manufacturing. But if more is at stake, we should be doubling down on tooling, on automated testing, on collaborative review. Even if the cost of prototyping isn’t problematic (and it often is), the opportunity cost is astronomic.

What if you could halve your number of pre-manufacturing prototypes? What if design review wasn’t a meeting to be dreaded by the team, but a routine, straightforward daily activity? What would this do to your competition?

Ultimately, shipping should be a celebration, not a fear. It should be a moment of certainty, of success, of comfort that you and everyone on the team has had total insight into the evolution of the product, and that every issue has been tracked, identified, and addressed.

And we think we can get there.

4 Reasons to do a Better Job at Design Review

On this blog, we often point out analogies between hardware and software development. Here’s one such analogy: just as it has become easier to write software thanks to technology, behavioural evolution, and better processes, new tools have appeared that make it easier for hardware engineers to design better devices.In this post, we want to talk about one of these tools: schematic and layout design review. Design review is code review for hardware. It is the stage in the design cycle when one’s work is peer-reviewed for errors.

We were curious to know how companies implemented their design review process and what tools they used to achieve it. So we ran a survey over the last few weeks and talked to 400 engineers worldwide from all over the spectrum: big firms, startups, medium-size businesses, and so on. Surprisingly, we realized that in the era of advanced technology the most commonly used tools for design review were… highlighters, red pens, printed PDFs, and meeting rooms. One of the most elaborate devices used to complete design review must have been a projector or a laser pointer. Nothing really innovative there!

Having reflected on the survey, we came to the following conclusions.

1 – You already know the value of design review

Drawing a schematic is basically an exercise in carefully reading datasheets, app notes, and reference designs to learn how to best connect up each component for your application. This is in addition to all of the work involved in developing the top-level architecture for your board and selecting components to meet the product requirements. Each of these steps is an opportunity to make a mistake.

Every seasoned hardware engineer has had the experience of spending many frustrating hours debugging something on their prototype only to discover the root cause was a careless error in the schematic or layout that should have been caught earlier. This results in wasted time, a costly board spin, or worse, being completely blocked from testing a particular part of your board. Every hardware engineer knows that after spending many weeks working on the same schematic you’re simply unable to see errors any more. You need a fresh set of eyes to take a look. This is what design review delivers.

2 – There are all sorts of reasons that people fail at design review.

It’s well-known that design review isn’t done effectively right now. 75% of the engineers we spoke with told us they are well aware that they needed to do a better job at design review. Similarly, 71% of our beloved guinea-pigs described their process as ‘inefficient’, 23% found it truly ‘painful’, and only 6% were happy with their current tools and processes. The interesting question is why this is the case.

Our survey has revealed that: In order to really add value via design review you have to understand the product requirements, carefully read all of the datasheets/app notes/reference designs, understand what the designer is trying to accomplish, and then look for errors. If you don’t read the datasheets and get into the mind of the designer, you don’t add much value because then you’re only able to find the really obvious mistakes (like a power pin being unconnected), which are much less likely to be present. Design review requires you to spend a certain minimum amount of time which can easily be a few days for complex designs.

To that end a colleague is often asked to look at the design at the very end of the process, making the design appear large and daunting. As a result, the colleague, who is very busy him or herself, feels rushed and simply skims over the design and datasheets. They may not thoroughly focus on each section. Often the team culture doesn’t accept, nor encourage, an engineer to dedicate a few consecutive days to design review.

Another familiar scenario is a designer completing a schematic, sending it out to the team for review, scheduling a meeting with everyone a few days later, and everyone showing up to the meeting without having looked at the schematic! Everyone expected to talk about the design as a team. This approach is not as valuable. With layout it’s even worse. A completed layout, especially one with 8+ layers, can be so complicated that’s it’s too daunting and difficult to review all at once at the end. Finally, a lack of tools to streamline the process is the most prominent reason that companies skip design review or is the most likely reason for why they fail at design review (think back to those red pens and meeting rooms).

3- Design review shouldn’t be a separate task in the design cycle.

The best way to do design review, in our humble opinion, is to set up an incremental design review process. A short review should be done after each component (or small group of components) is placed on the schematic or layout and is mostly connected. This task is much more manageable for busy engineers. It may only take 1 hour or less to go over the datasheet and check for mistakes. It lets engineers ask questions early about design decisions. And best of all, when the design is finished and ready for final review, all team members are already familiar with every part of the design and will be much more effective at reviewing. In other words, we suggest distributing the review time throughout the design process instead of doing it all at the end. To dig into the analogy with software development, can you imagine writing an entire application and reviewing the whole code base at the end? This wouldn’t make much sense. And the claim that incremental design review works is not just a hypothesis: 97% of companies that implemented an incremental design review process in their standard design cycle found more defects on average than teams that did not. Even better, 72% had one less board revision.

Incremental design review needs to be instilled in the team culture. Managers need to foster an environment where mistakes are okay. Engineers shouldn’t feel uncomfortable putting their work up for incremental review. There needs to be a very supportive team culture where it’s understood that the primary goal is to create the best product possible and become better designers along the way. Mistakes should be celebrated (as long as they’re only made once) because you learn something really important with each mistake.

4 – Current design review tools may as well be from the Middle Age

Ok, this one may be a bit extreme but… red pens, and (non 3D) printed PDFs are probably the most inefficient tools to achieve a proper design review. Why? Because if you annotate and comment on printed PDFs then it’s likely that one poor dude will have to go back and fix all the defects. And he’s probably going to get several copies of the design with different issues pointed on each of them. Then he’s supposed to summarize all of it and adjust the design with as little delay as possible. With this approach, how do you understand design decisions? How do you keep track of what remains to be fixed? How does someone other than the overwhelmed designated-victim assess the project status and define an ETA?

But don’t panic, it is definitely not your fault. Nor your manager’s. There are currently no good tools for design review especially if you want to do incremental design review. Actually, that’s not true: there is now one tool to do this. Its called Upverter. But this is not the right time or place to talk about this 🙂

Internet of Things & Hardware 2.0 – More Thoughts

Image by Vincent Piotrowski.

Last weekend I wrote up the first of my thoughts on the internet of things and hardware 2.0 movements and how they related to Upverter. This is the second half.

The second part of the meetup that peeked my interest was during the talk by Pachube founder Usman Haque on how we might get very, very close to the internet of things – but never actually make it. He cautioned that building IoT-ish devices like the Nike Fuel Band, but then siloing the data, and locking users into close app ecosystems wasn’t the Internet of Things, but rather just the old hardware model with a services business built on top of it and jammed into the cloud.

I think he’s right.

I think an internet of closed, largely unconnected devices, silos full of data, and no real API or interoperability is only marginally better than today. Its not even really an internet. Its much more akin to the old M2M paradigm (a bad thing). I think unless the incentive system is fixed, or the hardware is opened up, or the data is opened up, or the services are disconnected from the hardware and apps, the IoT won’t ever actually happen.

Open data.

I think the goal should be open data. It could be through APIs, or an “internet” where it all gets stored. It could be through more open hardware that posts to a server of the user’s choice. Or through guerilla firmware and hackers.

If open data exists, apps will be built. Just look at the veritable ecosystem of thousands of twitter apps that got built around that datasource. Imagine sensor data from all over the world, or all over your body, and the plethora of apps that could be built to consume it.

People pay for apps.

And people pay for hardware, but people won’t pay for data. So the question quickly becomes how to open up the data, and use the money from both its collection, and its consumption to pay for all pieces of the ecosystem. If the internet depends on open data, and there is no incentive for a silo to open up their data, and users won’t pay to generate open data – are we simply doomed?

Could you sell hardware that came without consumption apps?

Could you sell both the hardware and the apps separately?

Could you convince a hardware maker to give the hardware away and charge for the app?

Could you convince app makers to pay to use open data?

Could you create a marketplace around data?

Could you find a way to give hardware away for free?

Could anyone get large enough to define a standard open data format? (The IoT version of DoD)

Could someone build an open warehouse for open data and apps? (The IoT version of force.com)

Thoughts on Hardware 2.0 and the Internet of Things

Gigaom recently hosted a great get together in San Francisco talking about Hardware 2.0 and the Internet of Things. The meetup focused very specifically on connected devices and the quantified self, but the crowd was much more generally hardware focused. It was cool to see the energy around the event, and the continued growth of the hardware startup theme.

There were 2 parts of the meetup that made me sit up and pay attention, and I wanted to share the first of them here. It was from David Merrill from Sifteo’s talk on designing hardware in the world of the glass slab (smart phone). He argued that the smartphone has and will continue to kill lots of application specific hardware, but that there are 3 very specific reasons to build hardware despite the smartphone.

1. You need to interact with legacy hardware

Nest is a great example. Buying a smartphone and wanting to control the environment in your house simply aren’t enough to replace your whole heating and cooling system. So Nest created a piece of hardware that bridges the gap.

2. You need to interact with atoms

Makerbot is a great example. There is no conceivable way to print plastic from your smartphone without a new piece of hardware. Transportation, telepresence, and distributed sensor plays all fit this bucket too.

3. You need to interact with the human body

Pebble, Nike Fuel Band, WiThings, ibgstar, etc are all examples of this. I think its kind of a combination of the above 2 categories, but it explains better as 3. Quantified self fits pretty squarely in this bucket.

The short version is that as I was sitting there listening to Dave I realized that while he was talking about the reasons and ways to design IoT hardware. The ways not to get killed by the glass slab. And the role hardware startups have in solving problems. Dave was also describing a very large chunk of the Upverter community. He was describing our users and the problems they are using Upverter to solve.

And after I dug a bit deeper I realize a couple of things…

Most of the designs in Upverter fit into one of these buckets.
Most of the designs in Upverter are Hardware 2.0
Most of the designs in Upverter are part of the Internet of Things.

Pretty cool. We set out to build the best design tools at the exact same time as the hardware community set out to build smaller connected devices – it might turn out we’re made for each other.

But realizing this has made us all wonder – how else can we help throw gas on the fire? What features to IoT hardware hackers need that engineers have never needed before? What happens when you engineer a connected device that doesn’t happen when you engineer a phone or a server? What would make you better and what don’t you care about?

What is Hardware 2.0

Last week I spoke on a panel at a conference in San Francisco hosted by Lemnos Labs a very forward thinking hardware startup accelerator that like Upverter has a lot invested in the resurgence of hardware as a startup genre. The topic of the conference was “Hardware 2.0: The future of hardware” and it got me thinking about what changed. What is different between Hardware 1.0 – the Apples, Intels and the Sun Microsystems of the the world – and today?

This post is a first attempt at defining Hardware 2.0 and explaining the resurgence of hardware startups. I think five things have happened together, and they are colluding to bring hardware back.

Hardware as a Portal

Startups: Lark, Fitbit, Nest, ElectricImp

Call it the internet of things if you want, but it’s really more than that. As the big data movement continues to call for more and more data about everything from our hourly activity to our car’s engine hardware will be built to put it all online. It’s the reason for every buzz word from M2M, to the quantified self. It’s resulting in the merging of industrial control networks and the internet. It’s going to make it a hell of a lot harder to fake your dress size, or keep your reactors virus free.

Democratization of Tools

Startups: Upverter, Grabcad, Sunglass, TinkerCad

For the better part of the last 30 years CAD, ECAD, MCAD, EDA, CAM, PLM, etc. have all been impossibly inaccessible to most designers anywhere but at large companies. Workstations becoming desktops helped. Windows OS helped. Bittorrent helped. But generally startups couldn’t and still can’t afford thousands or tens of thousands of dollars of software before ever creating something. The combination of the HTML5, crowd sourcing, real-time collaboration, and github inspired reuse are resulting in a new breed of better, cheaper, modern and more accessible tools – which ultimately opens the door for an order of magnitude more hardware startups.

Rapid Prototyping & China

Startups: Makerbot, Shapeways, Ponoko, TechShop

If you know anything about software development, you know that it’s amazingly cheap to compile your product in both money and time cost. For all but the largest software packages it only takes a few seconds and a fraction of a penny worth of power. For most of history “compiling” a hardware prototype cost many weeks and many, many thousands of dollars. Often you could only afford to build a few before you ran out of time or money. 3D printers, rapid prototyping services, and China have all changed this. It’s now possible to get a couple of just about anything built and shipped, just about anywhere in the world, for a total cost of maybe a hundred dollars and a few days. This means more prototypes, faster iterations, and less capital required to start a hardware startup.

Pre-Sales & Crowd-Funding

Startups: Kickstarter, Indiegogo, Tindie, GrandSt

This one is kind of amazing. It’s now possible to sell a product you haven’t even built yet. This has two huge impacts. First, hardware has high upfront capital requirements, non-zero cost of goods sold, and things like component lead times which all means it’s hard to jump the gap between a prototype and mass manufacturing as a startup. Pre-sales means startups can sell product to fund manufacturing it without requiring venture capital or government grant money. Second, it aligns the incentives of consumers and hardware startups allowing the startup to test market fit before investing in manufacturing a product the market doesn’t want.

1 Billion Cellphones

Startups: Pebble, Square, AliveCor, DoubleRobotics

Today odds are that 1 in 3 people you know (in the developed world) carry a veritable super computer in their pocket at all times. This computer is capable of acting as the brain or the display or the network backhaul for any number of new devices. These mobile computers also now represent the majority of connections to the internet worldwide. These computers mean startups can build simpler and cheaper devices, with better interoperability, fewer battery constraints, and generally shorter times to market. The next great consumer electronics company will very likely start as a hardware startup with a widget for a product, a small device that is little more than a feature.

So What?

It’s always been harder to start a hardware startup. It takes a different kind of founder. A different kind of tenacity. But these five forces are levelling the playing field. Lower barriers, and better incentives mean hugely more startups. It means more problems become solvable, and more aspiring entrepreneurs build real companies instead of bullshit social coupon sharing apps. It’s still going to take a couple years to hit full speed, but it has already affected the devices we wear on our wrists, the way we pay for things, and the way we heat our homes.

The rest is inevitable.

Should we love or fear flying robots?

Most people loved Vijay Kumar’s presentation at TED of the work being done in his GRASP lab at Penn. We did, Hackaday did, and Chris Anderson sure did.

Farhad Majoo at Slate did not. In fact, he sounds like he’s ready to go all John Connor on us.

About a year ago, Mellinger posted a video showing a team of three drones building structures out of large metallic beams. The machines fly in a terrifying, coordinated ballet, each of them picking up a beam, finding the exact spot where it should be placed, and gingerly snapping the object in place.
Stare at this long enough and you could mistake the scene for something adorable—birds building a nest. But by this time you’ve stopped staring. Instead, you’ve opened another browser tab to look for good deals on bomb shelters and MREs.

Upverter believes that robots are cool and that flying robots are REALLY cool! Designing a robot from scratch is a great way to bond with your kids, help them learn math and science, and show them what you can do with advanced calculus and n-dimensional matrix algebra. No more questions about what use does math have if they’re optimizing the 4th derivative of a path for their flying robot OF DOOM!

One thing we did learn from Terminator 2 is that it takes a Robot to beat a Robot. So regardless of where you come down on the question of whether or not Penn’s flying robots will kill us all, you should be building your own and designing them here on Upverter!

There was a guy on the Daily Show the other night talking about how the point of the space program was to beat the Russians. Not to make the world better. And when we won the Cold War we killed the space program. For proof, look at NASA today vs yesterday. Despite doing it for all the wrong reasons, it made the world better. We respected engineers and technologists more than at any other time in our history. Little kids grew up wanting to be tomorrow’s heroes – engineers. In a small way the engineers of today are all reminicient of that. Flying shit is cool not only because it is a feat of engineering, but because it makes us dream of tomorrow. And it makes our kids want to be engineers again. Which is probably the most valuable thing we could ever hope to achieve.

About Upverter

Did I mention that Upverter makes it possible to share designs for real things. There are thousands of high fidellity, accessible anywhere, publicly shared and open sourced designs waiting to be forked, manufactured, and hacked on. If you’ve got a design, you should share it! Need a design, find it! Or just explore for some inspiration.

TPB, Physibles And What It All Means

About a month ago The Pirate Bay launched a section of their site called Physibles [blog] [gizmag] [physibles]. I’m amazed by how huge this is. And almost equally amazed by how little its been talked about. I didnt think I’d be one to have to tell you why this matters, but alas, it looks like I am. You’re welcome. Sorry it took me so long.

Collaboration and reuse are valueable

First and foremost. I want to let that sink it. Starting from scratch is painful and duplication of effort is ridiculous in the age of the internets. And the market is very, very good at removing inefficiencies. Look no further than Napster, released in 1999, 4 whole years before the iTunes store enabled access to media on the internet legally.

People are desperate to share

For a decade or so a small number of people have been sharing their designs for real things in impromptu message boards and phpBB forums. Its a horrible managomy of MS Paint drawn schematics, blinky text and scans of photocopies of pictures from (war era) text books. It’s beautiful in its agressiveness, and provocativly resourceful. But terrible for how hard and unapproachable it makes it all look.

The Pirate Bay is responding to a very real need: the ability to share. Even things as seemingly esotaric as the designs for real physical objects. They will be shared. They will be used. And their availibility and ubiquity will only increase. Someday soon the designs for the next smartphone, or assult rifle will be just as easy to find pirated as Microsoft Office is today. Which leads me to my closing point…

Open source hardware as a deterant

Not unlike what happend in software the companies responsible for building the multitude of real things that surround us will come to a crossroads. Is their offering and their value stored in their designs? Their cad files? Or is it somehow secondary. MySQL, RedHat and JBoss all built very large and successful businesses around a secondary value, all the while giving away most of their IP. As a product maker is it your ability to design the next great smart phone? Or your marketing, manufacturing, distribution and supply nextworks that really matter? Or maybe its doing it first? Or doing it at all?

If you need an example of a company built ontop of open source hardware you need look no further than the every-man’s 3D printer, the MakerBot. Since inception MakerBot Industries has opensourced the vast majority of their core IP. In otherwords you need not give them $1300 dollars and wait through months of backorders. You could buy all the parts in the design, assemble one from scratch, and even save yourself whatever margin MarkerBot would make from you. But their value somehow isnt in the design. Because despite being completely open source the vast majority of 3D printer owners own the product as produced by MakerBot.

Call to action

As you probably have already gathered I think this is a powerful and necessary step forward for the collaboration on and design of real things. I think in the months and years that follow this will be a blip on the radar. And it wont be long before its as common place to share models and designs as it is to steal music and movies.

About Upverter

MIT 6.002x Is A Damn Big Deal. And About Electronics

From the site

“6.002x (Circuits and Electronics) is an experimental on-line adaptation of
MIT’s first undergraduate analog design course: 6.002. This course will
run, free of charge, for students worldwide from March 5, 2012 through June 8,
2012.”

What did you do?!?! Is it my birthday? Christmas? What just happened?

Thats right. MIT’s biggest ever online course offering, and their first attempt at a fully online course is on learning analog electronics. Not software. Not economics. Not civil or mechanical engineering. Not some bullshit social sciences course. But real, powerful and positively useful electrical engineering.

Why Electronics?

I have some guesses. First is the obvious: OpenCourseware (their last attempt at online education) was pushed strongly towards biology, electrical and mechanical. The second is with the advent of things like codecademy, the Stanford ai course, and their own 6.00 online course doing another such course for software would be redundant. And third of the remaining options my guess is they would have optimized for a course where they had material that was easy to serve and check in a web-based environments.

The last 12 months

Its been pretty exciting! A year ago there was nothing beyond the very simple Falstad simulations, a few small communities of professional engineers, some larger communities of makers and DIY hackers, and not much else. Since then about a dozen startups have launched into the open source hardware / electronics / designer community space all very much in an effort to change the way we build real things.

And now, if that wasn’t enough, MIT has bet their prize horse in their second stab at teaching people over the interwebs on an electronics course. Amongst a plethora of wildly successful software courses. It makes me glow.

What’s next?

I can only predict more. The idea of building with atoms and electrons will continue to become a bigger and bigger part of public consciousness. Incredible new ways of doing education will continue to be created. In our lifetime today is the day the fewest of us have personalized, designed, or created something in the real world. There is so much more to come.

About Upverter

Did I mention that Upverter makes it easier to design and build real things. Tomorrow’s pocket platforms and the most revolutionary hardware yet to be conceived is being designed in Upverter right now. I challenge you to take 6.002x, learn something about electronics, and design something real in Upverter.

Quick! Make It Easier For Your Kids To Hurt Themselves

Keeping your kids safe now is only going to keep them safe for now. What happens when it comes time for real life? Do you really want to be responsible for the child who grew up in a padded room?

I didn’t think so.

I’m not here to give parenting advice – but you’re doing it wrong. Do your kids a favor; throw them something other than a pack of crayons. I’m not saying hand them a switchblade, but a circular saw couldn’t hurt. I mean at least let them explore a little…

In utmost seriousness, help them learn some skills that can be used in the real world. Because let’s face it: most artists pay their bills early, and with plenty to spare. While the world is just full of out-of-work plumbers and electricians.

The innovations moving the world forward are going to continue to come from the builders and doers, the engineers and technologists, the adults that we all know who fondly remember the time they blew up the neighbours’ tool shed as a toddler. We need a world filled with more doers, more makers, more hackers, and more builders. We need a world filled with people enabled to fix the big problems we are destined to face. We need a world with more Lego, more K’Nex, more childhood inventions, and a few less toolsheds (insert Darwin joke).

Yes.

Before I end this and go cut something big into smaler pieces. I wanted to answer the burning question you must have right now. The answer is yes. Yes you absolutely can. I don’t care if you’ve never built shit before. You can learn with your kids. You can go to a public workshop. Hell you’re always welcome to swing by our place. Just do it – whatever it takes.

But what you absolutely cannot do is to just allow your children to adopt your fears and your limitations. Because if you’re not careful, they probably will.

About Upverter

Did I mention that Upverter makes it easier to design and build real things. Tomorrow’s pocket platforms and the most revolutionary hardware yet to be conceived is being designed in Upverter right now. Once your kids move past the tearing stuff apart, Upverter might be able to help them start putting stuff back together.