A week or so ago, I talked of a ThoughtWorks project that was consistently hitting story sizes of one day using AngularJS amongst other technologies. What could we do to make those smaller?

Developers, when they are staffed on a project, quickly become the largest and therefore most expensive group. At that moment, everything has to be optimized for their greatest throughput. If we could delay that moment, then we could delay the coupled increasing of costs.

There’s only so far you can go with photoshop, wire frames and alike before the product owners itch to see something real, so I’m going to propose something that feels real enough to them.

Delaying full-stack development: UX first

Use AngularJS (or better). Hand-write JSON documents that would be served by a backend for pertinent RESTful GETs, and put them in source-control. Also put in a single HTML file that’s your whole app for now. You’re going to have all rectangles that could appear/disappear in a page in the same source file, and use Angular to show/hide them as applicable. You’re going to avoid modularization at this stage.

UX people should already know how to do their own incremental work using source-control appropriately and without an actual web server, so bring them in at this stage. They should already, by default, own the shit out of the CSS, Bootstrap, Sass, etc.

What you want them to adopt, is the AngularJS stuff too. All that goodness in attributes that are non-standard HTML. Attrs like ng-show, ng-hide, ng-click, and the mustachioed expressions. It would be great if it existed, but it doesn’t: a handy set of examples/recipes for newbie -programmers- designers to copy/paste from when designing AngularJS interactions, behaviors, and aesthetics.

Nothing persists of course, as the data is canned, and each refresh of the page, sets you back to the beginning, but a designer and a product owner should be able to push an application forward without a backend. At least for a while. Oh, and forget IE6 & 7.

The above, and no safety net from tests, will get you down to story sizes of an hour or so.

I said delay!

OK, so you still need developers. You can’t go live with a web app that has no backend. Finding the right moment to staff the developers is going to be a challenge, not least of which is resource planning. Do they do nothing before the cutover from designer-only to designer-in-full-dev-team mode? Are they not hired yet? It is a special skill to be able to predict when developers should arrive in force, for a multi month project, and not have ‘waste’ by some definition.

When developers arrive en masse things change. The HTML/JS code would get refactored to be more modular. Non-functional deliverables and priorities start to get weaved in. Tests start guarding progress, if not driving development. Retrofitting tests is far from ideal, of course. Business Analyst work starts to become more steering of direction, and formal batching of work into Agile iterations guards the valuable priorities.

Angular’s imperfection

Apart from the lack comprehensive example/sample code, it is not ready to be cut and paste centric, as not everything you’d want to do has a ng-attribute way of doing it. Indeed there is quite a gap between what you can do in attributes, and what you need JavaScript fragments for.

There’s no reason for that really. The framework that takes over from Angular (ThoughtWorkers are debating this privately now) will have higher equivalence between those two ways of doing things. Take Angular’s loading of resources from a adjacent JSON document: https://docs.angularjs.org/api/ngResource/service/$resource -

var User = $resource('/user/:userId', {userId:'@id'});
var user = User.get({userId:123}, function() {
    user.abc = true;
    user.$save();
  });

Sure you could tach that to UX folks as something suitable for copy/paste, but it would be better to have:

<div ng-resource="user, '/user/:userId', @id">
  <div>{{ user.name }}</div>
  <button ng-click="user.$delete(); window.location.href = '/'">Delete</button>	
</div>

I grant you that those two fragments are not functionally identical. The HTML one is more real world (delete), and the one from the Angular doco is contrived (load, mutate, save w/o interaction). Trust me, the ngResource page is a bazillion times better than it used to be when it focussed on a long dead Google-Buzz API (as an example).

I also grant you that there’s no “failure to load resource” handling. The same goes for “failure to delete”. Both of those shouldn’t slow down an idealized UX-led built-out of functionality, though.

The perfect starter team

Of course, this is only going to work for a build-out that’s got an emphasis on “get it right cheapest”, rather than “get it live ASAP”. The perfect team, still has a JavaScript/Angular expert, and a BA to help concentrate on the prose-full description of behaviors needed. It is best done in Agile iterations, and if a PM is involved at all it is to peer into iterations ahead to refine the length of project, and when the developers should arrive for the full-stack experience.

There’s another skill needed (Dave Smith points out): Data Modeler. The structure of the JSON documents that suggest storage in a NoSQL backend, means that someone in the team should be spreading around Data Modeler skills from the start. Not only should those JSON documents fit a simple binding to the view, but they should stand a chance of being retained for the future connecting of a from-scratch backend.

Pitfalls

Aside from those mentioned:

• Anyone coding too far ahead (functional or non-functional)
• Gold-plating instead of showcasing
• Lack of requirements
• Bad leadership
• Integrations with backends that can’t be delayed

Further reading

I outlined a year ago a model where UX staff can get busy with an AngularJS front-end: When Agile meets Angular and UX-led development. That article introduced the idea of UX-led (in this context) and cites pretotyping which you should learn to love. This one takes UX-led to it’s conclusion.

Delaying non-functional requirements is worth a read too, as are small stories - a call to arms and the document is the single source of truth.

Maybe even UI Technology Paradigm Shift is worth a read.

Lastly, NoSQL for storage AND relational for reporting may appease the ‘future thinking’ architects that will suggest that document-storage isn’t going to work for their corporation (when the team gets round to making a backend).

One last note

DDD is and will always be Domain-driven_design not “Developer Delayed Development”.