Car crash, computer crash... what's the difference?

Lean IT is about delivering quickly and cheaply, Agile about delivering high value compared to the costs, devops about taking responsibility for your work. If you start with one of these methods and take it to its logical conclusions, you'll end up with something that isn't very far from the others.

The idea that you can start with a mishmash of all three is probably not productive - there's a kind of learning journey you have to go through - but I'm willing to change my mind if somebody delivers proof.

What do you mean, "not enough memory"? 640 kB ought to be enough for anybody.

You don't want to make it even more cumbersome to change the code, as it sounds like you are already struggling with the 10 Mloc codebase. So forget about having humans "approve" the changes.

What you want to do is make it easy to submit good code and difficult to submit bad code. This means that you will need the capability to quickly assess the proposed patch, for some definition of "good" and "bad". Computers are fairly good at this. In other words: test-first development, with automated testing on several levels.

Bug comes in, you write an automated user acceptance test that FAILS. Then you try to find and fix the bug. When the newly added test passes, the bug is by definition fixed. Add a couple of unit/module tests, and a couple of UATs for good measure. Rinse and repeat.

There's plenty of tools for this. All major platforms have the capability for programmatic reflection. Use e.g. Cucumber for the acceptance tests, and the relevant unit test framework for module/unit tests. In addition to the functional tests, try static analysis.

Or about how they kept the world's population hostage with Clippy the Paperclip? I mean, when they heard Clippy was going to be removed from the next version of Office, around 350 million people upgraded straight away.

Or is it about how Microsoft is paying 500 million (USD, EUR, whatever) in fines every couple of years, in order to keep doing business as a software monopoly? That is probably the most brilliant crime by the Microsoft Digital Crimes Unit ever!

Learn to juggle! Seriously! I learned to juggle with three balls during a particularly stressful software project some 15 years ago. Nowadays when I feel blocked, I pick up three round objects and go somewhere else to juggle for a while. I haven't progressed beyond three objects but then again I'm not doing it for the fame and the money. :)

Juggling activates other parts of your brain than you (as a software engineer or IT guy) normally use. You can juggle as long as you like, ten seconds or ten minutes. The materials (e.g. stress balls, tennis balls, apples, oranges, whatever) are cheap and small. Does you good to get up out of that chair and stop staring at the monitor for a moment. If someone asks what you are doing, say that you're taking a minute to think about some small creative problem e.g. structuring the next three paragraphs you are writing, or looking for alternative ways to implement some feature. The learning threshold is admittedly steep, but the Internet should be full of tutorial videos by now. Also, juggling is a nice party trick, kids especially are fascinated.

Think of it as an off-screen microhobby...

--Bud

> It's a fact that OS/UI developers seem to believe that [something]

A seeming fact, then? Or an opinion?

> we generally need increasingly large displays [read: pixel counts] in order to restore focus on the application and to minimize the impact on screen and usability which the OS/UI claims.

Not at all. We generally need more and better modes of interacting with our phones and the apps running on them. You see, there is an upper limit to the physical size of a phone: it needs to fit into your pocket. And there is also a lower limit on the size of an UI element: your fingertip. Increasing the resolution only enables the device to show sharper text and more detailed pictures.

There are many "novel" or "trendy" interaction methods like swiping, pinching, multi-finger dragging, gestures and so on, that are not yet commonly used in mobile phones or mobile apps. Properly used, they can free up screen estate. For example, an app that supports pinching doesn't need on-screen zoom buttons.

Many if not all of these interaction methods can profitably be reserved for the system UI. If you replace the most common system UI functions with gestures, you can remove the status and system bars and free up the top and bottom part of the screen. The Android 2.x swipe-from-the-top action is a good example, as it allows the top status bar to become very narrow. However there is no reason to stop there.

> Android 2.x seeks to minimize the UI impact and it does a nice job of it. A minimal row of buttons

No it doesn't. The iPhone minimizes the UI impact by simply NOT having that row of buttons. The Nokia N9 uses swiping creatively to do away with even the physical buttons and touch areas that you find on Androids, iPhones and Windows Phones.

All of these phones, even the N9, still have a slim status area at the top. Jolla's Sailfish aims to do away with even that.

> What Ubuntu-phone is proposing is unintuitive and seeks to infringe on how an app can live on a device. Do. Not. Want.

So you say. Now, in the real world, what Unbuntu proposes is really going to make some if not all of the system areas redundant and give apps more control over the screen real estate.

What is intuitive, by the way? In this context something is intuitive if you can pick it up and use it without training. It's not even remotely synonymous with "whatever I've gotten used to", as you seem to imply.

Have you actually tried a swipe UI? I have been using a swipe-based phone (the aforementioned N9) for a long time now, and it just works. You can either take my word for it, or go and try it yourself before commenting further.

--Bud

"Remember that all models are wrong; the practical question is how wrong do they have to be to not be useful." (George E.P. Box and Norman R. Draper, Empirical Model-Building and Response Surfaces (1987), p. 74)

"One of the most insidious and nefarious properties of scientific models is their tendency to take over, and sometimes supplant, reality." (Erwin Chargaff)

I think that says it all, really.

--Bud

One wonders if they'll be turned off by Celine Dion music — a new type of shark repellent perhaps?

Oh yes, the "Celine Dion effect" is well known. For example, playing My Heart Will Go On in railway stations late at night will magically keep the stations empty from pickpockets, rapists and other miscreants and indeed any sentient beings except cockroaches. The high notes will first melt your earwax and then your brain. Cockroaches merely lose their orientation and walk into walls.

I don't see any reason why it wouldn't work underwater too. Unless of course the sharks fight back with lasers.

--Bud

> stupid_is writes with news that Duke Nukem Forever has now gotten a firm US release date: May 3rd.

Yes, but which firm?

> It will release worldwide three days later.

Release what?

I thought "DNF" stood for Did Not Finish.

--Bud

Not a good thing to push because the kernel is the interesting part of Symbian. It's power-tight and has real-time features, both of which are very nice features in a mobile communications device. Unfortunately it only runs on ARM. Linux on the other hand runs on everything. With Qt on top of both Symbian and MeeGo, there's nowhere Nokia can't go. (There's no guarantee they'll actually go there, but they *could*.)

--Bud

Given that the camera moves at relativistic speeds, the chromic aberrations are probably a relativistic effect and would of course get more pronounced the faster the camera moves. Another interesting side effect is that while for you the movie is over in a matter of minutes, someone observing you will feel that the movie takes too long, and incidentally also perceive you as significantly smaller.

Kids, don't try this at home!

--Bud

What was that again? Last time I checked, Darl McBride was busy terminating SCO. :)

--Bud