Link: http://weblog.tetradian.com/2013/12/27/getting-beyond-just-do-it/
Sometimes I really do despair of the ‘Just Do It’ crowd…
In a previous post, I described the practical challenges faced by anyone starting out on something new, and used a few personal examples in my own work to illustrate this. I then made the huge mistake of asking for practical advice about this.
What I got back was a stream of utterly unhelpful garbage – most of it well-meant, but some sadly not – most of which could be summed up by three words: “Just Do It”. None of the people concerned seemd to understand a really, really simple point: if I already knew how to do it, I wouldn’t be asking for advice on how to do it – I would already be doing it. And in those circumstances, ‘Just Do It’ is not not so much not helpful as an outright insult. Sigh…
In amongst the unhelpful non-advice, there were indeed a fair few of the more blatant examples of smug-arrogant-insult-disguised-as-’help’, such as “there can be such a thing as too much thinking”, and “if you want to do something, you’ll find a way; if you don’t, you’ll find an excuse”. If there’s a quick way to enrage someone who is trying to do something completely new, and has been doing so, damned hard, for way too many years with way too little income and way too much anti-support, that really has to be it…
So…
Let’s do the big-picture first, and then the small-picture part, okay?
The big-picture
Before we start, a brief aside for the ‘Just Do It’ folks: ‘Just Enough Architecture Up Front’ does not mean ‘No Architecture Up Front’. If we don’t do sufficient thinking up-front, we end up building something that is, by definition (and by stupidity…) inherently incapable of reaching the required aim.
An illustration in point: there are literally tens of thousands of projects ongoing across the world right now into exploring some form or other of ‘alternative currency’. Yet by definition, none of them will succeed in doing anything more than making the real problems worse. The actual problem-area is not about the structure of ‘currency’, but that currency itself is merely an overlay on top of an existing ‘wrong-answer‘ (short-termist exclusive-possession) to a significantly deeper challenge (managing finite resources over the long-term on a finite planet). By definition, all of that effort on ‘alternative currencies’ is a total waste – and worse, it’s taking energy away from where we really need to place it – because we urgently need a viable ‘right-answer’ to that resource-management challenge before those irreplaceable resources really do run out.
So, here’s the big-picture of what I’ve been talking about, about ‘the app’ or whatever:
– 1. There is an identifiable need for some kind of tooling that supports the whole of the workflow and context of enterprise-architecture and related fields – in effect, anything that links across and through the whole cycle from before strategy to after operations and back again, fully recursive at every level across the entire scope. We could summarise the overall scope and need with the Five Elements frame:
– 2. The key problem being addressed here is fragmentation of views over that whole scope, and across all of the different timescales, from far-future to near-future to NOW! to past, and back again. Plenty of tools already exist to cover single subsets of the overall scope, but incompatibilities between them mean that at present there is no way to create any kind of unified view. Without that unified view, we automatically devolve to increasingly-ineffectual ‘Just Do It’ dysfunctions that are inherently-unable to deliver against the actual need.
– 3. Specific model-types and metamodels will be needed in order to cover the specialist needs of subsets of that overall space. More particularly, it should be self-evident that no single model-type or metamodel will be able to cover the whole of the space, other than at a level of abstraction that is unlikely to be much practical use. However, some means to unify across the whole space is required, in order to prevent fragmentation. There is therefore a requirement to balance across all levels of abstraction, from most-abstract and most-unifying to most-concrete yet most prone to fragmentation.
– 4. As part of the necessary ‘Just Enough Thinking Up Front’, I’ve already spent several years exploring the needs for whole-of-context tooling, including use-cases, metametamodels and metaframeworks. I’ve done a lot of observation of real-world workflows across the whole of the context-space, in order to understand where tooling could help in unifying across those workflows, versus where (as in fact occurs too often in practice at present) tooling will increase fragmentation or just get in the way.
– 5. Any tooling will need to cover and/or be able to support the whole of the toolset-ecosystem that is actually in use across the whole context-space, from petabyte-plus big-data repositories, all the way down to almost-’dumb’ handhelds. The scale is so huge that no one manufacturer or toolset-developer could ever expect to cover it all – yet overall, failure to cover the whole of the toolset-ecosystem will, by definition, cause failure to deliver to the actual need. This implies a need for non-proprietary standards that focus primarily on the ‘between’-space – the linkages between the discrete elements or ‘solutions’ in their respective subsets of the overall context-space.
There’s more to it, of course – a lot more to it, including why tackling this issue properly could well be a species-survival issue for us all – but that’ll probably do for a start?
And I repeat: any so-called ‘solution’ to these requirements that fails to link across the whole of the context-space will not satisfy the actual need.
And yet, equally obviously, we’re not going to be able to deliver all of that in one go. So what do we do?
The answer: start small – yes, that part would sort-of-satisfy the Just Do It brigade – yet whilst keeping always the whole always in mind – which is the part that the Just Do It brigade tend to forget…
Between big-picture and small-picture
Some folks – the MIX crew, for example – might describe this kind of big-picture requirement as a ‘moon-shot‘. Which perhaps leads to a useful analogy here, about the difference between a firework rocket, versus the kind of real rocket-science needed for a rocket that really can lift something towards the stars. The ‘Just Do It’ crowd are really good at giving us millions of metaphoric firework rockets: and whilst the result may be very pretty, and probably very profitable for some, it doesn’t deliver against the actual need.
The only way that ‘Just Do It’ it will deliver anything useful towards the actual need is if we keep the big-picture in mind at all times whilst working on any part of the small-picture.
So, here’s the mid-range of the moves I’ve made towards that whole-of-context tooling requirement:
– There is no existing tooling that comes even close to satisfying the need. Probably the nearest would be something like an expanded version of Evernote: hence it might be sort-of-possible to do some kind of plug-in for Evernote that might sort-of do sort-of some of the need. The catch is that, like just about everything else that I’ve looked at over the past few years, it’s a proprietary file-format, it’s constrained in terms of what parts of the ecosystem it can and can’t support, and I don’t have a clue where to start plug-in development for Evernote anyway.
– I have a lot of research-notes on what’s needed. Many of these I’ve published on this blog, if anyone has any interest in doing anything more useful than putting me down yet again – see, for example, the post ‘Five EA app-ideas – anyone interested?‘ and all of the links that come out of that post.
– Almost no-one is likely to take it seriously unless I have some kind of first-level demonstrator to show. Which is why I’ve doing a lot of work towards getting some kind of prooof-of-concept together. Which is where we get down to the small-picture.
The small-picture
For the purposes of building at least some kind of concept-demonstrator that might just possibly keep the ‘Just Do It’ crowd at bay, I’ve been pulling a whole load of strands together.
Any ‘real’ toolset will need serious-level security, reliability, performance, and much else besides. I am not the right person to attempt to do that. I can code, sort-of, but most of my detail-level knowledge is way out of date, and was never too wonderful to begin with. What I can do is knock up something that makes enough sense for someone else – who does know what they’re doing, with code and the like – to ‘get it’ as to what I’m on about here.
(The reality, once again, is that whoever actually ‘gets it’ first will probably make an absolute fortune out of it, whilst once again I’m likely to end up with nothing. But that’s the way this game goes – and it’s probably the only way that this kind of toolset that we need has any chance of happening at all. Oh well.)
I don’t have a clue where to start with ‘proper’ modern app-development – anything IOS or Android or OS-X or Windows or Unix or anything of that kind. I struggled for quite a while to make any sense of Objective-C: to me it seems to combine the worst of C with the worst of assembler, with the advantages or sense of neither. I likewise struggled for quite a while to make any sense of Eclipse, and failed.
In any case, I know that, even from the start, it needs to be multi-platform, or at least in some sense cross-platform, in order to demonstrate some of the key points about an ecosystem of toolsets.
To give somewhere to start, I’d settled on doing some kind of web-app that could also work as a offline-standalone. In other words, somewhere that either includes or perhaps even runs entirely on the HTML5 / Javascript / CSS caucus.
I’ve explored pretty intensively on frameworks and the like. For example, there are a few standalone oddities like TiddlyWiki – except, in that specific case, every darn save has to carry the entire wiki source-code with it, at minimum of 600+kb a shot; and since its CSS is embedded in its Javascript code, and its user-data embedded in the save HTML DOM,, there seems to be no way to make it satisfy some of the other key requirements, such as responsive-layout or cross-platform data-exchange.
Scouring Themeforest and suchlike, I’ve found a few frameworks and site-templates that might be usable as a base from which to start on the kind of app-development that seems to be needed for that prototype. Beyond that, there’s a bewildering array of Javascript-libraries and pre-process languages (CoffeeScript, LESS, Grunt, Brunch, etc, etc, etc) that I may need, but just don’t know. And choosing the wrong base-framework would guarantee having to scrap the whole lot and start again – which I don’t have the time or the energy to do – not any more, anyway. So I really do need to get it right first time, without fail, otherwise it’s not going to happen: I’m painfully aware of that.
I’m working on Macs (variously OS-X 10.8 and 10.9, if that detail is relevant).
I have various web-development IDEs here, installed, paid-for, working.
I also have various servers set up on my development machines: Apache, MySQL and Node.js, to name a few of the more obvious ones.
In that sense, I’m almost ready to go: I have enough basic knowledge, tools, frameworks, requirements-summaries and concept-sketches with which to make some kind of start. If you like, that’s hurdles 2, 3, 4, 5 and so on.
What I don’t have is the knowledge of how to get over the first hurdle: how to set up a compile-workflow.
When I last did web-development, there was a clear distinction between front-end and back-end: in my case, HTML, CSS and Javascript on the client-side, and PHP and MySQL on the server-side, all as distinct files, and all directly in their raw interpreted-language form. But that isn’t what happens now: instead, there seems to be an unavoidable requirement for some kind of automated-workflow via a make-tool such as Grunt or Brunch, to link together all of the various precompilers (Coffeescript, LESS, etc), libraries and dependencies (Twitter-Bootstrap, JSQuery, D3.js etc), minifiers and compressors (Uglify.js etc). And I don’t know how to set it up.
I haven’t found any information on how to do the very first steps: everything I’ve found so far assumes a full working-knowledge of the OS-X terminal and the Unix command-set and library-management Git and Subversion and the rest – which I don’t have.
And since I don’t have that knowledge, I’m stuck, at the first hurdle. Not at the second or third or fourth hurdle – I know how to deal with those. The first hurdle – and only the first hurdle.
So, here’s the request, again: can anyone show me, step by step, how to set up an appropriate automated workflow for web-app development, on Mac OS-X, that does not assume that I already know how to use Terminal or anything else of the non-GUI part of OS-X?
If all you’re going to offer is yet more ‘Just Do It’ platitudes… well, just don’t bother, okay? I’ve given seven years of my life helping others with step-by-step instructions on how to sort out their enterprise-architectures – almost all of it unpaid – so you darn well ought to understand why I can get a bit tetchy by this stage, if, when I do ask for help, all that I get back is yet more ‘Just Do It’ inanities. I’ve had more than enough of those pseudo-’advice’ insults already, so please don’t be surprised if I tell you exactly where you can shove such them…
But if – unlike the ‘Just Do It’ crowd – you can tell me how to do that setup, then yes, that would be great: it would really help me a lot right now.
Or, even better, if you’re actually interested in taking on the challenge of the toolset-ecosystem, and do know what you’re doing in development and the like, then yes, I’d really like to hear from you. Again, I’m painfully aware that I’m not the right person to do this – but someone has to do this until the right person comes along.
Either way, please, please, let’s get beyond the ‘Just Do It’ bullshit, okay? This is a serious concern, and needs serious responses from serious people – not petty platitudes people pointless people who are only interested in playing around… At my time of life, I really cannot put up with timewasters any more. Sigh…
Over to you, if you would?
