Interesting. I remember thinking it was probably nice to use, but 1) not worth the money (to me), and 2) possibly awkward to carry in some circumstances. I'm probably not the set that would stereotypically care about it, but I am somewhat particular about my interfaces (though in a radically different way than most people seem to be...).
Big deal, every product gets it's-not-for-me-so-it-must-be-stupid comments.
The 'Pencil' product is a good example of the points made in the article. It's a souped-up stylus with some nice features and pretty hardware. But for it to be a sellable and desirable product at $75, it has to tie in well with software. Its app seems to be nice and well-received. They also have a printing service and incorporate social aspects where people share their creations.
It's not uncommon to buy hardware, that on the face of it is very nice, and /would/ be good to use, but getting it to work with your software is just an annoyance. Any company that can convince you going in that the software will be nice to use, is going to have an advantage.
> We have chosen to not use bylines because we believe the voice and insights provided by our subjects are the highest priority.
I came upon this while looking for the author. I think it's too bad they don't use bylines. It matters to me whether the person who wrote this is their co-founder, a capitalist, an engineer, etc.
Rather than not using bylines, I'd prefer that they name the author as well as the reviewers and other contributors, much as Paul Graham does.
I don't think you're the one living in a bubble. Tech journalists of all kinds tend to surround themselves with other tech journalists, and generalize their tastes/experiences across the entire population.
>'Am I the one in a bubble here or are the writers of this article in some strange feedback loop?'
It's not just these writers...
When's the last time you saw something that wasn't described as beautiful or revolutionary? You know it's bad when Silicon Valley spends an entire scene on the breathless "change the world" superlatives of startup culture [1].
Well fuck, why wasn't I invited to the revolution?
Journalists should know better than throwing around weasel phrases like these. Consumer devices like the Pencil are outside the scope of interest, let alone work, of most hardware and embedded software engineers, and it has changed exactly nothing about the field in general, thus hardly making it "revolutionary".
For this blog post, although a journalist (in training) may have written it, it is on the firstround blog and the purpose appears to be both educating companies that first round invests in as well as getting traffic which can bring first round investment prospects. Hence the link bait title "software is eating hardware". Made me take a look. Simply "lessons for building magical devices" wouldn't have.
I'm not seeing any attribution at all as far as who put together this post, could have been a summer intern. Hard to believe (because of no attribution) that it's anyone at first round of any significance.
Edit: Just saw carbocations comment re: bylines below.
After going to their page, I see a carpenter's pencil made for tablets. I don't get the beautiful part. Carpenter's pencils always felt like crud in my hand.
The author and the technology/finance circle jerk he feeds off are most definitely conspiring to put the reader in their bubble. The only thing bubble based software is eating is available capital, which could be used to research and develop more robust, long term solutions by advancing hardware and software together.
People think that they can build a game-changer with some really great industrial design and packaging... what really matters is an equally beautiful software system
Are we missing an aspect here? I feel like we are missing something. I was pretty certain hardware had more aspects that make it compelling than design and packaging.
Having worked in this sort of environment, this scares me a bit. Software creeps a LOT more easily than hardware. It's too easy for a software person to ask for "small" upgrades that end up being much more trouble than they're worth: upgrading to faster processors, more capacity memory, etc, it can be a real pain. There has to be a balance, and I'm not anxious to have a software person direct a hardware team again.
What does systems-oriented mean in this sentence: "It’s the systems-oriented software engineer who understands concepts like power management, radio signals, network communication for small devices" ?
He's not talking about operating systems or embedded systems type stuff, right?
I think the author IS talking about plain-old embedded systems engineers. Finding a competent one is apparently rather rare. From what I've heard, most firmware engineers are EEs with only a rudimentary grasp of software engineering practices and CS concepts.
Based on the context I would assume he means someone that has a deep understanding of which parts of the system can be powered down during certain events, can figure out what the system bandwidth requirements are going to be and how to balance that within the power constraints of the device. I have worked on SoCs (System on Chips) for a decade and a half and there is always at least one person who's soul responsibility it is to make sure all the parts of the system gel.
Systems-oriented software engineer, to me, means a developer who can venture into realms of the system not normally granted a lot of attention; someone who understands the code around the drivers doing all the work for some of the system component modules, for example, or who can formulate a good understanding of the behaviour of the system as a whole, sum total of its parts, and knows those parts well. Whereas a non-systems programmer sees a file-descriptor they can read from, a systems-programmer sees the driver, the cache management, the block and other layers underneath it all that make it work. i.e. not an Application developer, who assembles blocks, but rather a Systems developer, who makes blocks and destroys them at will.
Software vs hardware again. I've worked in both sides of things (EE and software) and despite it being my income now, I distrust software people more than hardware people.
Hardware people have to get it right first time and generally have better engineering discipline. They are also supported better by their tools (software tooling is crappy at best compared to say SolidWorks or an EDA platform).
Software people tend to accept a fuck up on day one and fix it later approach.
Hardware and software people need to work together. Someone with battle scars from both arenas needs to lead as they understand the compromises at both ends and can direct the product.
That's...true, but potentially misleading. What's missing is that a major reason hardware is more reliable is that hardware design can and does punt the parts which are difficult to test into software. Which is a perfectly sensible strategy, but does mean that software wouldn't get as reliable as hardware if software people adopted the same methodology.
Actually yes, well its predecessor on Solaris in about 1999 and they only make products worse. Anything that comes out of Cadence is a turd. They even ruined pspice recently.
They company I worked for ended up writing their own layout/simulation platform after a bout of Cadence and got absorbed into Mentor Graphics.
>'...the behavior of the car six months from now could be radically different because software can reshape the capability of the hardware continuously...'
yeah, some of these days Musk will reprogram it to fly with existing hardware.
I gotta find out which language these guys are using.
In my view, there's no hierarchy of disciplines such that any discipline (including marketing) is assured of being "closer" than any other to understanding the potential customer, the social impact of the product, etc.
I feel that there is something important here. Sufficiently complex hardware benefits from having the flexibility and adaptability of software. Many years ago I did process control programming of machines in a large expensive clean room assembly line. Amazing machines, custom built, handed materials off to the next machine in the line. It turned out that the materials could move around, just a few millimeters, in their plastic carriers. If the carrier didn't settle in quite snuggly and the materials happened to be sitting in just the wrong place, the machines would smash through all of the materials in the carrier because it didn't "see" them while looking/smashing through the carrier. Of course, the mechanical engineers could fix the optical system that looked for materials, but the software guys were able to solve the problem in just a few hours. They had the machines "wiggle" the carrier when it was loaded to make sure the optical system saw any materials present.
After this experience, the mechanical engineers and software engineers worked together to ensure that there was a comprehensive API for the machines so that software could fix, modify, or enhance the machines operation.
28 comments
[ 5.4 ms ] story [ 76.9 ms ] threadThe 'Pencil' product is a good example of the points made in the article. It's a souped-up stylus with some nice features and pretty hardware. But for it to be a sellable and desirable product at $75, it has to tie in well with software. Its app seems to be nice and well-received. They also have a printing service and incorporate social aspects where people share their creations.
It's not uncommon to buy hardware, that on the face of it is very nice, and /would/ be good to use, but getting it to work with your software is just an annoyance. Any company that can convince you going in that the software will be nice to use, is going to have an advantage.
I came upon this while looking for the author. I think it's too bad they don't use bylines. It matters to me whether the person who wrote this is their co-founder, a capitalist, an engineer, etc.
Rather than not using bylines, I'd prefer that they name the author as well as the reviewers and other contributors, much as Paul Graham does.
It is? Am I the one in a bubble here or are the writers of this article in some strange feedback loop?
It's not just these writers...
When's the last time you saw something that wasn't described as beautiful or revolutionary? You know it's bad when Silicon Valley spends an entire scene on the breathless "change the world" superlatives of startup culture [1].
1: http://readwrite.com/2014/05/20/silicon-valley-hbo-episode-7...
Journalists should know better than throwing around weasel phrases like these. Consumer devices like the Pencil are outside the scope of interest, let alone work, of most hardware and embedded software engineers, and it has changed exactly nothing about the field in general, thus hardly making it "revolutionary".
I'm not seeing any attribution at all as far as who put together this post, could have been a summer intern. Hard to believe (because of no attribution) that it's anyone at first round of any significance.
Edit: Just saw carbocations comment re: bylines below.
Are we missing an aspect here? I feel like we are missing something. I was pretty certain hardware had more aspects that make it compelling than design and packaging.
Having worked in this sort of environment, this scares me a bit. Software creeps a LOT more easily than hardware. It's too easy for a software person to ask for "small" upgrades that end up being much more trouble than they're worth: upgrading to faster processors, more capacity memory, etc, it can be a real pain. There has to be a balance, and I'm not anxious to have a software person direct a hardware team again.
He's not talking about operating systems or embedded systems type stuff, right?
But I think he means someone with the same skill set but a traditional CS background. Not that I quite see what that buys you.
Hardware people have to get it right first time and generally have better engineering discipline. They are also supported better by their tools (software tooling is crappy at best compared to say SolidWorks or an EDA platform).
Software people tend to accept a fuck up on day one and fix it later approach.
Hardware and software people need to work together. Someone with battle scars from both arenas needs to lead as they understand the compromises at both ends and can direct the product.
Software isn't eating hardware.
Uh ... have you ever had to use Cadence Virtuoso? If not, consider yourself lucky.
They company I worked for ended up writing their own layout/simulation platform after a bout of Cadence and got absorbed into Mentor Graphics.
yeah, some of these days Musk will reprogram it to fly with existing hardware. I gotta find out which language these guys are using.
After this experience, the mechanical engineers and software engineers worked together to ensure that there was a comprehensive API for the machines so that software could fix, modify, or enhance the machines operation.