Hacker Newsnew | past | comments | ask | show | jobs | submit | roedog88's commentslogin

I can see the ease of use argument, and that Apple products certainly do well at that. But, thinking on a longer time line, isn't that target audience shrinking. What is the life expectancy of the pre-computer literate population? How big is this audience now? I'm just asking. I have no idea.

On the other hand, a much larger audience would be the vast unwashed masses in the third world who use cell phones to access the internet. The sales volumes are higher, while the price point is lower... I wonder if Apple would go there, or would they leave that market to others.


It is a good example of using a little humor to help defuse a user's frustration.


Aside from the built in stuff like email, calendar, contacts and maps with the traffic view I use the following every day: shuffle as my to do list, and StreamFurious (free version) for streaming audio.

The TripIt and Yelp apps were useful on my recent vacation.


I don't think you overreacted. I would find it difficult to trust a consultant who pulled a bait-and-switch on me.

An alternative to firing them might have been to re-negotiate their fees based on the less known designer, or to defer payment until the job was finished to your satisfaction.

But given the breach of trust, I don't think canceling the contract was out of line. Especially if staying with them would require extra oversight and heartburn.


He didn't hire a consultant. He hired a consulting company. BIG difference.


It shouldn't be. Plenty of up-and-up companies subcontract, but they tell you that sooner than the day the project kicks off.


Adding more weight to your point, I read that McDonald's divested their stake in the Chipotle chain, giving the reason that they wanted to focus on increasing revenue at their own restaurants.


What about certifying the software that Joe the developer creates, rather than Joe the developer? This is the approach the FAA takes with DO178B for the flight software on the jet planes that we ride.

These are very large projects, using hundreds of developers. The quality of the team members varies. Half are below average for the population at large.

Adding certification on top of this doesn't change the fact that half the developers will be below average. The projects are too large.


Do you mean half are below the median?

(Actually, if the rockstar programmer stories are true, then it's way more than half of the programmers that will be below average. Which strengthens your point in a way.)


> What about certifying the software that Joe the developer creates, rather than Joe the developer?

There's a simple reason why - it costs x to certify 1 developer, and y to certify a piece of software.

For most software, "y" is still too expensive to offset the potential damage caused by software failure (compared to a jetliner, where the potential cost is huge).

A programmer may create hundreds or even thousands of pieces of software during a career. Average x over that number of projects, and it's negligible. Multiply that number by y, and you have an enormous figure.

Also, the cost of certifying a piece of software to provide any kind of assurances of quality is time consuming and expensive. Compare this to a certification that shows that anyone who wants to claim to be a "software engineer" actually knows the first thing about software engineering, and is at least capable of producing software in a systematic way.

It's just like we license drivers once and assume that that basic level of competency will ensure "quality driving" on a variety of road types. We don't certify each driver for each road individually.


The problem is that we need to guess at what x and y are for particular levels of confidence. We can't use real-world numbers, because none of the existing developer certification programs grant sufficient confidence.

You can guess one way -- as you clearly do -- and it looks like the up-front developer certification cost dwarfs the software certification cost when amortized over all projects. This might remain true even when multiple developers are considered.

You can also guess another way -- as I do -- and it looks like the up-front and recurring costs to properly certify a developer and maintain that certification would be very large. It could be so large that, even when amortized across many projects, it's still comparable to (or even more costly than) certifying the individual projects.


I think the idea that certifying developers and not certifying safety critical software is a non starter. On safety critical projects, certification will add to existing and onerous validation and verification costs.

The process requirements on these projects (DO-178B) call for an organization to institute a systematic way of developing software across the project that everyone on the project follows. An additional certification for each individual is not necessary. Either they can follow the process or they are reassigned.


You appear to have inferred incorrectly that I am talking about safety critical work.

I am not. I'm talking about anything that people are expected to spend money on. The certification passes to the software, and then users are capable of making slightly more informed decisions.

I'm a formal methods geek, so I generally advocate theorem provers for stuff which is actually safety critical. To me, certification of developers would just be a way of lifting the general quality of the non-safety-critical stuff that still has the opportunity to cost people lots of time and money.

Think about viruses, for example. People complain about viruses causing millions of dollars of damage.

The virus didn't actually do any damage. The shonky programming that allowed the virus to propagate in the first place did.

And that's why certification is important. Hopefully it would at least ensure that people writing software are familiar with the issues that can affect software quality.


Working in technical support my colleagues and I all knew who were good customers, and who were bad customers. Our manager knew too. He would back us up with raises and options. Making unhappy customers happy is not an easy job (especially given our bug list at the time).

Years later, I still remember one who called almost once a week with a new issue he had dug up. Admitting he was right and promising to fix the bugs did not make him happy, or make him go away. We all had a theory that he was calling so often because he was lonely and wanted someone to talk with.

Taking a longer view, I think being a nasty customer is it's own punishment. These people are miserable or sad, and lording over a service or hospitality worker gives them only a pyrrhic victory. The server or tech support moves on with their life. But the asshole is still an asshole.


I moved to Los Angeles from Mt. View several years ago.

The startup and technology scene is less visible than other industries here, notably entertainment and aerospace. I don't feel the buzz like I did back in the bay area.

That said, it was a very good move for me. I was happy to leave behind my bay area snob attitude upon finding that there were many smart people who do interesting things in Los Angeles. It's a bigger city than just the one we see in the celebrity/entertainment news.

Also, my dating life improved greatly compared to the bay area.


If you (or anyone else here) wants to get more plugged into the tech community here, email me. mail at awarner.com


The article talks about how many embedded projects use C and the need for new developers. I have two thoughts about why embedded developers choose C.

One reason for this choice that I've observed is the very conservative mindset in those developing safety critical software. I think this is understandable given potentially fatal consequences for errors. The approach to safety is somewhat brute-force, write the code to strict guidelines, then test, test, and test. Changing a language or compiler would require extensive re-testing, introduce unknown risks, and the development of new guidelines.

The other big driver for embedded software is unit cost. The logic goes this way. Saving a dollar on a part used in 2 million unit saves $2M in costs. A cheaper part is selected if the part cost savings is less than the extra engineering costs needed to squeeze the functions into a smaller memory and slower chip. C, and C++ can be quite lean, while perhaps taking longer to develop than another language.


I've been using the hipster pda. http://www.43folders.com/2004/09/03/introducing-the-hipster-... for a few years. It works well for me. I find that maintenance takes very little effort any more.


Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: