Creating Software, Hardware, and Community

Archive for category Professional

There is a great post on the website The Street with Peter Semmelhack of Bug Labs, on why hardware is hard. I’ll wait here while you go read it…. Disclaimer: I worked for Bug Labs on ’09-’10. I dig Peter’s vision and experience.

Bug Labs Hardware Engineering an adventure for 2013 that played out around 2007 to 2011, part of which I was there for the last two years of. At the time, their software system was growing well and with the industry, while the Hardware/Firmware development was, frankly, a black-hole of engineering time suck.

For the time I was there, things were a bit rocky, and the realization the hardware vision was nigh impossible was a tough vision change to make. Pluggable complex engineering is absurdly hard, for engineering reasons I’ll get into below. Peter did a great job of herding the company onto a new path, It’s great to see Bug has pivoted to a place where it vision is technically possible, and is having great success.

Given that, It was a surprise to me this month to read about Project Aria and PhoneBlox. Two admirable projects that sound great as YouTube videos, but projects that are none the less destine to a die via death-by-a-million-solder-burns. It was pretty sad to see that hubris (Motorola) and lack of domain knowledge (PhoneBlox) leading well intentioned people down a rocky road.

A road to a black-hole that other companies, like Bug Labs and Open Moko, had already mapped out with giant warning signs and ‘Black Hole Ahead’ articles sharing their traumatic experience.

I could write a whole detailed post on each of the red-flags on these projects, and how it overlaps with the insurmountable challenges of Bug Labs Hardware. but I’m going to stick to bullet-points unless I get some reader-request to elaborate on some of these.

To ‘plug together’ a device of phone complexity, you need decades of engineering, or 2-4 years of education. These won’t be accessible outside of trained engineers, or a huge engineering NRE.

Ruggidizing core components while maintaining speed is impossible.The faster, hotter, and smarter you make electronics, the more finicky they are.

If you do ruggidize them, you need slower plug-friendly protocols which are 2 orders of magnitude too slow for modern expectations.

Delay: The open phone tech will always be 6 to 24 months behind the advertised *buy now, we ship next month* phones.

People pay a lot *not* to assemble their own PC’s. DIY PC kits and purchases are a niche of a niche, even amoung nerds and hackers. Seriously, people want to change their wallpaper and font-defaults, not their RAM or front-side-bus.

We’ve been down this road, in projects by Open Moko. Bug Labs, and more. The ‘fully configurable’ system is going to be crash-tastic. It’s great PR, it’s shit engineering.
Imagine the phone as a car-level complexity devices. Changing out the dashboard, or some plastics. or adding a spoiler to a car? Sure, a great idea. Changing out the engine, or suspension, or powertrain really takes a mechanic, or a car so de-tuned it’s worthless on a highway (which is why I loved my Vespa ET3). A few hours of thinking would make it clear the fully-pluggable system is a daydream.

I have more hope for Jolla, built by thoughtful engineers. The ‘plugable’ modules are nice-to-have add-ons and external to the core system. They are a bit isolated, and they are not core components of operation. It’s much more likely to succeed, and they can use isolation circuits and ‘firewall’ the plug-system to a few external pins/ports, rather than ruggidizing a lot of internal connections and parts.

If you want me to expand on any bullet-points, just drop a note in the comments, and I’d be glad to rant on in detail why those are such problems.

I’ve been helping a bit in the background of Open Hardware Summit this year, aka OHS 2013. Like many Open Source projects, OHS tends to lean on people who self-select for expertise, and people who don’t have the best balance of work-life (aka, people’s who’s hobby is their life is their job, etc. OHS also takes self-nominees, I.E. you just submit your own talk.

This system tends to skew the talks submissions in a few ways. It skews towards people who are self-confident in their abilities, which to be honest often does not map to the most skilled person. It also tends to skew talks to people that have pre-made talks, or who have given talks before. Even submitting a talk to a conference is a bit of a skill set and gained knowledge, and can really be a time sink for someone doing it the first few times.

Which leaves me with a good question I don’t have an answer for. How does a community event do outreach and find speakers, but still skew towards most genuine knowledge, instead of most self-reported knowledge? How to get the shy knowledgeable people to apply, not just the gregarious or self-assured people?

Last Tuesday I was lucky enough to be invited by Philly PUG to give a co-talk with Spencer Russell. Spencer and I each have some experience in making an easy to use command line console (Spencer) and posting a project to Python Package Index (PyPI).

It was a great talk to a packed house. More than 70 people showed up, with Bu Logics, where Spencer and I work, footing the bill for some snacks during the break.

Most of my friends know I left MakerBot back in December/January. They were going in a direction that didn’t fit my style/interests and the commute back and forth to NYC was becoming a real headache, especially with a little human in my life. Someday when dust has settled I’ll talk about it. But for now there is too much chance my opinion would misunderstood or ‘creatively’ misinterpreted by folks that have been with MakerBot. No hard feeling on my end, but the situation just wasn’t working out.

After leaving I took some time off, then spent some time taking took a look around the Philadelphia scene for any interesting opportunities. After talking to several shops I finally found a great fit for my interests and skill.

As of last week I’ve joined on with BuLogics as Chief Innovator. I’ll be once again herding nerds and working to keep the engineering and design team in close coordination with the business folks. Two things I enjoy, and am pretty damn good at.

Part of what set BuLogics offer apart was a chance to have a big influence in their next stage of growth. They are looking to expand and focus their skills a bit more cleanly. It’s hard to pass up such a great opportunity there to help take an organization to the next stage of growth.

Another great side effect of the new position is that I have a lot more flexibility to blog. So you all can look forward to more posts about teams, teamwork, and creating a culture of making both here and over at BuLogics blog.

P.S. also, check out the terrible bio photo :( It’s the only one I had available when they posted that I’ll have to change that soon.

It is sometimes hard to keep to a charter or agreement one has made without public acknowledgement and feedback. People are social animals, and we are well built to follow social contracts, but sometime private agreements are forgotten.

So it’s with a sadface :( that I write this post to publicly admit I failed to stand by the ‘Not to Speak or chair all male panels’ pledge I signed on for. To be fair, the panel was chaired by a woman (the fantastic Phoenix Wang) and it wasn’t a public event. But nonetheless, I took a pledge and dropped the ball. Mea Maxima Culpa. It was a pledge I signed without talking much about, and I completely forgot I agreed to the pledge until the day after the panel. Interestingly enough, I just took a look back at the pledge page, and I can’t read the pledger to see who else may be slipping up, or defecting. Nor did I see any suggestions on how to make up for a slip-up for pledges that forgot their pledge, or who get stuck in a rock/hard-place and must take a panel without a woman member for some extra-ordinary reason.

If anyone has any good suggestions for a proper Mea Culpa for people that don’t live up the the pledge, drop ‘em in the comments. I’ll be picking one of them, or inventing my own, to make up for failing at that pledge.

Back in the 1960’s and ’70’s a researcher for IBM named Greet Hofstede did some amazing research about culture, and found 7 cultural dimensions that map onto all human cultures, and knowing those dimensions tell a lot about how the culture behaves. Those dimensions are:

power distance (PDI)

individualism (IDV)

uncertainty avoidance (UAI)

masculinity (MAS)

long term orientation (LTO)

I’ve also gotten into a habit of thinking about how colleges fit into that scale, so I can better understand what they want or expect from a working (or personal) relationship. It’s an interesting and useful lens to use when figuring out how to work with people in an organization that you don’t automatically click with.

Two-ish year ago phooky asked me to interview as a lead desktop developer. I wasn’t really looking for a job, but since I respected him and his incredible hacks, I agreed. At the time it was a small pre-funding startup. To work with a hacker I respected so much, and on 100% Open Source technology was enough of a draw me from Philadelphia to work in Brooklyn. Since then I’ve been shuttling back and forth from Philly to Brooklyn most of the week so I could herd the nerds for MakerBot. It’s been an amazing opportunity, but a recent addition to my family means I need to be in Philly full time.

MakerBot gave me the challenge and honour of building a great department to create a stellar product. I also had the rare joy of a blank slate on which to redesign and implement our new desktop software stack, hand in hand with a group of brilliant developers. We created a new slicer, a new tool-chain system, a new device driver, and even a beautiful and simple UI on a tight schedule, with some great partners. Despite the controversy about closing some source access to MakerWare, it’s a product I am very proud of. It’s fast, robust. It ran cleanly on 3 platforms from first day it shipped Without a doubt it is the most impactful product I’ve shipped. The most on-schedule product I’ve shipped too!

It’s quite bitter-sweet to be leaving MarkerBot, and a department I shaped, but c ‘est la vie. Goodbye Brooklyn, and MakerBot! It’s been an honour, a challenge, and a joy working with you. I’ll miss the great humour, the inspired hacks, and the great brainstorming. Even though you won’t really need it, I wish you all the best of luck. With the pool of talent still there, I’m sure the company will grow and succeed regardless. I’ll always look back fondly on the great time and great people I worked with at MakerBot, and Ilook forward to seeing great products and projects you ship in the years to come.

… but at the same time, Hello Philadelpha! It’s good to be back full time. Lets get into some trouble.

I came across an excellent (and old) online talk by Greg Wilson on the net today, covering what we believe about software development. It’s a good talk about how little science we use in deciding and reviewing how we plan software, and highlights how many bad or guesstimate numbers computer scientists and engineers throw around when talking about their profession. Watch the video.

The best developers are 28x more effective than the worst

Along with the bad statistics of it, it’s not backed by good data. The studies were long ago with small sample sets, they really don’t apply to modern conditions. Common sense? Not especially. Also, there is the statistical problem of *ever* comparing the best to the worst. It’s a useless measure since ‘worst’ could be someone taught to code an hour ago. Comparing against mean/median/mode is probably a lot smarter.

SCRUM and Sprints keep software from being late

Another good point. As far as I’m concerned, working in a sprint system is what got MakerWare out the door on such a great tight schedule. Iterative design and culling features, as well as allowing for error and error correction during the process. But the plural of anecdotes isn’t data, the plural of anecdotes is rumors. Is there really smarter planning going on? Smarter throwing away features? What is the actual process that makes SCRUM seem or be, better than planning up front?

Until I watched the video, I had not recognized how many software process decisions we as a culture made by anecdote based suggestions, or convinced over beer discussions. If you have time, watch the talk, or add his blog to your RSS reader.

I was reading up on some software management design, and through the random links of the internet I came across the wikipedia article on Twelve Points of Leverage. Having worked with a lot of system, I’ve always been curious about system, and what drives them.

I was blown away by the fact that someone had the insight (and gall) to totally generalize large system input and control, and pretty succeeded at it. There is a single developer* article on the topic, but I’m quite astounded it doesn’t show up in engineering or Comp Sci more often.