4 ms·

The Architecture of Morrisons OrderPad

30 points by seansh 12y ago

yitchelle 12y ago
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 12y ago
  I suspect thats its a custom tool set [1] [1] http://martinfowler.com/bliki/Infodeck.html http://martinfowler.com/bliki/Infodeck.html
martijn_himself 12y ago
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).
GFischer 12y ago
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 12y ago
  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.
tl 12y ago
> (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.
- dangoor 12y ago
  We don't know what the user's requirements were. It's possible that they minimized the required GET actions but that some actions required GETs because the data needed to be real time accurate. In-memory and offline storage are possible in web apps.
- HolyHaddock 12y ago
  Output should be measured by saving costs or new revenue, not lines of code written.
- forgotAgain 12y ago
  And it's a lot cheaper to over specify a cheap wifi network then it is to try to solve the problem with software in applications.
- blatherard 12y ago
  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 12y ago
    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.
- prof_hobart 12y ago
  Certainly better than a planet where effectiveness is measured in terms of number of LOC produced.
- Cthulhu_ 12y ago
  I wonder what quantity of code / time was spent on building their custom jquery-based application framework. Or maintaining it.
davidbanham 12y ago
"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 12y ago
  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.
forgotAgain 12y ago
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.
- fidotron 12y ago
  I'm seeing this trend a lot in the internet of things world. Basically there is a push to replace stuff that works with interoperable web technology based non solutions for . . . Cost saving purposes? Actually it always looks like a way to sell consultancy and hardware upgrades. A lot of this seems based on the group coming in not actually getting how sophisticated that system they assume to be archaic really is.
- cowabunga 12y ago
  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.
Cthulhu_ 12y ago
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 12y ago
  Heaven forbid that they go with something stable with which they have years of experience delivering products. Desperately uncool.

30 points by seansh 12y ago

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 12y ago
I suspect thats its a custom tool set [1] [1] http://martinfowler.com/bliki/Infodeck.html http://martinfowler.com/bliki/Infodeck.html

martijn_himself 12y ago

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).

GFischer 12y ago

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 12y ago
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.

tl 12y ago

> (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.

dangoor 12y ago
We don't know what the user's requirements were. It's possible that they minimized the required GET actions but that some actions required GETs because the data needed to be real time accurate. In-memory and offline storage are possible in web apps.
HolyHaddock 12y ago
Output should be measured by saving costs or new revenue, not lines of code written.
forgotAgain 12y ago
And it's a lot cheaper to over specify a cheap wifi network then it is to try to solve the problem with software in applications.
blatherard 12y ago
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 12y ago
  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.
prof_hobart 12y ago
Certainly better than a planet where effectiveness is measured in terms of number of LOC produced.
Cthulhu_ 12y ago
I wonder what quantity of code / time was spent on building their custom jquery-based application framework. Or maintaining it.

davidbanham 12y ago

"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 12y ago
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.

forgotAgain 12y ago

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.

fidotron 12y ago
I'm seeing this trend a lot in the internet of things world. Basically there is a push to replace stuff that works with interoperable web technology based non solutions for . . . Cost saving purposes? Actually it always looks like a way to sell consultancy and hardware upgrades. A lot of this seems based on the group coming in not actually getting how sophisticated that system they assume to be archaic really is.
cowabunga 12y ago
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.

Cthulhu_ 12y ago

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 12y ago
Heaven forbid that they go with something stable with which they have years of experience delivering products. Desperately uncool.