

The Architecture of Morrisons OrderPad - seansh
http://martinfowler.com/articles/orderPad/

======
forgotAgain
This is a very disappointing project. I would imagine the IT people who worked
at Morrisons were rolling their eyes as the consultants came in and delivered
a way over engineered / overly complex system.

The problems outlined in the article were solved with simpler methods 10 to 15
years ago. Why use a tablet at all? Symbol Technologies was making wireless
handheld computers with scan guns 15 years ago.

In a modern supermarket inventory is updated every time an item is scanned at
checkout. Spot checks of inventory are constantly being done to check for
discrepancies.

The timing of orders was solved in supply chain applications years ago.

Whoever payed for this project I'm sure had a lot of nice meetings with the
contractors. But in the end they got an overly complex system when off the
shelf components in use for years would have done the job better and more
reliably.

~~~
cowabunga
Having developed software for point of delivery (similar market and devices)
on Windows CE approximately 6-10 years ago, I would suggest that they did
indeed pick the best solution to the problem now.

The symbol/intermec handhelds are expensive, terribly unreliable, slow,
require a lot of maintenance and are terribly fiddly especially for people
with gloves on (as you'd expect in the freezer department in Morrisons). As
for the software development side of things, you're pretty much limited to a
subset of win32 that isn't very pleasant to use or a mobile CLR which is so
incredibly slow it makes you want to hang yourselves. Then there's the
incredible deathly pain of deploying the code to all those devices.

It took us three years to deliver a point of delivery system with the same
staffing level with much smaller scope which was simply signing for stuff and
listing a delivery schedule. The integration was done by a third party - we
just passed messages back and forth.

They did a damn good job at TW on this one if you ask me.

~~~
forgotAgain
I disagree with you on a number of your points

 _The symbol /intermec handhelds are expensive, terribly unreliable, slow,
require a lot of maintenance and are terribly fiddly especially for people
with gloves on (as you'd expect in the freezer department in Morrisons)._

I had different experience with industrial scanning equipment from reliable
manufacturers. I found them to be reliable. They could be dropped and still
function and they had a much wider functional temperature range. If the
operator is wearing gloves I would expect that the environment is outside the
functional temperature range of a tablet.

 _As for the software development side of things, you 're pretty much limited
to a subset of win32 that isn't very pleasant to use or a mobile CLR which is
so incredibly slow it makes you want to hang yourselves. Then there's the
incredible deathly pain of deploying the code to all those devices._

There were many devices that supported OS's other than Windows CE as well as
Windows CE device that didn't require the CLR for applications. There were
also thin client models where the code executed on the server which made
deployment much simpler.

 _It took us three years to deliver a point of delivery system with the same
staffing level with much smaller scope which was simply signing for stuff and
listing a delivery schedule. The integration was done by a third party - we
just passed messages back and forth._

You had a remarkably tolerant customer.

 _They did a damn good job at TW on this one if you ask me._

I disagree.

------
tl
> (4/25) We needed to support working offline should the user go out of range
> of wi-fi.

> (8/25) When offline, any actions that require a GET to the server results in
> an error message to the user.

I would argue right there that you failed to deliver a product that met the
user's requirements, and this sort of limitation is why I have to write native
code when writing a web app would be much easier.

> (21/25) Development team consisted of 5 developers, 1 business analyst, 1
> tester, and 1 project manager (times 2 years for development time)

> (21/25) Production code is 20K LOC of Java, 10K javascript.

I'm not sure on what planet that is considered a reasonable level of output,
but it must be nice there.

~~~
blatherard
Regarding the need to do a GET when not connected: How would a native app
solve this problem any better? Presumably, there's live data that sometimes
needs to be fetched. If you're not connected you're not going to get that data
whether you're in a browser or an app.

~~~
robterrell
My favorite solution for this periodic offline/online access is CouchDB for
mobile or PouchDB for html. But it's use would require another device between
the back end CouchDB and their Oracle server.

------
martijn_himself
On slide 6/25, why would you not do a straight 'update order quantity' and
'sendUpdate' using JQuery? (last 2 steps, ok apart from checking the size
limit). Why all the ceremony in between? (genuine question).

------
Cthulhu_
I'm reading a lot of Not Invented Here in that front-end stuff - building your
application on top of jQuery is terribly pre-2012. I bet they spent a
considerable chunk of time on that.

~~~
regularfry
Heaven forbid that they go with something stable with which they have years of
experience delivering products. Desperately uncool.

------
GFischer
Is the two-year timeline reasonable? (ok, the 1st version to production took 7
months)

Ok, so they have more testing code than business code, this is not a "quick
and dirty" app, but it still looks like a long timeline and a large team for
the app's description.

~~~
narag
_Is the two-year timeline reasonable?_

I really hope it isn't. I've made much shorter estimates for a nearly
identical application, with time penalization clauses.

------
davidbanham
"since all the data is stored inside the DOM as field values or HTML data
attributes."

That doesn't seem like a very good idea. Seems like the opposite of what we've
been doing for the last few years.

~~~
protonfish
If "what we've been doing for the last few years" means two-way binding of
data models, then I agree that either that or using direct field values is a
bad idea but the one I am thinking is bad may not be the same one that you
are.

------
yitchelle
The presentation is nice. Does any one know if the tool used for generating
type of presentation is available?

It would be great format for presenting to upstream project management and
friends.

~~~
sleet
I suspect thats its a custom tool set [1]

[1]
[http://martinfowler.com/bliki/Infodeck.html](http://martinfowler.com/bliki/Infodeck.html)

