HyperCard combined three aspects: (1) A easy-to-assemble set of graphical/user interface components; (2) a simple (simplistic) database; (3) a quirky programming language.

Possibly VB with Access provides a similar set of functions.

We should be able to produce something that allows end users to do some development for themselves, while acknowledging this is not a production-quality tool, but no matter what, people will take prototyping systems and try to deploy them to production usage.

I've used it for several different things, including catalog/library "decks", user interface mock-up with a bit of back-end semantics (for a system configuration function, to understand user requirements and usage models), and a potential front-end controller to a very simple 'robot'.

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 :-)

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.)

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: http://thedailywtf.com/ :-)
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: http://blogs.hbr.org/2013/04/d...

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." )

dave

Arguably the Poles have known this since they routinely get invaded from both East and West, and in 1939, from both sides simultaneously...

Hurghada - odprawa paszportowa:
-Nationality?
--Russian
-Occupation?
--No, just visiting.

(from a friend in Poland.)

So I call "bullshit" on those claims. It shouldn't be that hard to test on iOS, and if you can find a Windows Phone, it should be easy to test there, too.

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.

Kool-aid...

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.

dave

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. https://en.wikipedia.org/wiki/...

Thank God I'm getting ready to retire.

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/Console.app) 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.

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.

Would anyone here doubt that a Mac Pro is a 'high end machine,' or that the posted specs for system noise don't make that "quiet?

One difference is obvious, you can go see, listen to, and buy a Mac Pro right now.