What's actually documented is that big software projects have a high probability of failure. The level of detail in their requirements is, like the failure rate, a consequence of size.

Agile seems mostly like it is meant to let developers write more prototypes, with the expectation of throwing them away, in the name of "responding to change" -- particularly when, as often as not, the change is due to defects in the development process rather than any underlying technical or business reason. Instead of planning, there's a frivolous focus on making things that look good or check some box but don't necessarily have a solid architecture.

You are basically just saying that agile is more *fr*agile than waterfall -- given two teams of equal "discipline" and skill, you're likely to have something closer to the original intention with waterfall than with agile, because (in your words) agile requires more discipline to work well. Also, you're spouting nonsense when you say that the point of daily meetings is to free managers from micro-managing; if they wanted to stop micro-managing, they would not have a meeting each day where the explicit purpose is to point fingers.

Waterfall doesn't need a long QA/QC cycle if you put thought into design validation and verification beforehand, and spend some time developing tests in parallel with developing code. Putting off test planning and preparation will hose you whether you use waterfall or agile or whatever else.

So Snowden is going to be pardoned by Obama now, right?

If by "pardoned", you mean "Drone Strike", then yes, Snowden will be "pardoned".

Out of four garden lamps I put in about five years ago, only one functions and that very poorly.

The LED lights themselves may still work, but the solar collectors on top get clouded or dirty (or both) and stop providing power.

The recommended break point is as it is with any language - whatever is most readable.

Sometimes that might be the return value being on the next line.

Sometimes it might be each parameter on it's own line.

I myself prefer to either have the whole thing on one line, or everything broken out per line if that will not fit. But I'll admit I let some longer methods sometimes wrap to two lines on the display (even though it's really one long line).

The second is for the return value, yes.

Although you can absolutely name the return values something different, I just had in mind some optional transformative thing where you could use it or not and treat the data tuple the same way.

You sound a lot like me in 1998.

I doubt this will happen any time soon, but it really is going to be the way to go. The same model worked great for long-distance service.

I've done Objective-C since before the release of the iOS App Store, and Swift almost full time since Apple released it last year...

Some of the things you mention beginners do not have to use (generics, and struts for example). To keep things simple to start with, they could just use classes instead.

I will agree that optionals might be a bit rough on the beginner - but perhaps not as starting from nothing, the concept of a bucket that holds a value instead of just using the value directly, would not be so foreign...

You also mention different ways to specify params, and shortcuts - but I see those as a major plus. You can just pick a level of detail that makes sense to you and work with that, until you feel comfortable with reducing further the syntax you use.

I think the function syntax is one of the cleanest and easiest styles to understand... I believe a few other languages have this form also, but in swift you just say something like "a function named takes in these params, and outputs those params" So it looks like:

func myFunc (a:String, b:Int) -> (a:String, b:Int)

it's just so balanced that you can have any number of things in or out.

There are a few things I think make Objective-C less approachable.

The separate header files, and the heavy modern use of private categories to define most internal properties confuse people as to where they need to define things.

Simply more verbose syntax all over. I like verbosity myself, I love named parameters... you get that with Swift though with a lot fewer characters typing.

Part of that extra syntax in ObjC is the shorthand to make arrays like @[] and @(value) to make NSNumbers... but in Swift Integer is treated the same as String, both are first class objects that you can do things with so it's more consistent. That in particular is I think a large benefit for newcomers.

It was not obvious from the summary what the heck was meant by "embedded programming". In TFA, in addition to the quoted paragraph, the word "embedded" is also used in "The ability to defer loading in a mobile app or an embedded app on Apple Watch will improve the perceived performance to the user.", "Swift provides the development community a direct way to influence a language that will be used to create apps, embedded systems (if Apple ever licenses an embedded framework and chip for third parties), and devices like the Apple Watch.", and "Ultimately, Swift is a more approachable full-featured programming language that will allow developers to not only build apps but also target embedded systems like the new lower-power Apple Watch for many years to come."

So if he's referring to the Apple Watch, maybe. If he's not, I'm not sure what the heck he's referring to; "embedded systems (if Apple ever licenses an embedded framework and chip for third parties)" sounds like hand-waving. Is he expecting Apple to be pushing Darwin into the *ahem* Internet of Things or some such?

More to the point, who outside Apple develops embedded software for an Apple platform?

Wrapping it in foil means it won't function as anything.

But it also means the work application will not record any downtime for the app running.

If you are "on call" then you are technically working, so that phone needs to be 100% functional and they have the right to track it.

True enough (I totally agree the company as the right to track their own equipment) but if a boss said something creepy like "I can see how fast you are driving" in the bag it would go when I was driving anywhere and I'd just blame bad cell reception on the dropoff... I could pull it out every 15 min or so to see if there were any messages. But it would technically be dereliction of being on-duty...

It is important to note, however, that putting the phone in the Faraday bag emulated loss of signal, instead of loss of power,

I was mulling that over after I posted, but after some thought I think that ends up being OK also as it's easy enough to claim your car blocks cellular signals really well or just were in a bad area... at any rate the app wouldn't show it had been shut down which I think would be the main trigger they would get onto you about.

That's a great point but it does seem like a company should have the right to enable GPS tracking for company assets. Perhaps a good compromise would be that you could indicate when you were off-work to avoid tracking, but if required the device could be signaled to turn back on tracking.

I personally would probably get one of those signal shielding bags and drop it in there when I wasn't to be on-call. Then you could carry it with you even. Then it also appears just as if it lost power for a while, so it would be hard to get in trouble over it...

Reading is one thing, browsing quite another...

Also worth considering - the Pebble display is 30x50mm on the old Pebble, just 20.1x23.44mm on the Time.

The Apple Watch 38mm has a 21.2x26.5mm display, the 42mm version has 2.3x30.8mm...

So the old Pebble is substantially larger than any of the new models, and somewhat easier to read as a result.

I have a Pebble Time on order, it will be interesting to compare... but I just can't see browsing on any of them at all useful beyond something like an RSS feed worth of info.

and frankly you can always bring the watch closer to your face.

You have an unpleasant surprise in store for you as you age. Minimum close focus gets further back, to where you really cannot just bring the tiny screen closer...

Go into an Apple Store, reading the web on that display is just not practical.