Forgot your password?

Comment: Re:Meh, anything Apple does is considered "cool". (Score 1) 277

by david.emery (#47974405) Attached to: Phablet Reviews: Before and After the iPhone 6

Good points.

I think the ability to run Windows applications was more of a psychological than practical advantage, particularly with the growth of web applications. VirtualPC ran pretty well on PowerPC for limited/occasional use (personal experience). With the exception of some (so-called) Web applications that require Active X controls (the worst offender being the S/MIME PKI module for Exchange WebMail), I haven't had to either BootCamp or VMWare/Parallels for the last 2-3 years.

That being said, many companies (my current employer included) continue to be a Windows-only world, arguing cost efficiencies (and ignoring the investment in keeping Windows secure.) I worked around a problem with their corporate SharePoint by setting the Safari User Agent string to Firefox :-)

Comment: Re:Meh, anything Apple does is considered "cool". (Score 1) 277

by david.emery (#47973725) Attached to: Phablet Reviews: Before and After the iPhone 6

Well, for a long time the PowerPC had some real advantages over x86, particularly for floating point performance. However Motorola lost its edge there, and the big problem with PowerPC chips was their power consumption, making laptop design and battery life much more difficult.

But that kind of sophistication is beyond most of the tech press, and I suspect beyond a lot of the people here who emote their hate for specific brands. (I admit to a very strong bias against Microsoft, so include myself in that set at least to some degree.)

Comment: It's not just the money! (Score 1) 261

by david.emery (#47968919) Attached to: Mark Zuckerberg Throws Pal Joe Green Under the Tech Immigration Bus

What keeps someone at a job that might pay less than he could get for hopping?

1. Individual job satisfaction? (Yeah, laugh! That's a big part of the industry's problem! Proof: :-)
2. Co-workers, the company, the location
3. Benefits and incentives to remain

I guess as a Boomer, these might be old fart attitudes. But at least for many of the people I've worked with, they're significant considerations. Salary alone has rarely been the primary reason engineers change jobs. That's well-documented, here's one reference that tries to summarize the research:

Comment: Re:Mark Zuckerberg is a liar. (Score 4, Informative) 261

by david.emery (#47960623) Attached to: Mark Zuckerberg Throws Pal Joe Green Under the Tech Immigration Bus

Mod parent up, please. In particular, the comment about industry being unwilling to invest in training is spot-on. I'm old enough to remember when it wasn't that way. (Example, how many remember getting training in Ada if you worked in the defense industry? Regardless of what you think of the language, 25-30 years ago that industry was willing to invest in its "human capital." )


Comment: Re: Technical People (Score 1) 194

by david.emery (#47685857) Attached to: The Billion-Dollar Website

I don't know if anyone associated with this project adopted anything they called "agile" or not. What I was saying was that I have zero confidence in "agile" as I've seen it either defined or applied, for products that are (a) large, (b) complex and/or (c) have substantial infrastructure (versus user-facing) functionality. This project had at least (a) large, and probably (c) substantial infrastructure requirements (that might have been solvable by judicious selection of the right commercial products.)

It should be a feature that a waterfall project could be seen to fail early, but for the PM whose career is built on continuing the project past his tenure, there's no advantage to her/him to fail quickly.

Comment: Re:F-35 Joint Strike Fighter (Score 1) 194

by david.emery (#47678285) Attached to: The Billion-Dollar Website

...Witness the F-35 Joint Strike Fighter, an aircraft nobody needs, trying to fill too many roles, and was supposed to save our armed services money by having one plane replace many planes...

I'm not defending the F-35 (I'm a huge A-10 fan, and 2 F-35s would fund the whole A-10 fleet), but your comment here is self-contradictory. Either we don't need it, OR it's trying to fill too many missions (that do need to be done.)

I think it's the latter, and that's not just requirements creep, but a different phenomenon that is something like "requirements conbinatorics", where too many requirements get loaded onto a system (health care or weapon) and the result is either (a) not buildable as a violation of math or physics or (b) massively complex and therefore massively expensive.

It's a combination of no discipline on the part of the users/managers who develop the specifications or needs statement, and the problem that the number of major system starts (whether DoD or commercial) is limited, so each user/stakeholder needs to get -His/Her Requirement- in place on this system, because they won't have a chance for another 10 years to get that requirement into their/their user's hands.


Comment: Re:Technical People (Score 5, Insightful) 194

by david.emery (#47676953) Attached to: The Billion-Dollar Website

PLEASE Mod Parent up! I've been working on large government funded systems (defense and commercial) for 35+ years, and in my view programs are screwed from the beginning by overly-aggressive schedules for the up-front work. When the incomplete/absent requirements/architecture/design results in coding, or more often test and integration delays, they'll find more money and time. By then, it's too late.

Back when we had explicit waterfall milestones (requirements review, preliminary design review, etc), we could tell at PDR a program would fail as a result of incomplete or even incorrect requirements & architecture.

Unfortunately, the adoption of "Agile" in these organizations has reinforced the culture of "We don't need no stinking requirements! We can draw an architecture on a whiteboard in an afternoon", resulting in systems where you really can't say anything intelligent about how long it will take to complete them, because you have no fscking idea what "complete" actually is.

And this -should not be a revelation-, at least to anyone who has read "Mythical Man-Month," which will be 40 years old next year.

Thank God I'm getting ready to retire.

Comment: Re:User docs, or developer/maintainer docs? (Score 1) 199

by david.emery (#47672825) Attached to: Ask Slashdot: Should You Invest In Documentation, Or UX?

How often do you need to do that? As an "end user" when things work correctly, I'd assert it's infrequently.

But when trying to debug a problem, I agree this is frustrating, and the worst of all is "You are unable to log in at this time. A system error has occurred." and even if you know how to bring up the Console (/Applications/Utilities/ to look at the error logs, they're not particularly helpful.

So I'll put some words into your mouth and say, "It's important to have documentation available to support troubleshooting or 'power users', but the goal should be that 95% of the time you shouldn't need to RTFM to use the system." Agree?

And access to documentation is separable from existence of documentation. Most of the time, when I'm connected, using a search engine to find this kind of information doesn't bother me. But when disconnected (e.g. sitting on an airplane), not having the information local can be very frustrating.

Comment: User docs, or developer/maintainer docs? (Score 1) 199

by david.emery (#47672259) Attached to: Ask Slashdot: Should You Invest In Documentation, Or UX?

From a user doc perspective, Apple Mac OS X is a great example of what you can do with a minimum of user documentation, but with very mature and fully enforced user interface guidelines. In fairness, someone new to the platform does need some hand-holding, either training (including over-the-shoulder help from a family member :-) or a good book (I'm partial to the Pogue "Missing Manual" series.)

From a developer doc perspective, if you expect to maintain the software, some amount of documentation, that should capture (1) interfaces; (2) design intent; (3) full build/reconstruction directions (including configuration data, etc) is essential. And "Agile" that ignores these documentation/sustainment issues is just an excuse for write-only coding.

Faith may be defined briefly as an illogical belief in the occurence of the improbable. - H. L. Mencken