Using email with older iPad/iPhone, Android device or Mail client

If you have a new enough iThing or other device, then you’ll find “” as one of the options when you create a new Mail/Calendar/Contacts account.
If your device is a bit older – iOS6 or iOS5 or earlier – or is OS X or Android, you may not have an option. But you probably have got an option for adding an MS Exchange or an Exchange ActiveSync account. This works well with so long as you know the right settings. This worked for my iPad and older Android phone:

Email and password: <your actual email address and password that you can use to login to with>
Then on the settings page you need:
Username: An alias, including the bit, which you can use to log in to outlook. This may or may not be identical to your email address
Domain: First try it empty; otherwise try

And that should Just Work. Using with a non-outlook email address, I find that this set up picks up the Default From Address that I set via the web interface.

Money doesn’t make the world go round

“Who are we kidding? Apps are built to earn money. They are a product created to generate profit, and there are a number of ways we can get them to do just that. The simplest, and therefore most common method is …”

So says a typical email in my inbox. But. It ain’t true. Apps are also built because people love to build things. Many, many apps – and websites; and Real Stuff; — are built because people love to built things, and if they didn’t have to earn a living they’d still be building things. For some people, earning money is the pesky thing getting in the way of building the apps they’d love to build.

Should a Software Architect Code? is the Wrong Question

It’s a long-running argument in software architecture and I’ve seen some quite emotional comments on it. But it’s the wrong argument. The right question is surely one about ratios:

“What ratio of non-coding architects to coders will work best for us?”

A ballpark answer to this question would follow logically from calculating how many full-time-developers worth of work results in an amount of non-coding-but-still-requires-deep-or-broad-technical-understanding-and-vision work that adds up to one full time job.

I suggest, based mostly on e-commerce & similar SMEs, something like:
(1) 25 developers’ worth of coding results in 1 full-time non-coding-architect’s worth of work.
(2) Every team needs at least one coding-architect-or-architecturally-competent-developer per 5 developers

Which gets me to a ratio of



non-coding-architect : coding-architect-or-lead-dev : developer

Architecture features plenty of non-coding work. Dealing with people, plans, business change, technical design, design decisions, frameworks, principles, patterns, catalogues, quality attributes… There’s more than enough of it if you have 25 coders’ worth of development going on.

So in a workplace with 100 developers, you may want a chief architect, 3 or 4 non-coding architects and 20 coding-architects-or-architecturally-competent-developers. But if you are chief architect or even CTO of a company with 15 developers, you probably still code.

There’s no right answer to the question, how much coding does a coding-architects-or-architecturally-competent-developers do. It can vary from nearly-nothing to 95% as projects progress. Perhaps 50% is a good average?


There having been not one but two still-live threads on this on LinkedIn software groups since 2012:
LinkedIn – 97 Things Every Software Architect Should Know – Should architects continue coding … ?
LinkedIn – IASA – Should software architects code?
Anthony Langsworth’s 2012 post

Clojure (and some Lisp) in 10 mins for OO developers

Notes from a short talk at xp-manchester:

No doubt the most useful slide is 3, which is a 1-slide “how to read lisp” tutorial.

We did a series of 10 minute talks on the evening, including a set of 3 on features of functional languages: Haskell’s strong typing, mostly inferred; & Erlang’s agents. Erlang’s agents are almost like an OO language in which every ‘class’ (agent) gets its own process; which is what OO seemed to suggest to me when I read descriptions of the grand idea in the 80s/90s. My headlines for Clojure are largely the points made in