For novel ideas about building embedded systems (both hardware and firmware), join the 35,000 engineers who subscribe to The Embedded Muse, a free biweekly newsletter. The Muse has no hype and no vendor PR. Click here to subscribe.
Writing software is easy. Software engineering, though, is hard.
The push for more STEM education is fantastic. And awful.
Virtually every reader of this column is well-educated and knows a lot about math, science and engineering. But we're not representative of the rest of the world. The average Joe just doesn't understand most of the concepts we grapple with every day. One of the many things I wish for this world is for humanity to have decent schooling in what really makes the world tick. Absent such grounding how can one make good decisions about out highly technological world? When emotion substitutes for analysis how does one see through a politician's deceit? It's easy to lie with statistics and to bias graphs to greatly distort the truth; a little understanding of these subjects can make the scales fall from one's eyes.
But there's the flip side to this which we're seeing with the maker movement and getting K-12 kids into coding. While I applaud any passion and hobby, and love to see youngsters fired up about technology, there's a dark side that is becoming more apparent. Programming is easy, and it doesn't take long before a nascent developer discovers just how easy it can be. Want to make the red LED blink? Piece of cake! Build a simple robot? Just glue in some Raspberry Pis and crank a bit of code.
Pretty soon we find that these hobbyists, who will mostly go on to never program a computer in adult life, have an ingrained sense from their vast (in their minds) experience that coding is, well, easy.
What's hard is software engineering – designing code that works even at boundary conditions. That is reuseable. Maintainable. That works, when the user unexpectedly pushes all of the buttons at the same time.
Often getting the first 90% of a project is pretty straightforward. The real skill comes in making that last 10% work, and work well. Toss a framework together and in no time a lot of stuff functions. But to make a real system that can be deployed to thousands of customers demands much more skill. And time-consuming hard work.
So we hear statements like "it's only a software change." Or "what's the big deal – it's only code?" And worse "how long can it possibly take?" A number of readers have been complaining about customers, or worse, bosses, who proudly sport a bit of experience with making an Arduino thing go, being puzzled why it takes so long to build a real product.
They say a little knowledge is a dangerous thing. I disagree. A little knowledge is dangerous only when coupled with hubris and a lack of humility. A little knowledge can be great; in the case of software it can give a non-practitioner an appreciation for the complexity of systems. And a little knowledge about a lot of things can make one wiser.
But I do think we're starting to see a shift where that little bit of knowledge of programming warps judgement.
Not having the time I no longer mentor young folks who want to play with this technology. If I did, though, I'd show them a listing of a real product. A 100K line-of-code product is not very big by today's standards. But printed it would fill four reams of paper. The code for the Apollo Guidance Computer (http://authors.library.caltech.edu/5456/1/hrst.mit.edu/hrs/apollo/public/archive/1701.pdf) is 1700 pages long. I might use a tool that shows the relationships of classes on a real product to demonstrate just how complex things can be.
One can see the difference between an Estes rocket and the Saturn V at a glance. It's much more difficult to understand how a toy robot's code pales compared to what is found in most real products.
And, as I was writing this an email arrived from Nuts & Volts magazine posing the question "will the art of circuit design fade because of platforms like Arduino?" (http://www.nutsvolts.com/newsletters/newsletter-46?utm_source=Newsletter+%2346&utm_campaign=Newsletter+%2346&utm_medium=email).
I vote a resounding No!
Published May, 2016