I'd really like to be able to customize my phone any way I want, without having to jump through so many hoops because of the lock-downs the manufacturer, carrier, or whoever have put on to attempt to control what I do with it.a) it doesn't work, b) it's really annoying and c) it's my phone, not yours, as is made clear any time it needs repair.
I might feel slightly differently if updates and fixes came out in an expedient fashion, but the lag time is months for updates, if there are any.

And what is it with them crippling features on my phone? Why are parts of the bluetooth stack turned off? Why can't I use wifi tethering? Where's the API for the IR port? Why is it so difficult to put things on an SD card? I know the base OS can handle these things. I know the phone has the capabilities to do them. So why are they deliberately disabled?

Grr...

...but we are NOT DULL!!!

The hardest part of software development is the schedule. Managers and so forth want to have the comfort of knowing when some piece of code is going to be finished. The ugly truth is that it's all guesses. That's why almost any significant software project is usually late. You can't tell ahead of time what is going to bite you. The whole thing may have to be redesigned because of problems you couldn't see at the beginning. The requirements may change. And then there is the debugging, which is really unpredictable.

My theory about why open source code can be better than commercial code is because FOSS is released "when it's done", not on some arbitrary date. The worst kind of scheduling is when you start with the end date and work backwards. Inevitably something (quality, features) gets lost.

The rule for estimating time to write code is this: take your best guess, double it, add one and convert to the next higher units. So if you think you can code something in 3 days, tell them it will take 7 weeks. By the time you flush out the design, write and comment the code, debug it, write the tests, test it, document it and deliver it, you'll be lucky to meet the deadline.

And over-estimating doesn't do you any good either. All it takes is finishing early ONCE, and from then on your estimates are considered "inflated".

"Everything takes longer than you expect -- even when you expect it to take longer than you expect."
        - Ashleigh Ellwood Brilliant

I for one would love to have a smart license plate. Just think of the hacking opportunities!

Jailbreak your license plate and display snarky messages to the other drivers on the road. Change your state to "confusion". Temporarily change your plate number and see how many red light cameras you can trip in a row. "Borrow" your rude neighbor's id and run up their toll bill. Steal a smart plate and hack it so you don't have to pay to register your vehicle. The possibilities are endless.

Any "smart" whatever can and will be hacked. If the incentives are large enough, those hacks will get widely distributed and used. How many incidents of license plate hacking will it take before the police decide it's just an expensive way to enable smart criminals? Not too many, I'd guess.

I've been on both sides of this issue.

As a user, I am often frustrated by the terse, non-informative error messages I get when something goes worng. "Cannot open file" is typical. Which file? In which directory? Why couldn't it be opened? What is the file for? What is supposed to be in it? What part of the program was trying to open the file?
The available on-line help is mostly not helpful in these cases, and FAQ's written by the developers, not the users are useless. Even finding out where the log is kept, much less actually seeing useful information in it? Good luck with that.
How can I as a user file an informative bug report with such scarce information?

So first suggestion: build into your programs meaningful error messages, along with enough information to accurately diagnose the problem. Include options to turn on debug output. When an error is detected, log complete information about it into the log file (the location and format of which should be documented). That way the user has a chance of making a good bug report. And be sure to ask for that information when the bug is filed, with specific directions about how to find and include it. "Append log file" isn't enough, you have to tell them where and how to find the log file.

As a developer, I know the frustration of vague bug reports, that leave out vital information. Simple things like which version of the program was being used, or the configuration settings. You have to make it clear to the reporter that you cannot solve the problem if you don't have enough information. One company I worked for actually had a bug state named "Not Enough Information." The only cure for this is to engage with the end user who reported the bug. And the biggest incentive for that person to engage with you, is the prospect of getting his bug fixed, soon.

So second suggestion: be very reactive to people who report bugs. Get back to them, tell them what's going on, ask questions, and let them test the fix. There is nothing that kills the enthusiasm for bug reporting like going through the process, waiting weeks to get a response, and then be told "Yeah, OK, it'll be fixed in the next version, due out in about 9 months. Thanksbye." And don't underestimate the effect of some user saying to his peers "I reported this bug, and they fixed it for me" to encourage others to report bugs, and make good bug reports.

Of course, there will always be lame bug reports, no matter how you do it. But you can at least encourage good ones, raising the signal to noise ratio.

What is your hardware background? 0 electronics experience? Can wire a bread board? Can Solder? Make your own PCBs?

How much do you want to spend? A couple of paychecks? A couple hundred bucks? Coffee money? Pocket change?

What tools do you have available? Machine shop? 3-D printer? Garage full of power tools? Dremel and a glue gun? Swiss army knife?

What aspect interests you the most? Mechanics? Electronics? Programming? Artistry?

The answers to these questions will determine how you approach the field of robotics. You are getting in at a good time: there are tons of options. Here are a few to get you thinking:

• Pre-assembled robots. Cost from $100 to $100,000. If you don't want to mess with building your own, and want to get straight to the programming aspects you can just buy a robot. They range from things like the Scribbler to something from Willow Garage. The more complex behaviors, actions and programming you want to do, the more it's going to cost you. Best option for a beginner: probably the 3pi from Polulu.
• Robot kits. Cost anywhere from $25 to several thousand. These come with all the parts, but you put it together. Some of them allow customization, some of them are just the one thing. The simplest ones aren't programmable at all: they just have various behaviors. These may be a good way to get started if you need to learn to solder. Examples: mousebot, BOEbot, many many others (google!).
• Robot construction sets. Costs a couple hundred to a few hundred $. If you don't want to get into the electronics, but are interested in mechanics and software, a construction set may work for you. You build your robot out of sets of parts and program it yourself. There's no soldering involved (usually) and you can get right to building something as soon as you open the box. Most notable examples are Mindstorms (Lego) and Vex.
• DIY robot parts. ~$100. Basically, you pick out the parts you want to use, buy and assemble them and program your robot. Requires soldering skills, mechanical inclination and some engineering. For example, an arduino with a motor controller shield and a Tamiya tracked base. Takes a lot of work to get all the parts to work together smoothly. You'll spend a lot of time learning and building.
• Scrap/salvage parts. Very low budget option, but lots of fun. Instead of buying robot parts, you get the parts by salvaging pieces of broken or abandoned toys, electronics and appliances. You may need to buy a microcontroller "brain", but everything else can come from garage sales and thrift stores (or just stuff tossed out by friends, family and neighbors). You could start with a remote-controlled toy as the base, add sensors from things like dead VCRs, flatbed scanners or burglar alarms, and program a microcontroller to give it behaviors.

And of course, you can combine any of those options. Lots of people start out with Mindstorms or a BOEbot and end up building custom parts for them, or using salvaged parts to add on to a pre-built robot like a Roomba.

Two suggestions. First, you will need a support group to talk out problems and ideas. Online is fine, in person is more inspiring. Second, find a good book on what you want to do. There are several mindstorms books, there's several arduino books, and of course there is The Robot Builders Bonanza for the DIYer.

Hope this is helpful,

When I was in grad school the local ACM/IEEE chapter sponsored a programming contest for several local high-schools. This is a fun way to get kids interested in programming and computers in general. Competitive games are a draw. Contact the ACM, IEEE or your closest university and see if they have any contests in your area. If not, maybe they will help YOU host one. Your kids will get to meet students from other schools with the same interests, polish their programming skills and have some fun. Cool prizes help.

Another area with some cool factor to it is robotics. There are FIRST and BEAM leagues all over the place. Check them out. You could spend a few months getting a contest entry together, involving not just programmers, but budding engineers as well. Even without a contest, having a school robot is cool. And they have something tangible to show off to the rest of the school.

I first learned to code by reading the BASIC manual of my Sinclair ZX-81 and laboriously typing out programs one keyword at a time on that little keypad (after assembling it myself). It's amazing what you can do with 1K of RAM.

> Imagine the power of being able to hire a recent college graduate who has been taught how to develop system diagrams,
Using which tool?
> build complex SQL,
For which implementation?
> run log analysis,
On which platform?
> set up a cloud test environment,
On who's cloud stack?
> and write automation scripts.
In which language?

Sure, it would be great to hire someone who could do all that right out of college. But 5 years later, he'd be unemployable because all the specific skills he learned will be obsolete. What is he supposed to do then, go back and get another BS in software QA?

Hire people who know the fundamentals. Choose people who can learn new skills. Train them.
Sure, they won't know the specific tools and environment your particular company uses. But you have to invest in people to get the most out of them. The more highly specialized the job, the more time and money you need to invest in training them. If you concentrate on hiring those who can learn, rather than those who happen to match your particular requirements at the moment, then they can do more than just the one job on the current project. Imagine not having to fire people when the project is over, but instead just move them to something else, even if it requires a different skill set.

> No more crossing your fingers that this eager young face in front of you can really pick up those skills,
> and no more investing so much time and money in training them on the job. We ask no less from
> Technical Writing and Development. Why do we have such different expectations for one of the most
> important functions on the team?"
If you can't tell whether or not the person you are hiring can learn the skills needed to do the job, you need to revise your interview process. Sure, there's no 100% way to tell the gems from the lemons, but you should be able to consistently identify applicants who can do the job.

The fact that development jobs often demand a high degree of specialization is, IMHO, a bug, not a feature.

It's true that even an obsolete smart phone has lots of integrated features that you would be hard pressed to find or add to a micro-controller or tiny PC ( like the PI). There are even a few models that have some primitive IO capability, and lots of them at least have a serial port. So you can, with some effort, get some IO going.

But.

The huge advantage of the PI (and Arduino et al) is the development environment. It's free. It comes with the device. You can roll your own OS, drivers, libraries, programs and interfaces. Or build on the work of others via the community of developers who share their code. In other words, it's an open platform (yeah, yeah, quit nit picking).

A smart phone, on the other hand, is going to be much more difficult to develop for, unless you just want to make apps like everyone else. Many of those neat pieces of highly integrated hardware are not documented, proprietary, and don't give you the source code you need to made modifications. Yes, there's Android, but even there doing low-level things like single pin IO, or even just using the components to their full capabilities, is going to be hard, if not nearly impossible.

So for example if you want to make a robot controller, and you have an old iphone 3 lying around, and compare it to a Ras Pi. The Pi isn't going to have built-in screen, wifi, accelerometers, audio, battery and charger. But the Pi is going to be much easier to use for this application. The number of hoops you'd have to jump through to get the iphone working would make it a much harder prospect to use. By the time you finish getting, or custom making, the connectors/cables/circuits needed to hook it up, you'll have spent as much as a Pi or arduino costs. And that doesn't even address the development environment you'd need. Android phones have it much better off, but it's still not as easy as hooking up and programming a Pi or arduino.

Yes, you have a perfectly good cell phone that could, with some work, be used instead of a Pi. The problem is that the cell phone is going to take a lot more time and effort to hack than the Pi.

I understand the purpose of the question: how to cut costs and still provide services. But there are so many things wrong with the airlines that emulating them, even a little, can only lead to Bad Things.

- prices are seemingly arbitrary, change without notice and nobody feels like they got a good deal.
- they have an adversarial relationship with their (unionized) employees.
- they not only cut unnecessary "luxuries" (food), but started charging extra fees for necessities (luggage).
- dealing with them is usually an exercise in frustration, especially when things go wrong.
- the experience of using their services is usually uncomfortable at best.
- customers are treated like cattle, herded from here to there, penned up in holding areas and lines, and sometimes stored on planes that are not moving.
- customers are at the mercy of uncontrolled factors such as weather, maintenance schedules, work shifts, traffic and the occasional security "emergency".

The two unavoidable facts about airlines are that nobody but the rich enjoys airline travel any more, and that until they figure out just what it costs to get a person from point A to point B, they are not going to be sound financially. We do not want our healthcare to be like this. Pick a different industry to emulate. ANY thing else.

Now, if you want ways to do more healthcare with less cost, that's a different question entirely.

That's so wrong. Imagine you are on the other end of this process, trying to use that code. You'll never be certain which combination of features exist and are supported and which have either been deleted or not implemented. If you have a logically orthogonal set of features, removing or not implementing a random subset just leaves gaping holes where your users are going to be very frustrated on the day they try to do something you thought was of "zero value".

Just -In-Case development prevents problems in the future, which is what good programming does. Just-In-Time development is a shortcut and leads to incomplete code.

Take something he wrote several months ago, that he's not likely to have on the top of his brain. Then ask him to debug, add to, modify or analyze his own code. Or just ask him to give you an explanation of how it works. It might dawn on him that his own code is unreadable and hard to maintain, if you do it right.

I'd also push back on your manager, to make it policy that until this guy gets his code in shape, he is the one who has to maintain it. Bad code is bad even to those who wrote it. Make him work on his own code.