Please create an account to participate in the Slashdot moderation system


Forgot your password?
Compare cell phone plans using Wirefly's innovative plan comparison tool ×

Comment Re:Stagnant? (Score 1) 108

I was just looking at this article which points out that Apple's R&D has gone up many times over since Job's passed on...

The thing is, that's usually a bad sign. It means that your development teams are growing very quickly, which has two effects:

  • The median age/experience level drops precipitously, resulting in poorer output quality.
  • The amount of effort required to maintain the products designed by more people grows by the square of the number of people involved.

Eventually you reach a point where every additional person makes the product worse or more delayed, rather than better or faster. These days, I keep getting the feeling that Apple passed that point a while back, and they just haven't noticed yet. This is one reason why innovative ideas almost invariably come from small companies, not big ones.

The other reason is that the larger Apple grows, the harder it will be to innovate, because the breakage caused by doing so will become an ever bigger problem as the code base increases in size. At some point, it will be necessary for Apple to start over from scratch—probably by buying a company that creates some innovative alternative. At that point, it will have fully become Microsoft or IBM. And that's okay. Eventually, somebody else will come along and become the next Apple. It's the circle of life.

Comment Re:Sterilized long ago (Score 2) 168

In our solar system only moons are tidally locked to planets, but no planets to stars.

Mercury comes pretty close with its 3:2 spin-orbit resonance. It spins 3 times for every 2 orbits. That's close enough to being tidally locked that the difference is mostly moot from a "cooked on one side" perspective.

Comment Re:There is no "removing" of anything... (Score 3, Interesting) 366

If the new phone doesn't have a headphone jack, it'll be all over the Internet. There will be almost no way to avoid knowing that the iPhone 7 doesn't have a headphone jack.

That's not where the user impact comes in. Most people don't use headphones constantly. They use them occasionally. And they will think to themselves, "That's not a big deal." Then, at some point in the distant future:

  • They're at a friend's house and want to play some song. Their friend has an Android phone, and a stereo with only an 1/8" plug.
  • They're out somewhere and think, "I'd like to listen to some music while I walk from A to B" and then realize that their Bluetooth earbuds aren't charged.
  • The stewardess tells them that they can't use wireless headsets (that's a per-airline policy decision) and offers to sell them a headset for $3, but oops, no adapter.

And so on. And suddenly, what seemed like it didn't matter suddenly matters, and you have a pissed off customer.

Comment Re:Fix Apple (Score 1) 366

Apple will do no fixes of anything until it learns its lesson with very bad iPhone 7 sales because of the removal of the 3.5mm audio jack.

What would be worse for Apple would be if they don't lose sales, because there's definitely a non-negligible percentage of their customers who will be negatively impacted significantly by removal of the headphone jack, and if those folks buy the phone anyway, then they're going to end up with a bad impression of Apple products, and Apple will lose them as customers. In the long run, Apple should hope that they lose those sales, because at least they'll have a chance to make up those sales by releasing a future generation that isn't missing critical features.

The ultimate destruction of Apple as a brand of amazing hardware will come if they ship a device without a headphone jack and 30% of their users don't realize how much they'll miss the headphone jack, buy the phone anyway, and then start trash-talking their new iPhone on social media before switching (permanently) to Android. If Apple ships this product, I may start doing covered calls on my Apple stock to limit my losses. As a user, this is just a big annoyance, and I'm hopeful that they'll pull their heads out of their a**es before I'm due for a new phone. But as an investor, this is absolutely terrifying, oddly reminiscent of the period where a certain Pepsi exec was running the show.

Comment Re:Cat got my tongue (subjects are dumb) (Score 1) 38

Question 1: Who the hell reuses passwords, and why? Anyone left not using password managers?

Statistically, almost everyone:

  • Anyone who created at least one account more than a few years ago and has continued using it without changing his/her password
  • Anyone who is using a site that doesn't support the browser's build-in password manager (usually by not showing a username field)

There are probably others, but most users have at least a few sites that use shared passwords, and most of them are the fault of the people who designed the websites.

Comment Re:Sigh. Another Vulnerable PHP Service (Score 1) 68

The thing is, lack of upgrades usually indicates a design problem. For services like this, the software should be distributed using git so that local changes can be merged sanely. Instead, most of these bulletin boards involve moving aside the existing installation, extracting a tarball, and running some sort of installer script that does who-knows-what. So upgrading can be nightmarish for sites that involve any sort of customization.

Also, this sort of software should be designed in such a way that it never makes backwards-incompatible changes to data structures, at least for a reasonable period of time (say a year or two). It should be possible to clone your installation to a new directory, apply the patches to the new version, start it up, and let it add additional database fields, etc. as needed, but the new version should be tolerant of partial data created by the old version (and should upgrade it on the fly), and should create data in such a way that the old version can still read it. This ensures that you can test the migration to a new version without having to set up a full clone of your entire infrastructure, with the ability to roll back if it breaks something.

And ideally, a built-in upgrade scheme should be designed into the software. For example, it could have a script that clones itself into a directory beside the original and does a "git pull" in that subdirectory. After you fix any conflicts, it should let you access the new version by symlinking the new version into a subdirectory in the original version's tree. When you're satisfied, it should provide a one-button command that atomically deploys the new version by swapping out the symlink that currently points to the old version with a symlink that points to the new version.

Oh, and it should check for updates automatically and email the admin every time there's an update. And it should allow you to auto-upgrade (with automatic email notification if the upgrade fails because of git conflicts) if you configure it to do so. And it should also have an intermediate mode that always keeps the latest version ready to preview but doesn't enable the upgrade, for folks who want to verify the updates manually, but still want to be ready to quickly install security updates when they find out about an exploit.

With such a design, these systems would stay up-to-date much more consistently.

Comment Re:What happens at crunch time? (Score 1) 109

I understand the point of core hours perfectly. I don't understand the point of them being dictated from the top of the organization down. Realistically, until you have five people in the meeting, there's no chance of not being able to find a day when everyone can be there, and you shouldn't typically have that many people in a meeting unless it is either a team meeting or a broad cross-functional group meeting. Both of these should be repeating events. Decisions about which day to pick for team meetings should be determined by the team based on what works best for everyone, and everyone should agree upon a particular day each week when they all agree to be there. Broad cross-functional meetings don't require a specific person from any given team, so the team or the team's manager should decide who is responsible for representing their team in those meetings based on who will be there on that day of the week.

Workers should be willing to occasionally take brief phone calls on their days off if they need to answer an urgent question about something. More significantly, there should very rarely be anything so urgent that it can't wait a day if it happens to be that employee's day off. If you are finding that such urgent blockers come up frequently, either:

  • The work of certain employees is too tightly coupled (which means it should have been done by one employee over a longer period of time, and schedules are likely unrealistic).
  • There isn't enough intra-team communication so that other folks understand what each other are doing at a high level.
  • There aren't enough people working on an important piece of the puzzle, resulting in things that only one person understands.

Any of these things indicates a failure of management that should be corrected ASAP, and not just because it makes flex-time easier. It is also the only real way to protect against the "hit by a bus" problem, the "won the lottery" problem, etc.

Comment Re:Meh (Score 1) 179

Singletons are a good default design pattern to use if you need something that should typically be shared across lots of pieces of code (e.g. a cache). With that said, my general policy is that you generally shouldn't design classes that are limited to use as a singleton. You should always provide the ability to allocate additional instances unless it is impossible to safely have more than one instance for some reason (and you must justify why this is the case).

Comment Re:Not convinced (Score 1) 109

Then they'll quietly drop this perk for new hires...

Legally, they can't do that. For ACA purposes, for example, if someone works 30 hours or more, they're considered full-time employees legally, and you have to pay for their health insurance. And you cannot legally limit 401(k) matching unless the employee works fewer than 1,000 hours per year (19.23 hours per week).

At 30 hours per week, about the only thing they have any flexibility on is the number of vacation days. And nobody is going to join a company that makes them work 3/4 time with no vacations, so if they attempted that, it would quickly become a self-correcting problem.

Comment Re:"Well, of COURSE they'd like that." (Score 1) 109

It is a lot easier if you make it a per-team plan rather than a per-employee plan. Hire people into specific parts of the company with the understanding that those entire teams will work the alternative schedule. If someone wants to work a normal schedule, put that person on a different team that works a normal schedule.

Slashdot Top Deals

"Truth never comes into the world but like a bastard, to the ignominy of him that brought her birth." -- Milton